This is description of my attempt to use C++ to program BBC micro:bit device.

After seeing my son playing with it using the online programming tools, I’ve decided to do the real programming on it using offline toolchain, command-line tools and C++, just to prove myself and the whole world I can master this sweet board, and… generally feel better.

The principle of how-to start is not difficult to find, there are couple of google search results. I have chosen to follow this site from Lancaster University.

Step no 1: Installing yotta

OK, so there we go. I know that for a platform Cortex-M0 class MPU we will be eventually producing ELF file, so GCC (or ARMCC) compiler is going to be involved. Surely compiling by hand is not-an-option, so some kind of build system is required. But… Let’s have a look of what we have here.

The official documentation for yotta reveals some details on what it is and how it works. Yota for that project will work, as long as you have CMake installed. The CMake will be invoked with Ninja generator. Ninja will be interpreting its makefiles and will be eventually invoking our GCC compiler. Wait! yotta itself is written in Python. So we have one of the smallest platform on the world, and the number of layers of indirections for the source file compilations will look like this:

Python > yotta > CMake > Ninja > g++ > some-file.cpp

Hmm. Not to much? Off course, as with any such a pyramidal system, the transparency and ability to get out potential diagnostic information to solve problems raises my concern, but maybe it’s just me…

Anyway. Let’s proceed. I’ve installed yotta and required build dependencies on my Linux (Ubuntu 16.06) box with:

sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa
sudo apt-get update
sudo apt-get install gcc-arm-embedded
sudo apt-get install python-setuptools cmake build-essential ninja-build python-dev libffi-dev libssl-dev 
sudo apt-get install python-pip 
pip install yotta 

Getting yotta ready with:

yotta --version

gives 0.18.2. OK, looks it is truly there and ready.

Step 2: Installing srecord

Moving on, with installing required dependency for building images:

sudo apt-get install srecord

finished without any problems.

Step 3: Getting examples

That’s easy:

git clone https://github.com/lancaster-university/microbit-samples
cd microbit-samples

Step 4: Building examples

yotta build

invoked from within samples working copy gave me this:

Results can be confirmed:

ls build/bbc-microbit-classic-gcc/source/*.hex -l

returns this:

-rw-rw-r-- 1 adam adam 494768 Jul 31 00:10 build/bbc-microbit-classic-gcc/source/microbit-samples-combined.hex
-rw-rw-r-- 1 adam adam 211160 Jul 31 00:10 build/bbc-microbit-classic-gcc/source/microbit-samples.hex

OK, good to go.

Step 5: Connecting the device

The nice thing about micro:bit is that is comes with built-in flasher/programmer and you only need to connect it to the host PC over USB cable, to be able to run your program on it.

The procedure is as simple as copying a HEX file to the mounted microbit’s filesystem. I’ve decided to connect the micro:bit to the USB socket in my keyboard. teh dmesg revealed:

[134646.236021] usb 2-2.1: new full-speed USB device number 7 using ehci-pci
[134646.329289] usb 2-2.1: New USB device found, idVendor=0d28, idProduct=0204
[134646.329292] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[134646.329295] usb 2-2.1: Product: MBED CMSIS-DAP
[134646.329298] usb 2-2.1: Manufacturer: MBED
[134646.329301] usb 2-2.1: SerialNumber: 9900023431324e45002290190000003500000000ccf928bd
[134646.329443] usb 2-2.1: rejected 1 configuration due to insufficient available bus power
[134646.329446] usb 2-2.1: no configuration chosen from 1 choice

Hmm. Surprise here. It looks like there is higher energy consumption required then I though. I’m sure my keyboard port is able to deliver approx. 200mA to USB-powered devices connected to its ports, and I truly didn’t expect more than that required for a such board to draw.

After re-connecting the device to direct USB port in the PC, I could see it’s filesystem under /media/adam/MICROBIT.

At this point, I was simply curious what is a the current requirement micro:bit USB driver tells to the USB host/hub. Let’s see:

lsusb

gives, amongst others, this:

...
Bus 004 Device 005: ID 0d28:0204 NXP LPC1768
...

so one more time:

lsusb -v -d 0d28:0204

and then in the output, int the Configuration Descriptor section we have:

Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          122
    bNumInterfaces          4
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA     <--- here !

OK, that explains the behaviour on my first connection attempt a bit. However, I think there is some miss-reporting going on there. The micro:bit specification on this power supply documentation page suggests that the board should not draw more than 120mA. This is the value I would expect to see in the USB device descriptor.

Step 6: Flashing the micro:bit board

Anyway, let’s move on and flash it:

cp build/bbc-microbit-classic-gcc/source/microbit-samples-combined.hex /media/adam/MICROBIT/ -v

OK, the micro:bit blinked for a moment with its yellow LED and after a seconds, the HELLO WORLD ! :) message was scrolled on it’s LED matrix display. Tada!!!

Now, that was following steps found on other pages. Let’s try to see of what is the code that we’ve compiled and run.