Chapter 10. Serial Peripheral Interface - SPI

As we have already seen in the previous chapter, the I²C bus is widely used to connect on-board devices with the main CPU, but another bus with similar features exists: the (SPISerial Peripheral Interface (SPI). However, and opposed to the I²C bus, this bus can transfer data at higher rates than I²C, and since it's full-duplex, data transfer can take place bidirectionally at the same time. Due to these features, the SPI bus is normally used to implement an efficient data stream for multimedia applications (LCDs/video) or digital signal processing and/or telecommunications devices (Ethernet, WLAN, CAN, Serial Ports, and so on) and SD cards. However, despite this fact, it can be used to communicate with standard sensors, ADC/DAC converters, GPIOs controllers, and other similar devices.

In order to demonstrate the versatility of the SPI bus, in this chapter, we will present several different kinds of devices connected to the main CPU by this bus...

What is the Serial Peripheral Interface bus?

The SPI bus is a full-duplex, single-master, multi-slave, synchronous serial data bus and, as the I²C bus, it's used for on-board connection of sensor chips with the main CPU. This bus require at least (apart the GND signal) three wires plus one chip select signal per slave, this line is typically called Slave Select (SS) or Chip Select (CS) and usually it's active low (that is the master must set it to 0 to enable the desired slave chip).

Some terms need to be explained here:

• Full-duplex:It means transmitting and receiving are at the same time on the bus.

• Synchronous: It means that the clock is sent along with the data (in this case, it is the master that provides the clock).

• Single-master and multi-slave: It mean that on the bus, there is one master only that directs the communication, while more than one slave can be connected on the bus.

• Serial data:It means data is transmitted one bit at a time over the bus.

The communication starts when the...

The SPI bus in Linux

As in the I²C case, the SPI bus has the concept of master and slave device too. Again, regarding the SPI master device, there is nothing special to do here since the proper driver is already up and running in our embedded kits' default kernel configurations (as seen earlier). However, to be connected with SPI devices, we can have several possibilities: external memories, I/O extenders, sensors, serial ports, and so on (the list can be very long!).

As seen earlier, we can also have a generic spidev driver to get access to the raw bus functionalities, but this time, we have no prebuild tools to manage it! The only things we can do is write our own program, maybe take some basic tools provided into the kernel's tree (see the next section for an example) as examples to manage our device through the spidev driver.

Note

For further information on the API in Linux for SPI, we can take a look at the Documentation/spi/spidev file in Linux's sources repository.

The SPI tools

In complete analogy to the I²C case, even for SPI, we have some basic tools to manage it. However, as stated earlier, this time, these tools are not into a dedicated Debian package, but they are stored directly in the Documentation/spi/ directory of Linux's sources repository. Honestly, these SPI tools offer a poor support against the I²C counterpart. However, they can be used for basic functionalities and taken as examples to build our own programs.

As shown here, the available programs are just two:

$ ls Documentation/spi/*.c
Documentation/spi/spidev_fdx.c  
Documentation/spi/spidev_test.c

Both of them can be compiled on the host PC (or directly on our embedded kits) using the following command:

$ make CC=arm-linux-gnueabihf-gcc 
       CFLAGS="-Wall -O2" spidev_fdx spidev_test
arm-linux-gnueabihf-gcc -Wall -O2 spidev_fdx.c   -o spidev_fdx
arm-linux-gnueabihf-gcc -Wall -O2 spidev_test.c   -o spidev_test

Note

Of course, if we decide to compile them natively, the CC...

Getting access to SPI devices

Now, we are ready to manage real SPI devices. We can find tons of supported devices in Linux's tree that are usually grouped according to their specific operations in complete analogy to the I²C case.

In the next section, we will see several different kinds of devices all connected to the main CPU through the SPI bus. Also, we will use different embedded kits to test them, but as said earlier, every command can be easily repeated on every GNU-/Linux-based boards with a similar configuration.

LCD display

As the first example, we will use the following tiny LCD display, which can be used in simple applications because it's cheap and well supported by BeagleBone Black's kernel:

Note

The device can be purchased at http://www.cosino.io/product/color-tft-lcd-1-8-160x128 or by surfing the Internet. The LCD is based on the chip ST7735R, which has its datasheet at:  https://www.adafruit.com/datasheets/ST7735R_V0.2.pdf.

First of all, we must do the following electrical...

The raw SPI bus

As for USB and I²C buses the SPI bus supports the raw access in order to directly send and receive messages from the SPI slaves, so it's time to show a little example about how we can do it on our Wandboard.

As for other raw accesses, the only problem is that it interrupts management. In this case, we cannot manage these signals from the user space. A kernel driver must be used.

Exchanging data in C

To show how we can manage the raw SPI bus, we are going to manage a really simple device using the Wandboard, that is, the thermocouple to digital converter based on the MAX31855 chip:

Note

The device can be purchased at:  http://www.cosino.io/product/thermocouple-max31855 or by surfing the Internet. The datasheet of the MAX31855 is available at: https://datasheets.maximintegrated.com/en/ds/MAX31855.pdf.

Electrical connections are reported in this image:

By looking at the chip's datasheet, we see that its functioning is very simple: it has one 32-bit register where we can read...

Summary

As you can see, the SPI bus is quite powerful, since while it implements an efficient data stream, it can also be easily managed with a large variety of different slave devices.

In the next chapter, we'll see another available bus for our embedded kits that allows us to communicate with some sensors using only one wire! It's time to move on to the next chapter and discover the 1-Wire bus.