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
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.
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
yotta ready with:
0.18.2. OK, looks it is truly there and ready.
Step 2: Installing
Moving on, with installing required dependency for building images:
sudo apt-get install srecord
finished without any problems.
Step 3: Getting examples
git clone https://github.com/lancaster-university/microbit-samples cd microbit-samples
Step 4: Building examples
invoked from within samples working copy gave me this:
Results can be confirmed:
ls build/bbc-microbit-classic-gcc/source/*.hex -l
-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
[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
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:
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
Anyway, let’s move on and flash it:
cp build/bbc-microbit-classic-gcc/source/microbit-samples-combined.hex /media/adam/MICROBIT/ -v
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.