micro:bit C toolchain explained, part 1. ninja & cmake.
Last updated: Jan 23, 2023
December 2020: I wrote this post when only v1 of the micro:bit existed. I haven’t yet checked to see if the contents are still valid for the toolchain used to program v2 of the micro:bit.
I use the offline build tools from Lancaster University for compiling and building C-code for the BBC Micro:bit board. I used the toolset without really understanding what was going on under the hood. I spent some happy time fixing this. Understanding our tools gives us a better chance of fixing things when they fail. I hope to pass on what I learned here.
So you have written some C code to go onto your micro:bit. Great. Now how does your beautiful prose get converted into the executable (often called a binary) file that can be copied onto the micro:bit?
The components of the toolchain that are unleashed upon your unsuspecting C code are shown below. Let’s start at the bottom.
Offline tool chain for building an executable from C code for the micro:bit
The ‘file to go to micro:bit’ is the end product of the chain of build tools and the Gnu C compiler (called gcc) shown above. This is the file that you copy to your micro:bit and is automatically executed when you power up the micro:bit. Let’s talk about gcc.
gcc
gcc stands for the Gnu C Compiler. If we write a simple ‘hello world’ C program contained in a single file to run on your workstation, telling your C compiler (in our case gcc) how to build the executable can be done in a single command. For example, the command gcc -o hello hello_world.c
creates an executable file called ‘hello’ from a C program in a single file called hello_world.c, using gcc to do the compiling and linking. It gets more complicated when there are multiple files in the project. As we are using the micro:bit, there will be multiple files as many C files need to be brought into your project to enable the code to be built to run on the micro:bit hardware.
gcc is used to do the compiling and linking of your C code and the supporting libraries that are needed to enable the code to run on the micro:bit. gcc comes as standard with most distributions of Linux. But something has to tell gcc what files how to assemble the general mish-mash of interdependent files and libraries. This is what ninja does. ninja is a ‘build tool’. Let’s discuss what build tools are.
build tools
To understand the rest of the blocks in the toolchain, we need to have a little chat about build tools. A build tool looks for instructions in a text file, which is often called a build file on how to build ‘something’. That something could be how to use a compiler to compile and link files written in C, or for indeed another language. That something could also be how to build the instruction text file for a different build tool. This , which will then go on to do ‘something else’.
The build file contains a list of rules, such as the flags and controls to run the compiler with. It also contains a list of build statements which say how to build each of the files necessary to produce the output.
There are many different build tools. The micro:bit toolchain uses several. ninja, cmake, yotta and make are all build tools. Each of these tools looks for a text file specific to that tool. Here’s a little table for each build tool command and the corresponding build file that it works with.
build tool | build file |
yotta | yotta_config.json |
cmake | CMakeLists.txt |
ninja | build.ninja |
A build tool can often be used for building more than one type of language or thing. Let’s make build tools clearer by looking at how we use the ninja build tool to build a simple C project.
ninja
In the micro:bit toolchain, the ninja build tool uses a build file called build.ninja to instruct gcc on how to compile and link all of the project’s C files. Entering ’ninja’ at the command line causes the contents of this file to be processed by the ninja build system. The build.ninja file contains details of the interdependencies of the files that are used to create the binary that we want to load onto the micro:bit.
Let’s look at how ninja could be used with a simple three file C project outside of the micro:bit system. Consider a simple example project, split across three files. The three files are called array.c, display.c and display.h. This example runs on your workstation, not on the micro:bit. I’m trying to keep it simple to show what ninja does and what a simple build.ninja file looks like. We will use this example to help explain some of the other build tools as well.
array.c
#include <stdio.h> #include “display.h”
int main() { int v[5] = {1,2,3,4,5}; display_arr(v, 5); return 0; }
display.h
#ifndef DISPLAY_H #define DISPLAY_H
void display_arr(int *arr, int len);
#endif
display.c
#include <stdio.h> #include “display.h”
void display_arr(int *arr, int len) { for (int count=0; count<len; count++) { printf(“arr[%i] = %i\n”, count, arr[count]); } }
We can see that the files depend on each other. To build these three files into a single executable we need to tell gcc how each file depends on other files. An example build.ninja file that will compile and link the three example files to create an executable called ‘array’ is shown below.
build.ninja
cc = gcc cflags = -Wall -g rule compile command = $cc $cflags -c $in -o $out
rule link command = $cc $in -o $out
build array.o: compile array.c build display.o: compile display.c build array: link array.o display.o
default array
Putting all of these files into the same directory and typing ninja
will create the following output:
[3/3] gcc array.o display.o -o array
You will find a new file called ‘array’ in the same folder. This is an executable file. Typing array
at the command line gives this unexciting output:
arr[0] = 1 arr[1] = 2 arr[2] = 3 arr[3] = 4 arr[4] = 5
ninja is a relatively recent build tool. Traditionally the make build tool is used to build C programs. I will cover this tool in part 2 and show how this tool can be used to automate loading your code onto the micro:bit. However, with the micro:bit, ninja is used here. I’ve read that ninja offers about a 10x increase in speed of building the executable for large projects compared with make.
In our example above, I wrote the build.ninja file by hand. But how do we create this build.ninja file for our project? As I mentioned, building an executable for the micro:bit requires a bunch of C files and libraries to be compiled and linked with the source code that we write.
At the top of the ninja website, it states that ninja ‘is designed to have its input files generated by a higher-level build system’. In our case, this is done using the CMake build tool. So CMake produces the build.ninja file. Let’s have a look at CMake.
CMake
CMake is used to create the build.ninja file. That’s right - we are using one build tool to create the build file for another build tool to do something. There is a lot of this going on in the micro:bit build system. CMake can generate the build instruction files for a variety of build tools. Type cmake --help
and look at the list of generators at the bottom. CMake uses the Ninja generator to generate the build.ninja file.
Let’s use CMake to create a build.ninja file for our previous example C code. In the directory with the C files, create a file called CMakeLists.txt with the content below.
CMakeLists.txt
project(array) add_executable(array array.c display.c)
Two lines only! Create a directory called build_ninja and cd into this. Then type CMake .. -G "Ninja"
. The “..” part will look for the CMakeLists.txt file in the directory above where you are now, then use the contents to create the build.ninja file. You will see a lot of new files are created including a build.ninja file.
The build.ninja file I wrote by hand earlier contains 10 non-blank lines. The new build.ninja file created by CMake contains 95 non-blank lines! Granted, a lot of them are comments, but still…. One of the first lines in the new build.ninja file is include rules.ninja
. This file contains an extra 44 non-blank lines. So we have moved from 10 lines to a total of 95 + 44 = 139 lines. I included rules.ninja as a build file in the diagram at the top of this page as this file becomes part of the build.ninja file.
The next obvious question is ‘how is the CMakeLists.txt file created for the micro:bit build system’. This is done by yotta.
End dribble
Right, this is enough for one post.
In part 2 we will discuss yotta and the directory structure of the micro:bit C projects.
Additional reading
One good website that helped me figure out the programming toolchain, about 2/3 of the way down the article is https://hackernoon.com/the-first-video-game-on-the-bbc-micro-bit-probably-4175fab44da8.