BBC Micro:bit – Power Usage & “Mu” (an Off-line MicroPython Editor)

A good intro to the BBC micro:bit has been done by Andrew Mulholland at http://blog.gbaman.info/?p=711 and http://blog.gbaman.info/?p=727 .

Although there appear to be many good on-line tools for programming the micro:bit, one of the off-line tools is the “Mu” editor (“..a simple code editor for beginner programmers”) which uses MicroPython, details at http://codewith.mu/ (from where “mu.exe” can be downloaded).

[There is also a downloads directory at http://ardublockly-builds.s3-website-us-west-2.amazonaws.com/?prefix=microbit/windows/ , from which you can currently download “mu-2016-07-17_19_58_04.exe”] (as at July2016).

The “Mu” editor is all you need to start programming the micro:bit; (it is an off-line tool requiring no internet access once downloaded, and there is no need to register). For Windows 10, you just need to download the “mu.exe” (or “mu-2016-???.exe”) program, and then run it (ie. there is no need to install anything).

A history of MicroPython on the micro:bit can be found at http://ntoll.org/article/story-micropython-on-microbit . Interestingly this says that “Since hex files are a simple format we worked out a way of encoding Python scripts written in the editor in such a way that they can be inserted into the appropriate place in MicroPython's hex file.” If I understand correctly, this means that there is not really any “compilation” of your written MicroPython program, instead your script is just embedded into the fixed MicroPython hex file before everything is uploaded to the micro:bit. Thus effectively your scripts are just interpreted on the fly in the micro:bit. This also means the “Mu” editor can “compile/flash” your MicroPython code very quickly. (Currently I also note that no error checking seems to be done by “Mu” during this “compile/flash” process, so errors are hopefully trapped at run-time by the micro:bit itself, with error messages shown on its 5x5 LED-matrix.)

On computers running Windows, just plug the micro:bit into the USB port of your computer, and a new drive should appear under Devices and drives called “MICROBIT”. (ie. No extra drivers are required.)

The on-line editors seem to produce a file called “microbit (1).hex” or something similar, which then needs to be manually copied onto the above “MICROBIT” drive. However, the “Mu” off-line editor has a “Flash” button which automatically copies your software onto the micro:bit. I suspect that on re-boot the micro:bit moves this ???.hex file from the “MICROBIT” drive to an internal hidden drive from where it is run. (Note that once the micro:bit has rebooted itself, the ???.hex file does not show up on either the “MICROBIT” or “MAINTENANCE” drive.)

For a simple Hello-World program ( from http://microbit-micropython.readthedocs.io/en/latest/tutorials/hello.html ) just write the following 2 lines in “Mu”:

from microbit import *

display.scroll("Hello, World!")

then click on “Flash”. (NB. make sure you don't accidentally include any spaces at the start of either line, as such indents will confuse micropython and cause an error.)

If all is well, you should see the words “Hello, World!” scrolling across the micro:bit’s 5x5 LED-matrix.

Update: For the current Mu-editor, if you write a micropython program which is too big, when you click on the "Flash" button nothing seems to happen (ie. you don't get the "When the yellow LED stops flashing..." message, and nothing will get uploaded to your micro:bit). ie. There is currently no warning that your program is too long, instead the Mu-editor just does not do anything when you press on "Flash". For me this starts to occur when my program is greater than about 370 double-spaced lines. The solution is to reduce your code until pressing the "Flash" button results in Mu displaying the "When the yellow LED stops flashing.." message.

In Windows you can also (optionally) download and install an additional driver (see link in http://codewith.mu/ ) to allow the micro:bit’s USB connection to show up as a com-port, which you can then access with a serial-terminal-program. With this serial-terminal you can view “print()” output from your program, and accept “input()” (via your PC’s-keyboard). You can also use this serial-terminal to type MicroPython commands directly into your micro:bit, and see the result.

Wiki says “A read–eval–print loop (REPL), also known as an interactive toplevel or language shell, is a simple, interactive computer programming environment that takes single user inputs (i.e. single expressions), evaluates them, and returns the result to the user; a program written in a REPL environment is executed piecewise.”

However, note that downloading and installing the above USB-to-serial-port-driver and using REPL is NOT required if you use “Mu”, unless you want the extra functionality. (The above “Hello World” program will work fine without downloading/installing these extra drivers.)

The micro:bit can be powered via its small white-JST-battery-connector, which typically is connected to a battery pack containing two AAA-batteries (ie. nominally 3V).
On my micro:bit, when running the above simple “Hello-World” 5x5 LED-matrix program, I get:

* Battery-Power: everything seems to work from 1.9V: drawing 1.5-1.6mA when idle, and 2.0-2.2mA when scrolling the above “Hello-World” 5x5 LED-matrix program

* Battery-Power: up to at least 3.2V: drawing 1.8-2.0mA when idle, and 6-9mA when scrolling the “Hello-World” LED-matrix program.

(At 1.8V the 5x5 LED-matrix fails to light, BUT the current rises to a fixed approx 5mA, so I suspect that this low a voltage causes the micro:bit to enter a very strange mode. The 3.2V limit is the maximum I have tried, as it is the typical max one might expect from two alkaline AAA batteries). (Also note that I did not test the micro:bit’s Compass/Accelerometer/BluetoothRadio functionality using a 1.9V JST-battery-connector voltage.)

Thus, for 2x AAA alkaline batteries (say 1150mAh capacity each), a 2mA program (ie. no flashing LEDs) might run for about (1150/2/24) = 24days. However, using the LED-Display or Accelerometer or Compass or BluetoothRadio or other peripheral would reduce this.

You can INSTEAD also power the micro:bit from its 5V micro-USB port. (Note that you should disconnect the JST-battery-source BEFORE you connect the micro-USB power.) This USB-power also enables the USB-data-connection to your PC (allowing the micro:bit to show up as the “MICROBIT” drive). (Note also that the USB-data-connection is NOT enabled when you power the micro:bit from the JST-connector.)

On my micro:bit, again when running the above “Hello-World” 5x5 LED-matrix program, I get:

* micro-USB-Power: 5.0V: drawing 18-19mA when idle with a blank screen, and 25-30mA when scrolling the "Hello-World" LED-matrix program.

Update: [I originally had a micro:bit with a fault somewhere in its USB-power-regulation circuitry, as when I powered it from my computer’s USB (5.0v) it drew 250mA (ie. power about 1.25w) when idle, and the unlabelled IC on the right (next to the white-JST-battery-connector) got really hot (too hot to touch). I understand this is the power management chip. There are posts which say that this excessive heat eventually causes the micro:bit to fail (see www.suppertime.co.uk/blogmywiki/2016/03/microbit-worry/ ). (Although note that if powered from the white-JST-battery-connector, my faulty micro:bit didn't heat up, and worked mostly fine - except that the back "Button-R" only worked if using micro-USB-power, and didn't work when using JST-batter-power.) On my faulty “hot” micro:bit, in an attempt to delay any future failure, I succeeded in getting it to connect to my PC using a USB-Vcc of 3.5V (instead of 5V), at which this faulty micro:bit drew approx 160mA (ie. power about 0.5w). At this voltage, the above power management chip still warms up, but not as much (if not powered for too long), and the “MICROBIT” drive still shows up on my PC, allowing me to flash my programs. I also guessed that the USB receiver in the micro:bit was still cope with normal USB D+ and D- voltages safely even if being supplied with Vcc of 3.5V instead of 5V: as D+ and D- carry differential pulses I believe at worst pulled between 0V and 3.6V (which some texts say actually means 3.3V), This arrangement seemed to work for me, as this faulty "hot" micro:bit continued to work for a couple of weeks until I got it replaced.]

From https://www.microbit.co.uk/device : “Button R on the back of the BBC micro:bit is a system button. It has different uses. When you have downloaded and run your code onto your BBC micro:bit, press Button R to restart and run your program from the beginning. When you plug in your BBC micro:bit, it should appear as MICROBIT. If you accidentally hold down the reset button as you’re plugging in your BBC micro:bit, the BBC micro:bit will appear as a MAINTENANCE drive instead of MICROBIT. This is known as maintenance mode.”

In micro:python, this back "Button-R" causes your script-program to re-start from the beginning. However, it is also used in other modes to (for example) put the micro:bit into "Bluetooth-PAIRING" mode.

Update: [On my faulty "Hot" micro:bit (which drew 250mA when powered from the micro-USB-socket) this back "Button-R" did work ok when powered using the micro-USB-socket, but this button stopped working when powered using the white-JST-battery-connector. Therefore, for this faulty micro:bit, the "Button-R" did NOT restart my micropython scripts when on battery power, and only worked when using the micro-USB-socket power. However, for a properly working micro:bit, this back "Button-R" will re-start your micropython scritps fine if powered by battery OR micro-USB-socket power.]

From https://www.microbit.co.uk/device: “If you click on the drive while it shows as MAINTENANCE, you can see which version of firmware you have running on your BBC micro:bit. Firmware on your micro:bit should be up-to-date already. You can find the version of firmware in the 'version.txt' file on the micro:bit. Further information on the firmware can be found at https://developer.mbed.org/platforms/Microbit/#firmware .” (Although note that on my micro:bit, the version number was in a file called “DETAILS.TXT”.)

The DETAILS.TXT file on my micro:bit says “DAPLink Firmware - see https://mbed.com/daplink, Version: 0234, Build: Oct 12 2015 14:39:34”, which currently seems to be the most up to date version.

My micro:bit’s “MICROBIT” drive contained: DETAILS.TXT, AUTO_RST.CFT, MICROBIT.HTM, (dated 2004 or 2006)

My micro:bit’s “MAITENANCE” drive contained: DETAILS.TXT, AUTO_RST.CFT, HELP_FAQ.HTM (again dated 2004 or 2006).

The DETAILS & AUTO_RST files on both drives match, the MICROBIT.HTM file is a shortcut which links to www.microbit.co.uk; the HELP_FAQ.HTM is a shortcut which links to mbed.com