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
Tracking @tve's path throught the 'implemenation options landscape', I conclude that putting 'everything' on a single cpu just creates to many dependencies. Yes, it would be great to have a better integration of the communication aspect - something like wifie/ESP8266 - into the application part - JS applicationss - through the Espruino Runtime Environment...
But a long, long time ago evolution has taken a little bit a different approach: cooperation of subsystems that all have their own nPU (nano-PU) - working 'together' by a mPU - and for some faster information interchange bypassing and offloading the mPU - multiple specific DAPU (such as DMAs). First, it was like 'simple' periphery discrete chips, like CTC, SIO, PIO,... and D'M'A Integration.
VLSI and speed - allowed and required it to put it into a single package and shift towards more sophisticated cotrol through software (uCode instead of 'wired' decoding and control, CISC to RISC to hybrid) - and that's what we now have wit the stM hardware. I see kind of a repetition of that over and over again.
I like having an encapsulated communation component/platform - ESP8266 for example - and like-wise application platform (which includes some basic hardware access (w/ limited 'real' time capabilities). On a similar note, running robustly x/y of a plotter directly from Espruino ontop of the controlling app compounded already to 'issues' for me. Smooth operation over the range of given delta-x and delta-y asked already for independent processing/controlling unit that has enough 'free time' to stay within the tolerances of serving the interupts/timing expected by stepper drivers and motors. I'm thinking of Espruino platform as the center and high-level control, and all the other things are like satellites focused on a dedicated task - that doesn't meand they can not be Espruino's as well, but may be it become a bit an over kill.
I'd rather see ESP8266 grow to a point where it becomes as a http(s) service to Espruino by taking on more responsibility, especially such as TSL (and incl. HTTP/1.1). In other words, he code on Espruino to use those capabilities becomes more like a facade or API and the actual implementation is in ESP8266. Espruino has alaready enough on its plate to manage the hardware oriented, hardware-interrupt dictated aspect without 'losses' and at the same time tend optimally to the Javascript side / application.
Enhancing the cooperation by enhancing the software on both ESP8266 and Espruino sides looks most promising to me. ESP8266 and Espruino core should stay what they are, but both cores are complemented with bridge/beach head software optimized towards/for each other. The effort (and resource consumation) to be truthful to such a layerin/API/micro-service approach pays off by robustness in operation due to better testability.