You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@allObjects
@Svarog
Espruino hides all the complexity of dealing on that low level. If your events are low frequency, there is no need to even think of these things in the application - the high level of control - you intend to achieve. Espruino uses an event queue to queue and buffer up eventual low level, hardware events, and lets you 'attach' (watch with javascript event handlers) to deal with them when the processor has time to do so... and with temperature and other figures, such as moisture, etc., there is plenty of time left to do the things single threaded as Espruino on the application level in JavaScript is. Monitoring and analyzing bird tweets and chirping of crickets would not be considered low frequency events, even though Espruino has built in double buffered support for recording and processing of decently bursts of events... ;-)
I suggest to start of with Espruino original boards and not jump into the complexity and challenges the second-class citizens ESP-only based boards are.
As you most likely know, ESPs first ESP8266 series chips/boards had only a single processor and the communication stack required that a user thread can never hog the processor resource longer than a given time - in other words - that the application has to fit into maximum time sized windows between the times the communication stack has to be served by the processor. For a lot of applications this is plenty cycles to do what they have to do and return control to the (interrupt driven) communication stack control. If you though hog the cpu longer and the communication stack does not get control within expected time frame, the system resets and starts over.
In the Espruino world this contention has been solved a long time ago by pairing an application dedicated chip / board with a simple/cheap ESP8266 - either wired-up or on board module - to 'leave the communication' up to dedicated resource and have dedicate resource for the application: Espruino Pico w/ ESP8266 or Espruino-Wifi. More recently, focus shifted to NRF52 based hardware that has excellent BLE Bluetooth Low Energy support the same fashion. I could easily see a mesh/star of MDBT42Q breakout modules and a Pixl.js for control / display (and as hub w/ additional ESP8266 to communicate w/ 'outside'). Both of these Espruino boards use the same core - MDBT42Q module - and keep your application code 'simple'.
In the ESP world, the processor resource contention has been resolved with the EPS32 dual processor module. ESP goes though a bit a different route as Espruino / @Gordon. As much an underlaying OS helps to manage resources, it is more resource demanding and thus also more complex in using the underlaying hardware, since there are more layers between your application and the actual pin to control or measure, for example.
Espruino has a rich library that connects to all kinds of sensors and bring their access and control into a simple JavaScript object that - worst case scenario - requires the application to provide a callback or use Promises - also built-in language feature - to deal with asynchronous and event driven processing and communication.