The micro:bit page
Copyright © 2019–21 J. M. Spivey. All rights reserved.
This page is Grand Central Station for micro:bit hardware documentation. I have tried to include a copy of every document I used in writing the book, or at least a link to it. Where a local copy exists, a link to it is shown in the text below, and the source link is added at the end of the sentence. I have included copies and links in good faith, but copyright holders are welcome to email me and ask for material to be removed.
The micro:bit is best thought of as a system with three layers:
- The processor core is a Cortex-M0 (or on V2, a Cortex-M4) developed by ARM.
- The microcontroller chip, an nRF51822 (or for V2, an nRF52833) developed by Nordic Semiconductor, extends the core with a collection of peripheral interfaces.
- The micro:bit board, developed for the BBC, adds external components like buttons, lights, and an accelerometer and magnetometer on an I2C bus. The V2 board adds a microphone, a loudspeaker and a touch sensor.
This page contains exclusively documentation of the micro:bit itself: for information on the tool setup for programming it, see the software setup page.
The Cortex-M0 (V1) or Cortex-M4 (V2) core is an ARM processor, with sixteen 32-bit registers and a RISC-style instruction set. Like other microcontroller-oriented versions of the ARM, it omits the standard 32-bit encoding of the instruction set, and executes only programs written in the more compact 16-bit Thumb encoding. The V2 processor adds its own set of 32-bit Thumb2 instructions, so that programs contain a mixture of 16 and 32-bit instructions; this is different from the standard, "native" encoding used on the Raspberry Pi, where every instruction is 32 bits.
- ARM architecture reference manual for ARMv6-M, describing the Cortex-M0 instruction set (source).
- Quick reference card (source).
- Generic user guide for Cortex-M0 (source).
- Technical reference manual for Cortex-M0 (source).
Note that the nRF51822 does not have a SysTick timer (you have to use one of the other timers instead), and does not have a Vector Table Offset Register (VTOR) for the interrupt controller, so that the vector table is always located in Flash at address 0. We follow the same restrictions with the software for V2.
- ARM architecture reference manual for ARMv7-M, describing the instruction set implemented on Cortex-M4 (source). The earlier instruction set is a subset of this one, so no harm will result if you use the shorter and simpler ARMv6-M manual as a reference when programming.
- Generic user guide for Cortex-M4 (source).
- Technical reference manual for Cortex-M4 (source).
- A chart showing Thumb instruction encodings. To use this chart, begin with table [A] in the top left, and find the entry identified by the first hexadecimal digit of the instruction at the left, and the second digit at the top. This will either identify a specific instruction, with assembly language syntax given at the right of the table, or give you a reference to one of the other tables [B] to [E]. In each table, the first hex digits of the instruction are shown to the left to the table, and sometimes a further digit at the top. The notation r1 or r2 denotes a low register, one of
r7, while r/h1 denotes any register, including
pc. The notation
#4*imm8denotes an 8-bit immediate field whose (unsigned) value is multiplied by 4 – so it can express the values 0, 4, 8, ..., 1020. All immediate fields are unsigned, and all branch displacements are signed.
- A home-made list of common Thumb instructions.
For Version 1
The nRF51822 contains an implementation of the Cortex-M0 processor core that runs with a 16MHz clock, together with 16MB of RAM and 256MB of read-only flash memory. It also contains several peripheral interfaces, including a UART, bus interfaces for I2C and SPI, a hardware random number generator, and a 2.4GHz radio interface. The processor has the single-cycle multiplier option.
- Product specification for the nRF51822, containing the mechanical and electrical parts of the datasheet (source).
- Reference manual for the nRF51822, containing detailed programming information for the peripheral interfaces (source).
- Product anomaly notices for the nRF51822: version 3.2, version 2.4.
Handy Q&A from the Nordic site:
For Version 2
The nRF52833 contains an Cortex-M4 core running at 64MHz, with 128kB of RAM and 502kB of flash ROM. It also contains a richer set of peripherals than the nRF51822, but most of the peripherals retained from the nRF51 family can be programmed identically.
- Product specification for the nRF52833 (source), containing both electrical and programming information.
- Migration guide for moving programs from the nRF51 family to the nRF52 (source).
- 25 LEDs, arranged in a 5x5 matrix. Electrically, the 25 LEDs are wired as a matrix with three rows and up to nine LEDs in each row, in a seemingly irregular pattern. Only one row can be used at a time, so displaying an arbitrary image requires patterns in the three rows to be illuminated in rapid succession, under processor control. On the V2 board, the LEDs have a more orderly logical arrangement in five rows of five.
- two tactile switches, labelled A and B.
- a UART interface, connected to a host computer via USB.
- a 3-axis accelerometer chip MMA8653FC, connected to the nRF51822 via an I2C bus. Product page, datasheet (source).
- a 3-axis magnetometer chip MAG3110, connected to the same I2C bus. Product page, datasheet (source)
- Alternatively (on more recent boards), a single chip LSM303AGR with a different I2C address that combines an accelerometer and a magnetometer. Product page, datasheet.
There is also an edge connector that exposes some of the nRF51822 pins, including the I2C bus and an SPI bus, for connection of external components.
The following table gives the correspondence between the edge connector pads and bits in the GPIO register of the Nordic chip. Predefined constants
PAD1, ... in the header file
hardware.h correspond to values 3, 2, ..., so it is rarely necessary to use these values directly in programm code. The pin numbers on the chip are not needed unless you want to design your own circuit board.
|Pad on board||Pin on chip||Bit in register||ADC channel||Function|
In addition, there are a number of test points on the V1 board that give access to interesting signals, including the TX and RX lines of the UART.
In fact, the micro:bit board contains a second ARM microcontroller chip, an NXP (was Freescale (was Motorola)) KL26Z – more powerful than the nRF51822 – that provides the USB interface, as well as a voltage regulator for the 3.3V supply used by the rest of the board. It does its job invisibly, and we will not need to pay any attention to it. (But if you should short the 3.3V and ground terminals of the board, this is the chip that will get hot. Don't try it!)
The V2 board has the same hardware elements as the V1 board, but adds a microphone, a loudspeaker and a touch sensor: driving these is left as a challenge in this book. A schematic for the V2 board is available.
- The KL26Z on the V1 board is replaced by a more powerful KL27Z on the V2 board, but as before we will become involved with it. The 3.3V supply on the V2 board is provided by a separate LDO voltage regulator.
- The display on the V2 board is wired more logically as a 5 × 5 array, with the controlling pins spread across both GPIO device registers. Appropriate changes to the driving software are explained in each experiment.
The pins of the V2 board (or, properly speaking, the solder balls on its BGA package) are wired to pads on the board differently from the V1. The differences are reflected in different definitions in the file
hardware.h, so that few changes to actual programs are needed. In the table, the notation
a.b denotes bit
b in port
|Pad on board||Pin on chip||Bit in register||ADC channel||Function|
The V2 board has test points like the V1 board, but many of these are covered in black solder mask for safety, so it is harder to solder to them.
The supplied software for the micro:bit itself has three layers.
- An instance of the MBED library.
- An additional layer of device drivers written by programmers at the University of Lancaster, including a process scheduler.
We shall use none of this software, but it is useful to plunder the source code (especially the Lancaster library) for concrete examples of device programming. The MBED library and the Lancaster library use C++ to provide wrappers for lower-level features, following the pattern of initialising the hardware by declaring an instance of the driver class. We avoid this, and instead prefer to work with the underlying code, which is in each case written in pure C.