micro:bit problems?

If you have a problem with micro:bit, one can post here.
As a patron of Espruino, then most eyes will be watching your problem, and, together with Gordon, get some reply back.
The kick back for me is, that if there is a problem, then I get to see it as well so I do not get a problem at some stage: there is no self-less act :)

So here is a question, its not really a problem. I understand it has very few JSVars (300 or so?). I think its a very cool platform -- have you done some interesting projects with this limit? If its just for one off things (like a bluetooth button, and or using its display), it could still be really fun....so curious about its utility.

(I'm also a patron ;)

It has some limits due to the JSVars so I have just used it to show kids another way of using a micro controller with the espruino on board javascript where the immediate access to programming contra compile and download

Ok thats great! I actually am developing a workshop for kids as well -- might be a good choice. Thanks for the feedback.

Hi! It'll still work great with Web Bluetooth: http://www.espruino.com/Puck.js+Web+Bluetooth

So you can actually use it as an IO board really easily - for instance controlling robots/etc from a web page.

If you're careful, those 300 vars can still go a long way (especially since functions can now be stored in ROM) - there's a post on here where I hacked a cheap chinese DO003 OLED wristwatch (which uses the same 16kB processor) to run Espruino.

Thats great to know! I suspect I'll agree with you about the 300 vars on that platform, especially for kid projects, so will order a couple of micro:bits to start playing with them...I'll order a puck.js soon as well -- it looks REALLY cool. The low power consumption is particularly compelling on it.

I've found it very hard to get any useful code running on an Espruino micro:bit, once a module or two is required. The one thing I really worked on was advertising temperatures from some DS18B20 probe on BLE. Absolutely couldn't get it to fit, even with manual stripping and minification of the DS18B20 module.

Of course I could just use one of my precious Pucks, but it'd be a waste... they're overkill and I've got three or four spare micro:bits I'm not using. However, I'm just going to use a few bare ESP32 modules instead.

That's a shame - yes, I guess adding modules can suck up a lot of memory. Doing the 'save on send' and 'modules as functions' tricks in the IDE can free you up a lot of RAM though.

DS18B20 is interesting - the module itself could be insanely simple (just a few lines) but it's been added to over the years with features most people won't use. I guess it might make sense to add a DS18B20_minimal module? Same for a few others... any thoughts about naming?

I'll give it another go, now that I've got ESP32 functioning for what I want... the micro:bits have the benefit of battery connectors. It's just a real shame they went with the 16kB variant rather than the 32kB.

"Modules as functions" gave me trouble at the time, so I cut-and-pasted a very stripped-down DS18B20.js into the top of the source code, and minimised the code manually (still using Esprima et al., though)

I think for a restricted platform like micro:bit, almost all modules are going to be a problem as you don't want to compromise the capabilities of those modules for more capable boards, but not maintain two entirely separate trees.

Regardless, _minimal confuses with .min. Maybe, _basic? _barebones?

Yes, _basic could work. Shame that it still had trouble even with a cut-down driver.

It is frustrating about the 16k/32k variant - instead of 3.6k for JS code you'd have had nearer 20k!
I guess Nordic were giving the chips away for free, but if they'd been purchased it wouldn't have made much difference to the BOM at all.

It's too bad JSCush doesn't work with Espruino. Could be amazing for a small system like the nicro:bit. This was developed for one of those JavaScript 1k competitions.

http://www.iteral.com/jscrush/

Also I noticed recently that there was a "compile" option built into the IDE (using "compile" in your code) for the Nordic chips -- I assume it doesn't work with the ESP series. But for the micro:bit, would there be an advantage to using this feature? I understand it works on just a subset of the implemented javascript, and is more aimed at gaining speed, than memory...

Interesting - it might be the lack of with that causes problems when decompressing? Also it'll generate a huge sparse array before rejoining, which would use up all the available memory for much over 1kb. By rewriting the decompressor you could almost certainly still use it though.

And yes - the 'compile' option only works for ARM-based micros, and I don't think it works on nRF51(perhaps not even nRF52) because of the way functions are linked in at the moment.

To be honest it uses significantly more memory compiling. I did some tests, and minified JS code is actually significantly more efficient than almost everything else, including Mozilla's bytecode.

As an aside, one interesting option is actually to ban the use of character codes 128 and up in normal (non-string) code (which I don't think is even an issue) and to then use those in a similar way to your JS packer to pre-tokenise reserved words. It could allow Espruino to store code in an amazingly compact way, while increasing execution speed quite a lot.

Of course it'd then blow away comments, formatting, etc - but on some platforms I guess that wouldn't be a problem.

On another attempt, I juuuuuust managed to fit DS18B20 monitoring and a basic BLE advertising wrapper into a micro:bit, but it came down to trimming out individual characters out! It really is tight.

@Gordon Ok thats really interesting. For JSCrush -- I didn't think about that -- but yes it does actually use a textarea to buffer its output before putting it all back together. So I'm not sure how you would get around that. Also thanks for the details on the compiling. As for your suggestion about banning character codes above 128 -- that's a little bit bigger than a rainy day project :P Maybe I'll hack around with it at some point :)

@tom.gidden Interesting feedback. I'd be surprised if something interesting couldn't be done with 350 JSVars on the micro:bit -- though your point about libraries is well taken. I'll play around with it -- I have a BME280 I'd like to hook up to it...