The SPI bus can be something of a problem because it doesn't have a well defined standard that every device conforms to. Even so if you only want to work with one specific device it is usually easy to find a configuration that works - as long as you understand what the possibilities are. 

Now On Sale!

You can now buy a print edition of micro:bit IoT in C.

You can buy it from:

USA and World


 The full contents can be seen below. 

Chapter List

  1. Getting Started With C/C++
    Anyone who wants to use the BBC micro:bit to its full potential as an IoT device needs to look outside the coding environments provided by its own website. As an mbed device, however, the micro:bit  is capable of being programmed in C/C++. Here we look at how to use the mbed online compiler for a simple demo program.

  2. Offline C/C++ Development  
    We have already discovered how to use the online editor to create a C/C++ program. Now we are going to move to the desktop with an offline approach. This has the advantage that we can use any tools we care to select and no Internet connection is needed.
  3. First Steps With The GPIO 
    The most basic task when working with the micro:bit is controlling the I/O lines. This isn't difficult if you use the framework provided but there some subtle points to watch out for. This chapter looks a the basics of using the GPIO.

  4. Working Directly With The Hardware - Memory Mapping. 
    The framework makes working with the GPIO and other devices as easy as it can be but there are many layers of software to go through before you get to the hardware. Writing directly to the hardware can make things up to ten times faster and give you access to things that their framework doesn't. It is also an educational experience to deal with the raw hardware directly.

  5. Pulse Width Modulation, Servos And More
    In this chapter we take a close look at pulse width modulation PWM including, sound, driving LEDs and servos.

  6. I2C
    The I2C bus is one of the most useful ways of connecting moderately sophisticated sensors and peripherals to the any processor. The only problem is that it can seem like a nightmare confusion of hardware, low level interaction and high level software. There are few general introductions to the subject because at first sight every I2C device is different, but here we present one.

  7. I2C Temperature Measurement
    Using I2C devices is fairly easy once you have successfully used one - and hence know what information you need and what to look for in a working system. In this chapter we use the HTU21D temperature and humidity sensor as a case study of I2C in action. It also happens to be a useful sensor.

  8. A Custom Protocol - The DHT11/22

  9. The DS18B20 - One Wire Bus

  10. The SPI Bus
    The SPI bus can be something of a problem because it doesn't have a well defined standard that every device conforms to. Even so if you only want to work with one specific device it is usually easy to find a configuration that works - as long as you understand what the possibilities are. 

  11. SPI MCP3008/4 AtoD   
    The SPI bus can be difficult to make work at first but once you know what to look for about how the slave claims to work it gets easier. To demonstrate how its done let's add eight channels of 12 bit AtoD using the MCP3008.

  12. Serial Connections
    The serial port is one of the oldest of ways of connecting devices together but it is still very, very useful. The micro:bit has a single serial interface but it can be directed to use any of the GPIO piins as Rx and Tx. 

  13. WiFi 
    The micro:bit has a radio that works in Bluetooth LE and point-to-point ad-hoc mode, but at the moment it lacks WiFi connectivity. The solution is to use the low cost ESP8266 to make the connection via the micro:bit's serial port. 

  14. LED Display 
    The micro:bit's LED display may only be 5x5 but it is very versatile. If you want to make use of it directly then you are going to have to master some lower level functions.


The micro:bit has two SPI bus devices built into its processor a bus master and a bus slave. If you want to connect the micro:bit to SPI devices then it is the bus master that is of interest. If you want to use the micro:bit as a device connected to some other controller then you need to have it acting as a slave. This second scenario isn't as common and in this chapter we concentrate on using the micro:bit as a bus master. 

SPI Bus Basics

The SPI bus is very strange but commonly encountered as it is used to connect all sorts of devices from LCD displays, through real time clocks and AtoD converters.

It is strange because there is no standard for it and different companies have implemented it in different ways as a result you have to work harder to implement it in any particular case. However it does usually work which is a surprise for a bus with no standard or clear specification.

