Architecture: Core processing of jsiLoop

In the Espruino port to the ESP8266 what I am doing is invoking jsiLoop() once and, when it returns, scheduling a callback the next time the ESP8266 is idle and giving control back to the ESP8266 runtime. When the callback informs me that ESP8266 is idle, I invoke jsiLoop() again and repeat this process forever.

The philosophy here is that the ESP8266 is a single threaded processor and hence can't do things in parallel. Since WiFi and TCP/IP are implemented in software and radio in the ESP8266, we can't take too long outside of the ESP8266 world. So far ... all has been working fine. Espressif claim that we should give control back to the ESP8266 every 50 msecs or less.

Now imagine that we did NOT return control to ESP8266 in a timely manner. Imagine that jsiLoop() took seconds to return. What that would mean is that the WiFi and TCP/IP layers would not be fed. So, for example, if we setup a socket listener in JS such that an external client tried to connect ... if we didn't feed ESP8266 soon enough, an external client might try and form a connection and its own TCP layer wouldn't get any IP level responses in time and the connection would appear to fail.

We are starting to see indications that we might be not feeding the ESP8266 fast enough. It is manifesting during timing critical areas such as WiFi access point connections. If we ask the ESP8266 to connect to an AP as a station while also having setInterval() timer at work, we appear to get WiFi level timeouts.

It is early days in debugging this. If we do NOTHING timer related while forming the WiFi AP connection we are good ... so that might be a work around ...

Now ... the meat of the question. Is there a description of how the main loop of Espruino works? Does it process a statement, a function or something else in a unit of jsiLoop()?

Neil