Some kind of indication of PROGRAM Loaded

[Turgut Guneysu]

Hi John,

As I was working on my Battleship program, I experienced some things that were mildly annoying.

Since microBlocks loads the program to micro:bit automatically, and maybe because my program is on the LENGTHY side, there were instances where I would press the RESET key to restart the program, but it would not run correctly due to (what I am assuming) incomplete loading. In these cases, I would retry the RESET and then things would start running correctly.

The light on the back of the micro:bit blinks continuously during the program load, firmware upload, and program running in a tight Game Loop. So it is hard to tell positively when a program is completely loaded.

I also had instances where I would select the program from the File Open menu and double click it. The light would start to blink continuously but the program load would not finish. I would get a “not responding” message displayed at the program window title. After waiting more than a minute, I would disconnect and reconnect the USB cable, and pronto the program would display on screen and start running.

A similar problem also happens, in my case, as I was swapping two micro:bits and loading them with the same program code to test.

From plug-in to program start sometimes 3-10 secs time required in my case. If I press RESET too quickly after plugging micro:bit in, the program most definitely did not run correctly. After waiting a while then all was well again.

I will leave this to your evaluation. It is not a very critical thing, but it is confusing when one does not know why the program does not run after plug-in. My point being, some kind of “LOADING” and “LOADED” type of feedback might be helpful.

TG

[John Maloney]

Yes, I’ve seen this behavior too, and I agree, it is annoying – and also potentially confusing.

Some of what you describe is unavoidable – it simply takes time to write a large program into the micro:bit. As you say, more explicit, on-screen feedback to show the progress would be helpful.

It also sounds like there’s some sort of bug that causes loading to get stuck or fail in some cases. I’d especially like to figure out what is going on when disconnecting and reconnecting the USB cable results in the program starting right away. It sounds as though the program was completely written, but then the MicroBlocks IDE got hung. That might be the symptom of the serial port getting into a strange state. What OS are you using and what version? What’s your hardware? I’ve had reports of serial port hangs on Windows, especially when running on slower hardware.

It would be super helpful if you could figure out how to reliably reproduce the hang problem (i.e. the case where you need to disconnect and reconnect the USB cable to get it unstuck).

Also, if you’re running on Windows, you might check the MicroBlocks terminal window to see if there are any serial port error messages. If you’re on a Mac, you don’t normal see the terminal window, but I can tell you how to run MicroBlocks from the terminal so you can.

The light on the back of the micro:bit blinks continuously during … program running in a tight Game Loop.

Interesting that it blinks while running the Game Loop. Is your program using the “say”, “graph”, or “broadcast” blocks? All of those cause data to be sent to the IDE, which would explain the blinking light. If your program doesn’t do anything that sends data to the IDE, the yellow light should only blink once every second or so. That’s the IDE is polling to make sure the micro:bit is still connected and responding. Rapid blinking of the yellow light when your program isn’t sending any data may indicate that MicroBlocks has crashed and the IDE is trying to re-establish a connection to it. If that's what’s happening, I’d like to figure out why. MicroBlocks itself isn’t supposed to crash. An error in a script should just cause that script to stop and send an error code back to the IDE. But, of course, a bug in MicroBlocks itself can result in a crash. In that case, I’d really want to find and fix that bug.

‌

[Turgut Guneysu]

Some answers:

What OS are you using and what version? What’s your hardware?

It would be super helpful if you could figure out how to reliably reproduce the hang problem

I will work on this. I was encountering it pretty regularly while coding and testing my program. However, once finalized, I could not make it happen by simply switching micro:bits and loading it over and over again.

In the process of trying to figure this out, I came across a different combo where the command.com window disappears but the microBlocks editor keeps running OK:

1. USB icon with the GREEN circle is off (no GREEN circle) but the micro:bit is USB attached to the PC.
2. I load a big program.
3. I press the GREEN TRIANGLE to start running.
4. There normally is a cycle of displays on the command.com window that shows:
   Welcome to MicroBlocks!
   Restored xx scripts
   Started
   and the GREEN circle comes on and things run
5. However, if one hits the RESET on the micro:bit before the command.com displays complete or the GREEN circle is on, then the command.com window closes but things keep running.

The light on the back of the micro:bit blinks continuously during … program running in a tight Game Loop.

Your answer was spot on. I did have a bunch of debug displays during development cycle. Upon completion, I removed them and noticed that the continuous blinking disappeared. I guess I should have waited a bit before reporting. I will be keeping an eye on this and report again if it happens without the display commands.

‌

[John Maloney]

‌

Thanks for the update.

Interesting that pressing the reset button on the Micro:bit makes the Command window disappear. I hadn’t seen that before.