-
Hi folks,
given the low amount of free memory in a BBC micro:bit
>process.memory() ={ free: 280, usage: 20, total: 300, history: 0, gc: 0, gctime: 2.83813476562, blocksize: 12, "stackEndAddress": 536884560, flash_start: 0, "flash_binary_end": 258580, "flash_code_start": 260096, flash_length: 262144 }
is there an estimate of how much code may be sent to that device without causing a LOW_MEMORY error?
That code should also be able to be saved, of course.
Or, is there way to build larger code from smaller pieces (e.g. by saving individual functions rather than a whole bunch of them)?
Thanks in advance for any help!
With greetings from Germany,
Andreas Rozek
-
-
I meanwhile found the old firmware distributions and tried 1.85 - but apart from a different API (compared to 2.05) I often encounter communication failures (lost characters when uploading) which prevent me from testing...
[Update]
Communication errors can be solved by disabling "Reset before Send", but then the program runs havoc almost immediately => the old version behaves even worse than the new oneThis is strange as I made my first experiments with Espruino on BBC micro:bit with 1.85 - and I can't remember these problems (my boards are still the same and weren't touched since then).
-
Increasing interval length does not really help - both boards will eventually hang up.
Additionally: when trying to connect after a reset, I also often get the error message "Unable to retrieve board information. Connection Error?"
Even if that is followed by "Connected to Web Bluetooth, Espruino MICROBIT (No response from board)" that connection appears to be inoperable.
-
Hello Gordon,
I tried 1.95 (the latest one from the list of available downloads) and that behaved like 2.05.
The misbehaviour of
setTimeout
sounds critical, butgraphics.drawLine
might "just" have a hidden memory leak from what I found by my little tests.Oh, and, meanwhile, my own implementation of "drawLine" crashed as well (on the micro:bit, on Calliope it's still running - but presumably because that was started much later) - I will now try to increase interval length.
What also sounds weird is that both devices sometimes suddenly disconnect themselves from the WebBT connection.
With greetings from Germany,
Andreas Rozek
-
-
My conclusions so far:
setTimeout
seems to be terribly broken (I could not get it working at all)- code sent from the IDE (to RAM) should not be started immediately after uploading (the IDE seems to expect some response from the connected device which it might not receive otherwise). But you will have to use
setInterval
for that purpose (assetTimeout
is broken, see above) - the graphics library also seems to have its problems (
drawString
seems to work fine, butdrawLine
seems to be flaky)
My updated code
function currentXYZ () { return [2,0,5]; } var Buffer; function drawBar (x,Length) { for (var i = 0; i <= Length; i++) { var Bit = x+(4-i)*5; Buffer = Buffer | (1 << Bit); } } function updateDisplay () { var XYZ = currentXYZ(); Buffer = 0; drawBar(0,Math.max(0,Math.min(4,XYZ[0]))); drawBar(2,Math.max(0,Math.min(4,XYZ[1]))); drawBar(4,Math.max(0,Math.min(4,XYZ[2]))); show(Buffer); } setInterval(updateDisplay,100);
runs fine for much longer now than any other variant did.
With greetings from Germany,
Andreas Rozek
-
It's extremely weird:
if I change the last line of the above code to
setTimeout(updateDisplay,1000);
the BBC micro:bit does no longer hang up immediately after upload - but it also does not start unless a press RETURN once from within the Terminal area.
There must be s.th. going terribly wrong here...
-
Brilliant idea,
unfortunately, there must be more that goes wrong:
I order to make it right from the very beginning, I tried to replace
setInterval
bysetTimeout
withinupdateDisplay
(that saves me the "trial-and-error" approaches to find the proper interval whenever I change s.th. within the loop)The result looked like this:
var Gfx = Graphics.createArrayBuffer(5,5,1); Gfx.flip = function () { show(this.buffer); }; function currentXYZ () { return [2,0,5]; } function updateDisplay () { var XYZ = currentXYZ(); Gfx.clear(); Gfx.drawLine(0,4, 0,4-Math.max(0,Math.min(4,XYZ[0]))); Gfx.drawLine(2,4, 2,4-Math.max(0,Math.min(4,XYZ[1]))); Gfx.drawLine(4,4, 4,4-Math.max(0,Math.min(4,XYZ[2]))); Gfx.flip(); setTimeout(updateDisplay,100); } updateDisplay();
but did not work at all!!!! (when entered into the Editor area of the IDE and sent to RAM from there - which implies a "reset" before uploading)
So, I commented the
setTimeout
and tried again - and now I got the following message:>Uncaught Error: Too much recursion - the stack is about to overflow at line 4 col 41 Gfx.drawLine(0,4, 0,4-Math.max(0,Math.min(4,XYZ[0]))); ^ in function "updateDisplay" called from line 1 col 15 updateDisplay(); ^ Execution Interrupted >
Now, I'm completely lost (I do not have any pretokenization or other kind of minification switched on)
What makes it even worse: after crashing, I have to push the reset button of my BBC micro:bit in order to let it reappear in the scanned list of BT devices. Sometimes even several resets are necessary before I'm able to upload any JS code again....)
I'm now also trying to figure out whether the device itself is broken (which could theoretically be the reason for all these weird problems)
[UPDATE] my second micro:bit behaves the same...Any ideas?
-
Hmmm, I made some progress...
Adding an invocation of
process.memory()
to the beginning ofupdateDisplay
made my few lines of JS run stable for many more seconds - but in the end it still crashed...Is there any chance to work with Espruino on BBC micro:bit? Or does it simply have too little memory?
With greetings from Germany,
Andreas Rozek
-
Here are the results of
process.env
andprocess.memory()
>process.env ={ VERSION: "2v05", GIT_COMMIT: "990dac35", BOARD: "MICROBIT", FLASH: 262144, STORAGE: 2048, RAM: 16384, SERIAL: "a7508229-3abf344e", CONSOLE: "Bluetooth", MODULES: "" } >process.memory() ={ free: 276, usage: 24, total: 300, history: 11, gc: 0, gctime: 2.99072265625, blocksize: 12, "stackEndAddress": 536884560, flash_start: 0, "flash_binary_end": 258580, "flash_code_start": 260096, flash_length: 262144 } >
-
Ok,
I now have some code which crashes the BBC micro:bit within seconds:
var Gfx = Graphics.createArrayBuffer(5,5,1); Gfx.flip = function () { show(this.buffer); }; function currentXYZ () { return [2,0,5]; } function updateDisplay () { var XYZ = currentXYZ(); Gfx.clear(); Gfx.drawLine(0,4, 0,4-Math.max(0,Math.min(4,XYZ[0]))); Gfx.drawLine(2,4, 2,4-Math.max(0,Math.min(4,XYZ[1]))); Gfx.drawLine(4,4, 4,4-Math.max(0,Math.min(4,XYZ[2]))); Gfx.flip(); } setInterval(updateDisplay,100);
Does anybody have any idea why?
[EDIT] if the WebBT connection is kept, but the display runs havoc, the IDE's terminal sometimes issues
New interpreter error: MEMORY_BUSY
. Does this message help you?Thanks in advance for your effort!
Kind regards,
Andreas Rozek
-
Hi folks,
after many months of inactivity, I thought I'd give Espruino on BBC micro:bit another try and installed Version v2.05.
It worked in the very beginning (when doing some simple one- or few-liners from the Espruino Web-IDE), but after a few minutes I already got my first disconnect. Such sudden disconnects continued to occur - sometimes I even had to reset the micro:bit before it reappeared in the WebBT list of BT devices - but, initially, I thought, it would be my Mac (macOS is known for its horrible BT support) until I found the first weird pattern on the LED matrix.
Now, I'm quite sure that it's the micro:bit which crashes after a few minutes (usually less than 5) of activity.
Do you have any experiences with that version? As I remember, Espruino ran stable on the micro:bit several months ago (but I can't tell you the version number)
Do you know, which version runs stable?
Thanks in advance for any response!
Kind regards from Germany,
Andreas Rozek
-
-
-
-
-
Well, I was just experimenting with custom clock handles that needed this non-centric rotation point - but, of course, I could also do the required math myself.
Just tell me/us, if you plan to drop that feature. There are other ones which are more important (drawing a bitmap directly from file, for example...)
-
-
-
-
After some (purely syntactical) experiments, I found that getters/setters within IIFEs seem to be the problem. When trying
let Y = { _y:0, get y () { return this._y } }; print(Y.y); (function () { let X = { _x:0, get x () { return this._x } }; print(X.x); })();
(edited in the right section of the Espruino IDE, then uploaded to my Bangle.js) the
Y
-based constructs worked as foreseen (and even produced the intended output), but then theX
-based stuff failed.So, IIFEs seem to have their own (inner) capabilities?
-
-
Very interesting...
although the translation itself is horrible, it may indeed be "better than nothing".
It is impressive to see how far Google gets with keeping the formatting - although I have not looked into the details with all my annotations, embedded code etc. It won't help me anyway as my pages are created automatically using my own kind of CMS and I will have to translate all the building block individually.
Nevertheless, until then people may help themselves using this translator.
Thanks for this hint!
Hello Joern,
unfortunately not. Since time ran out (and my primary goal was to establish s.th. like a "remote control" for BBC micro:bit or similar between PC and board) I switched to the built-in BT services and used them (see https://rozek.de/Microcontrollers/MicroBit/BoardControl/index_de.html, German only, however) Those services turned out to run stable, whereas Espruino did not.
Meanwhile, I bought an Oxocard, which looks much more promising (not from an Espruino perspective, but from its hardware in general) - but now, I first have to complete my online lectures for this semester before I'll find some time to get my hands on it.
With kind regards,
Andreas Rozek