ESP32 Forum

I started looking at JerryScript (http://jerryscript.net/) as a JavaScript runtime. I compiled it as an ESP-IDF component ... and ... darn ... it worked first time. It slotted right into the ESP-IDF framework without issue.

I'm putting it through some paces now and there will be more to come ... but initial indications are excellent.

What was your experience with JerryScript (or IoT.js) on the ESP32? How does it compare to Espruino and Duktape (I see you have done some work in both of these)?

We are looking at implementing an existing embedded JavaScript language on the ESP32. This is such that JS developers can do their magic and the C devs can do the low-level magic.

Espruino is in development and appears to run out of memory quickly, and so it's not possible to run heavy JS applications. What is it like creating custom firmware extensions? Do you need to fork the whole library?

Duktape and JerryScript seem to be in the same bucket. But what has been your experience with the two of them?

Yeah I'd like to know as well, have you given up on Duktape for some reason?

@psiph75,
For creating your own Espruino firmware, take a look at this big tool https://github.com/espruino/EspruinoBuildTools, built by wilberforce
Adding your own extensions to Espruino, see here http://jumspruino.jumware.com/docu/Exte ... index.html This should be a good starting point.

What is a heavy JS application in your area, is Espruino the limiting part or is it ESP32 itself ?
To give an example, a Webserver used by some clients is running out of memory soon, whatever firmware you have.
Or using tons of textual data in javascript takes a lot of memory. Using flash for text saves a lot of memory, etc., etc.

@jumjum23
Thanks for the reply. First we have some low level performance critical UART stuff to do, so we need to write custom firmware.

On the "heavy" JavaScript side it's downloading and parsing 1 to 2 kB of JSON over MQTT using TLS, also posting other JSON objects over MQTT too. Also running various functions at certain times. With Espruino, the MQTT+TLS just by itself takes up 4000 vars (80%) of memory on the ESP32, and that's after deleting the certificate strings.

Howdy guys,
Back at the start of the year I was super keen on getting JavaScript running on the ESP32. I started working on Espruino and then someone pointed me to JerryScript ... from there I found Duktape. In my investigations, I chose to go with Duktape because of a variety of reasons ... not least of which is the level of C language integration and the currency of the language support. I also got chatting with the author of Duktape who turned out to be an exceedingly nice individual and every time I raised a question with him he was immediately there to help. And that went a VERY long way in my books.

Working against Duktape I got a large amount of function built including a large Duktape framework ... I was very pleased with the whole story. Unfortunately, a problem was encountered. When Duktape compiles JavaScript, the resulting compiled code is placed in RAM. This means that Duktape (as it stood in February) consumed a LOT of RAM. I had imagined that with 512K of RAM in the ESP32 that wouldn't have been an issue. However, the reality is that there is only about 200K of usable RAM for our apps. Next I found that creating sockets started using RAM and then I found that switching on Bluetooth and other advanced features ate more and more RAM to the point where I was running out of RAM. I also took the decision to write the ESP32 duktape framework ... in JavaScript ... which means that my wrappers ate a ton of RAM too.

Now ... with all that said, back in March I started hearing stories of a 4MByte RAM module ... and I paused my Duktape work waiting for that (which hasn't materialized yet). I am also in discussions with the Duktape author who has expressed some confidence that he may have a "compile to flash" option coming in a month or two.

Neil

Thanks Neil, that is very informative. I have experienced similar issues with Espruino.