The reason it can be made to work is that you can specify a range of different operating modes, frequencies and polarities. This makes the bus slightly more complicated to use but generally it is a matter of looking up how the device you are trying to work with implements the SPI bus and then getting the micro:bit to work in the same way. 

The bus is odd in another way - it does not use bidirectional serial connections. There is a data line for the data to go from the master to the slave and a separate data line from the slave back to the master. That is instead of a single data line that changes its transfer direction there is one for data out and one for data in. 

It is also worth knowing that the drive on the SPI bus is push-pull and not open collector/drain. This provides higher speed and more noise protection as the bus is driven in both directions. Also you don't need pullup resistors.

There is a bidirectional mode where a single wire is used for the data - the micro:bit doesn't support this.

The standard signal lines are

  • MOSI Master Output Slave Input i.e. data to the slave
  • MISO Master Input Slave Output i.e. data to the master
  • SCLK Serial Clock which is always generated by the master

There can also be any number of SS - Slave Select - or CE Chip Select - lines which are usually set low to select which slave is being addressed.

Notice that unlike other buses I2C for example there are no SPI commands or addresses - only bytes of data. However slave devices do interpret some of the data as commands to do something or send some particular data. 

The micro:bit has two SPI bus Masters but only one is exposed on the GPIO connector and while there are no standard CE lines although it is easy an logical to assign Pin 16 to this task. This means that in principle you can only connect one SPI device to the micro:bit although this is a restriction that is easy to overcome by using additional GPIO lines. 

The second SPI bus Master can be used just as easily as the first but you will have to allocate four GPIO lines to it and this is certain to mean loss of other functions.


In principle the SPI bus master hardware can be connected to any four GPIO lines but the  pins that are normally  are 

SPI Bus Pins

Notice that the use of Pin 16 isn't a mandatory and it isn't part of the usual pin allocation lists or diagrams. The data transfer on the SPI bus is also slightly odd. What happens is that the master pulls one of the chip selects low which activates a slave. Then the master toggles the clock SCLK and both the master and the slave send a single bit on their respective data lines. After eight clock pulses a byte has been transferred from the master to the slave and from the slave to the master. You can think of this as being implemented as a circular buffer - although it doesn't have to be. 


This full duplex data transfer is often hidden by the software and the protocol used. For example there is a single write function that also reads data from the slave - it readily should be called a read-write function.

The transfer is typically in groups of eight bits and usually most significant bit first but this isn't always the case. In general as long as the master supply clock pulses data is transferred. 

Notice this circular buffer arrangement allows for slaves to be daisy chained with the output of one going to the input of the next. This makes the entire chain one big circular shift register. This can make it possible to have multiple devices with only a single chip select but it also means any commands sent to the slaves are received by each one in turn. For example you could send a convert command to each AtoD converter in turn and receive back results from each one. (See:

The final odd thing about the SPI bus is that there are four modes which define the relationship between the data timing and the clock pulse. The clock can be either active high or low - clock polarity CPOL and data can be sampled on the rising or falling edge of the clock - clock phase CPHA. All combinations of these two possibilities gives the four modes:


SPI Mode Clock Polarity
Clock Edge
0 0 0 Clock active high data output on falling edge and sampled on rising
1 0 1 Clock active high data output on rising edge and sampled on falling
2 1 0
Clock active low data output on falling edge and sampled on rising
3 1 1 Clock active low data output on rising edge and sampled on falling


The way that the modes are named is common but not universal. 

There is often a problem trying to work out what mode a slave device uses. The clock polarity is usually easy and the Clock phase can sometimes be worked out from the data transfer timing diagrams and:

  • First clock transition in the middle of a data bit means CPHA=0
  • First clock transition at the start of a data bit means CPHA=1

So to configure the SPI bus to work with a particular slave device you have to 

  1. select the clock frequency - anything from 125kHz to 8MHz 
  2. set the clock mode Mode0 thru Mode3

Now we have to find out how to do all of this using the function supplied.