-
Yeah, it's a great fit for what we're doing... easy to hack around with the pins and prototype stuff, and fairly straight-forward to move to a "production" script once everything is good.
I hadn't noticed jspEvaluate(), but I think I'm happy with what we came up with despite the 64KB restriction on each module and the clear abuse of the PRECOMPILED_OBJS make variable. (Just noticed I have the jsvUnLock() calls commented out - whoops!)
Having it compile into the flash image is great, and having it not pollute the global namespace is very handy. We'll likely be adding some of the minified modules in a similar way if you don't beat us to it. When you have a lot of spare flash space, having a selection of the modules baked in and require()able without using much RAM or needing the IDE will be quite nice.
I had to do horrible things to the IDE to get it to work on FreeBSD since chrome.serial.getDevices() doesn't work (basically, I hard-coded a list of serial ports into EspruinoTools/core/serial_chrome.js) it would be nice if there was a way to connect to a serial port by name without having to go through a picker, but it seems to be working though a test using require("Font8x16").add(LCD) seems to hang Espruino... haven't looked to see why yet.
Great fun, and once we get the radio working, I'll post an update.
You are reading a single comment by @k6bsd and its replies.
Click here to read the full conversation.
k6bsd
That's awesome - thanks for posting up! This is one of the things I hoped Espruino would get used for (making consumer electronics 'hackable') but as far as I know you're one of the first people to do it.
And yes - for running JS straight out of flash, just do as you've said - or you can exec straight from a C str: https://github.com/espruino/Espruino/blob/master/src/jsparse.h#L67
If it's a 'static' string (or memoryarea) the interpreter will know, and when functions are defined the function decl will still take up RAM, but all the code inside that function will stay in flash.