Posted at 2020-04-27 by Andreas_Rozek

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

Posted at 2020-04-27 by Andreas_Rozek

Here are the results of process.env and process.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 }
> 

Posted at 2020-04-27 by Andreas_Rozek

Hmmm, I made some progress...

Adding an invocation of process.memory() to the beginning of updateDisplay 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

Posted at 2020-04-27 by @fanoush

if show() is slower than 100ms it probably gets queued up, try to increase the interval

Posted at 2020-04-27 by Andreas_Rozek

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 by setTimeout within updateDisplay (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?

Posted at 2020-04-27 by 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...

Posted at 2020-04-27 by Andreas_Rozek

My conclusions so far:

1. setTimeout seems to be terribly broken (I could not get it working at all)
2. 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 (as setTimeout is broken, see above)
3. the graphics library also seems to have its problems (drawString seems to work fine, but drawLine 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

Posted at 2020-04-27 by @gfwilliams

Hmm, that doesn't sound good. Espruino's pretty limited on the micro:bit (there's only ~6kB of RAM total) - I guess it's possible that something has grown and used up more of the available RAM so there isn't enough stack for it to work reliably?

How does 2v04 work?

Posted at 2020-04-27 by Andreas_Rozek

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, but graphics.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

Posted at 2020-04-27 by Andreas_Rozek

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.

Posted at 2020-04-27 by 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 one

This 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).

Posted at 2020-04-27 by Andreas_Rozek

Oh, what I found in my old notes from 1.85: Espruino on BBC micro:bit hangs quite soon when trying to run the ticker you mentioned in your video about Espruino on the micro:bit...

Thus, it seems to have been unstable in those days as well...