Rust Embedded terminology
Before we dive into programming the micro:bit let's have a quick look at the libraries and terminology that will be important for all the future chapters.
Abstraction layers
For any fully supported microcontroller/board with a microcontroller, you will usually hear the following terms being used for their levels of abstraction:
Peripheral Access Crate (PAC)
The job of the PAC is to provide a safe (ish) direct interface to the peripherals of the chip, allowing you to configure every last bit however you want (of course also in wrong ways). Usually you only ever have to deal with the PAC if either the layers that are higher up don't fulfill your needs or when you are developing higher-level code for them. Unsurprisingly, the PAC we are (mostly implicitly) going to use is for the nRF52.
Hardware Abstraction Layer (HAL)
The job of the HAL is to build up on top of the chip's PAC and provide an abstraction that is actually usable for someone who does not know about all the special behaviour of this chip. Usually a HAL abstracts whole peripherals away into single structs that can, for example, be used to send data around via the peripheral. We are going to use the nRF52-hal.
Board Support Crate (BSP)
(In non-Rust situations this is usually called the Board Support Package, hence the acronym.)
The job of the BSP is to abstract a whole board (such as the micro:bit) away at once. That means it
has to provide abstractions to use both the microcontroller as well as the sensors, LEDs etc. that
might be present on the board. Quite often (especially with custom-made boards) no pre-built BSP
will be available. Instead you will be working with a HAL for the chip and build the drivers for the
sensors either yourself or search for them on crates.io
. Luckily for us though, the micro:bit does
have a BSP, so we are going to use that on top of our HAL as well.
Unifying the layers
Next we are going to have a look at a very central piece of software
in the Rust Embedded world: embedded-hal
. As its name suggests it
relates to the 2nd level of abstraction we got to know: the HALs.
The idea behind embedded-hal
is to provide a set of traits that
describe behaviour which is usually shared across all implementations
of a specific peripheral in all the HALs. For example one would always
expect to have functions that are capable of turning the power on a pin
either on or off: to switch an LED on and off on the board or whatever.
embedded-hal
allows us to write a driver for some piece of hardware, for example a temperature
sensor, that can be used on any chip for which an implementation of the embedded-hal
traits
exists. This is accomplished by writing the driver in such a way that it only relies on the
embedded-hal
traits. Drivers that are written in such a way are called platform-agnostic.
Luckily for us, the drivers we will be getting from crates.io
are almost all platform agnostic.
Further reading
If you want to learn more about these levels of abstraction, Franz Skarman (a.k.a. TheZoq2) held a talk about this topic during Oxidize 2020: An Overview of the Embedded Rust Ecosystem.