I Sleep You 3000 #6254
Replies: 1 comment
-
Posted at 2019-06-18 by Robin Mon 2019.06.17 @unreality this experiment is creating a true Did you catch the bold text just beneath that code snippet from the link provided?
Forcing the processor to block other requested scheduled tasks is a bad practice, as you have discovered. A forced break/exit is most likely by design as this article points out: The datasheet for your particular processor may have an explanation also. The original snippet using
What is the true purpose, an attempt to make Javascript instructions look pretty? Posted at 2019-06-18 by Unreality @robin Posted at 2019-06-18 by @fanoush Yes, while it looks sensible, what you did in fact does not makes sense in event based system like espruino. The while block is useful only for short code that finishes quickly and not with true condition and not with any wait inside. Your blocks would translate well to e.g. micropython. Yes it is confusing and your case perfectly shows how those blocks are hiding the true nature of event based javascript and Espruino. The first generated code is in fact complete nonsene, which is not your fault. Your fix is well meant but not really helping, check e.g. this explanation Maybe the block->code generation could be much smarter to create illusion that this works but it looks like currently it is not clever enough. Posted at 2019-06-18 by Unreality @fanoush https://blockly-demo.appspot.com/static/demos/interpreter/async-execution.html You can see that the 'waitForSeconds' work completely fine. There is way to make the blockly makes sense in execution, so I think Espruino could do something to support 'waitForSeconds' like that Javascript Interpreter layer, and thus would make kids far more easier to play with Espruino? Posted at 2019-06-18 by @fanoush Oh, they have this sandboxed 70Kb minimized javascript interpreter written in javascript to allow this. Looks a bit heavy for Espruino. Posted at 2019-06-18 by AkosLukacs The Almost wrote that there could be a "main loop a'la arduino" thing in Espruino-Blockly, that emulates the expected behaviour. But the purist inside me thinks that kids mind should not contaminated be by seeing a blocking wait call on a microcontroller. Or actually in any code. Even if everybody seem to do that. Instead if the Posted at 2019-06-18 by Unreality why is it a poison for kids? some language supports the wait function, why limit event based javascript to the mind of a kid? also with ES7 it can support async and await, is it really a poison? Posted at 2019-06-18 by Unreality there are times we need for loop and have wait for seconds within it kids do not know about multithread etc, why limit their mind and treat "wait/sleep" as abnormal Posted at 2019-06-18 by AkosLukacs The poison part meant to be slight joke. If you do that with async-await, it won't block the CPU, it 's just a state machine, that gives the illusion of "sync" code. While allowing the CPU can do whatever it wants. Execute other code, or go to sleep to save energy. Ok, that's really far from a kid just learning programming, and I have no experience teaching kids. So you are right, it should be as simple as possible. Posted at 2019-06-21 by maze1980 The blocks "After n seconds do" and "Every n seconds do" are suited for the task, like this:
And yes, it first prints "LED 1 on" and then "LED 1 off", and that makes complete sense. If you tell someone to switch the light out after 1 minute from now on, and then to switch the lights on immediately the exact same thing will happen: Lights on first, then lights off. So I'd say even kids can understand this. Now duplicate the block, multiply the numbers by 2.5 and update the text. The kids will see the real power of async programming. You could toggle one LED at 1 Hz and another one at 2.5 Hz. How would you do this with a while loop using waits? The wait block should be removed for Espruino as it doesn't do anything useful, Javascript being an async progamming language. Posted at 2019-06-21 by Unreality
do you mean javascript ES7 which supports async / await changed the nature of language? Posted at 2019-06-21 by maze1980 No, it's still async. In Espruino you can take the block "Wait BTN1 both edge do", that is basically the same as an await. And ofc the "sleep" functions implemented in ES7 are still async, if there's any function triggered while a "sleep" function is "active" that function will be executed. Posted at 2019-06-22 by AkosLukacs Async-await does not make it sync. It only gives the "illusion" of synchronous execution. For example Typescript has / had a state machine that supports async/await without browser support. It's a state machine that gives an illusion of sync execution while the code actually executes async + on one thread. Now async is supported by most browsers, but I thought it's worth mentioning. So it's not block-the-browser sync & works (and did work) without browser support. For example unless you Check out this plunk for an example. Try to guess what happens without looking at the console :) Posted at 2019-06-23 by @allObjects This is a different wording of the facts @AkosLukacs points out in post #7. The problem is that blockly does not think (If you are using ESP8266, your processor reboots constantly... because the Wifi stack on it has an interrupt cycle of a given number of micro seconds to take care of urgent communication work, and when it does not get the control of the processor, it resets itself. This means in other words that the javascript executed on an even can only take so much that it still fits into this interrupt cycle window... From the total processor time only a percentage is available to other code / application code / Espruino code, and this code has to finish within a given number of microseconds. The other percentage is used by the Wifi stack). What actually happens in the blockly code is the following:
Creating the entry in the time table takes practically no time -returns immediately - to executed next statement, and now y0u understand that the code creates tons of execution deferred pieces of code... until it rans out of space in the time table... (paraphrased), and never ever even 'gets the time' to work on these scheduled blocks of code... SetInterval and SetTimeout is not a waiting kind of thing but a scheduling thing scheduling a piece of code to be executed at scheduled time (now plus delay), is executed immediately with control returning immediately. Try something like that in blockly:
Invoking the function f you even can - should - do with a wait, because you want to let the upload finish - because it is also a Javascript snippet(s) execution.
The sequence you create this logic in blockly is to create the function first, and then the other code:
I'm sure you have some other logic that controls boolean variable b and as well some variable code that determines whether the led should be turned on or off... @gfwilliams, I guess it is time to thing of something more Espruino / JS / Event driven and 'ban' the (inferior and in reality never used concept of) wait (by killing processor cycles by just looping around and checking time)... for examle: Posted at 2019-06-23 by Robin Sun 2019.06.23 Agree with your last sentence @allObjects re Blockly. I also like your idea of For @unreality, > 'Is there a max execution time that forced the nodeMCU to reset?' Found a nice article explaining both the Hw and Sw resets for ESP8266
EDIT: Sun 2019.06.23 Posted at 2019-06-23 by maze1980 @Allobject: The two blocks "After n seconds do" and "Every n seconds do" are already there. I'm not sure why you introduced scheduleOnce() and scheduleRepeated(), do you want them as js functions or blocky, and how would they differ from the existing js functions setTimeout/setInterval or the existing blocks? Posted at 2019-06-23 by Robin Sun 2019.06.23 @maze1980, I see that you are a recent member to the forums, forgive me if explaining this implies otherwise. While I'll defer to @allObjects for an author official explanation, and while his availability is rather limited, and a considerable amount of effort went into laying out that content, . . . IMO if you'll note, his last paragraph was addressed to Gordon, . . . 'for example' . . . and as a suggestion with content to enhance Espruino and not directly meant to change how the core Javascript is defined. In your explanation #13 my interpretation is that I believe that you believe the difference, but the explanation needs a bit of cleanup. Excellent article:
From the article and the above post, the 'actual' code is 'queued', along with the event, and running in a single thread. So there isn't a guarantee the function will be executed immediately as in your explanation. Posted at 2019-06-24 by @allObjects @maze1980, yes, I would like to have blocklies with these names. Of course, they will use setTimeout() and setInterval(), and furthermore, return the handle, so they can be canceled: cancel(handle)... another blockly... and the wait I would retire, because it conveys the wrong concept: Scheduling is not waiting... but I see your point that "After n seconds do" and "Every n seconds do" already do that... missed it. The only thing they are missing is to be able to store the handle... and there is no cancel to use the handle... Introducing the concept of scheduling makes cancel understandable... Posted at 2019-06-24 by maze1980 I agree, it makes sense. Maybe it goes beyond what most users would build with Blocky, but as long as a handle and cancel block are not implemented nobody knows for sure. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-06-18 by Unreality
the current 'wait x seconds' for Espruino blockly doesn't always work as intended.
for example, if a
while(true)
loop containing await x seconds
block, for javascript, it doesn't really wait for the setTimeout function and will just immediately execute the next iteration.e.g. the attached image will be converted to:
Which is pretty confusing for the blockly user
So I implement a sleep function as stated in https://stackoverflow.com/a/16624104/63226
It works when I execute like sleep(1000) or sleep(2000), but for sleep(3000) the nodeMCU resets itself.
Is there a max execution time that forced the nodeMCU to reset? if yes, then how to increase it?
Thanks
Attachments:
Beta Was this translation helpful? Give feedback.
All reactions