You are reading a single comment by @allObjects and its replies. Click here to read the full conversation.
  • Espruino is done with what has to be done in the interval and goes back to deep sleep... which of course switches the LED off.
    That's not the case at all. Espruino goes into deep sleep (STOP) modes while still keeping power on all GPIO outputs.
    Pretty much all peripherals are powered down, except GPIO which still works (or setWatch wouldn't do anything).

    That's quite confusing... But to verify from a different point of view: In deep sleep, if a GPIO pin is on output and high, and I place a drain of 10mA - LED to GND with current limiting resistor - does that mean that the 'processor' draws something between 10.5..11mA - 10 for the LED and some 0.5+mA for the rest of the chip? Or, in other words: driving an output stage is included in the 0.5+mA, but of course the sourcing not, and there is no need and no gain what so ever to put something external to it?

    Another clarification: peripherals means more than just a GPIO pin is sensing (input) or is driven (output), such as any serial I/O, because handling any serial I/O needs the high speed oszillator to run and drive the cpu crunching code. Is that correct?

    @Stevie, that's correct that there are two layers of execution code:

    1. the firmware that put's hardware events into the JS software event queue (with time and other information in order to not loose anything in case the (single threaded) JS interpreter is busy doing something at the moment of the hardware interrupt)
    2. the JS interpreter that runs until all interrupts in the JS software event queue are served.

    I would though still not call it 'an endless loop', because the concept of a '... loop' is very misleading, as noticed troughout the forum posts... Yes, as soon as a hardware interrupt happened, the JS interpreter is kicked off and loops emptying the interrupt queue.

About

Avatar for allObjects @allObjects started