Espruino on ESP8266

@Kolban, I woid not exactly compare the loops Espruino has with the typical 'application visible' and infinite - inevitable - loop of Arduino.

For me Espruino feels like two workers that cooperate with one another. Simplified:

The first one is very fast completely hardware event - pin, timer, communicaiton subsystem - driven and creates the software events and puts them into a work queue for the javascript coworker. The javascript coworker works around this queue until it is empty and then goes to sleep. It has to be this way, because the first, very fast worker has to make sure no events gets lost. The second one is slower and continuously works through the event list and executes the event related application code. If no application code has defined interrupts on pins and timers and communication sub systems, then I expect only internal timer events happen to keep up the (Espruino getTime()) time. Even when on-data communication events are defined and happen, the related data entity - nibble, byte, string/line/buffer - 'filling' has to complete before a javascript event is put into the queue for handling by the application queue.

Every on-"something" and setTimeout() and setInterval() of the application code registers and configures an event handling in the first, fast worker and defines what this worker has to put when into the queue for the javascript worker.

When the very first hardware or timing event happens and has been processed, the processer changes hats and puts on the javascript worker hat and looks into the javascript event queue to handle the event that it just has placed there. If a new hardware or timing event happens while handling the javascript event, the processor quickly and briefely changes hats and handles the event and then returns to resume the javascript processing. On finishing the javascript event handling of a particular javascript event, the processor checks for more javascript events and processes them until the javascript event queue is empty, and then goes to sleep... until it gets waken up by the next hardware event.