Great! I ask because I've been talking to Nordic and apparently there are some folks there that don't think Espruino is used in industry - it's nice to have a little ammunition when I next talk to them :)
I've just boosted the amount of flash dedicated to saved code - there was no reason for it to be that small in nRF52, so if you use a new firmware from the travis builds you should find the amount of memory available for saving has gone from 12k to 40k.
Hopefully newer firmwares will go a long way towards getting rid of 'MEMORY_BUSY' errors too.
On the IDE front, I figured out the issue - there's some really weird scoping issue when loading the main.js file in NW.js which means that the utf8 library doesn't load properly. I've got a fix which I'll roll into a new IDE release today - there's just something else I'd like to get fixed first as well.
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.
Great! I ask because I've been talking to Nordic and apparently there are some folks there that don't think Espruino is used in industry - it's nice to have a little ammunition when I next talk to them :)
I've just boosted the amount of flash dedicated to saved code - there was no reason for it to be that small in nRF52, so if you use a new firmware from the travis builds you should find the amount of memory available for saving has gone from 12k to 40k.
Hopefully newer firmwares will go a long way towards getting rid of 'MEMORY_BUSY' errors too.
On the IDE front, I figured out the issue - there's some really weird scoping issue when loading the
main.js
file in NW.js which means that theutf8
library doesn't load properly. I've got a fix which I'll roll into a new IDE release today - there's just something else I'd like to get fixed first as well.