Some days ago I got an ESP32 Dev Board. Based on Neil Kolbans work it was easy to get a first version of Espruino running. It lacks a lot of things, since Espressif is still working on SPI/I2C/BLE, ...
Anyway we have a new world for Espruino and this world supports tasks, queues and other nice functions.
First version of queue handling is already running
Target is to have JS-commands like:
Shame about the SPI/I2c - but if you're up to date with the current Espruino branch, you should be able to handle both of those in software pretty well?
Do the two cores share an address space, and is there any coherency? I guess that could change how you approach it pretty drastically...
Personally, I'd try and getting Espruino running on the non-Wifi core with it as much real-time control as possible (using interrupts for the utility timer and serial, and making sure Wifi doesn't use any CPU time) - then handling whatever tasks you can (eg HTTP server) on the Wifi core.
There's jsiQueueEvent and similar functions that could form quite a nice place to split between the two cores. Having an easy method to handle callbacks from the second CPU core could mean that it'd be much easier to hand tasks to it from JS.
For example things like FFT (I'm struggling to think of other intensive things :) ) could work on the second core and could then call back when complete.
Does it even make sense to have js running in both threads? Like, I'd say it's fine if everything runs in one thread, while the other one just handles network stuff that happens under the hood? I thought the main reason we were so excited about the second thread was so that we didn't have the network - stuff watchdog biting our ass if we have to do something slow
Status: SPI support is now available and I2C should be right behind it as the puzzles are now resolved. Note that the build instructions changed a tad to get the libraries correct for SPI and I2C. Espressif has released the news that their formal SDK at the 1.0 release will be available at the start of December at which time we will have all the proper libraries that we need to complete the build out. Until then we are using libraries that "work" but which aren't final.
For me ESP32 is like a (power hungry and power devouring EspruinoWifi on stereoids... The operation of the extra HW resources - 2 cores, higher clock rate/speed, more memory - and the extra SW resources - more versatile and more amout of code - come just not for free...
The choice of, for example, EspruinoWifi vs ESP32 boils down to all aspects of the application requirements. We know that the ESP8266 network stack and the serial communication and its ramifications pose restrictions and burdens in various ways, such as more work on Espruino side, they both ESP8266 and Espruino have at this time outgrown their growing pain in quality (and function and tooling), and that is something that ESP32 still has to go through... and more so since some of ESP32's (final - initial version 1.000000) pieces are not even 'born' yet ;).
Reading the comments, there is a discussion starting "do we need 2 Espruino tasks" From my point of view this would be one option only to use multiple tasks. Mention the 2-core Espruino option in was accidently begin of a wrong question.
Writing this, I'm absolutely sure, if we can do 2 tasks running Espruino, there will be some guys using that, if we like it or not.
Looking back to history, there was a time where so called mini-computers (mini not micro) have been as powerful as ESP32 is today. Several OS have been on the market and all of them supported multitasking. And there was a good reason for that.
Today we have this chip supporting multitasking, lets discuss how Espruino could support multitasking.
One big question is sharing data between tasks, queues and semaphores are a way to do this. Another question is task handling, and some more will come up.
Thats what I wanted to discuss, not "do we need 2 Espruino tasks". As I can see, my first post was misleading, sorry for that.
In Espruino there are two main queues already that are relatively well tested (used for everything, and have been there since the start) - there's ioBuffer - for input events, and txBuffer - for output events.
Potentially some tasks could be handled on the second core using those if needed.
Not sure what though - I'm struggling to think of stuff that's easy to offload.
Don't worry about formatting, just type in the text and we'll take care of making sense of it. We will auto-convert links, and if you put asterisks around words we will make them bold.
For a full reference visit the Markdown syntax.
© Espruino, powered by microcosm.
Report a problem