An Overview of the Serial Peripheral Interface (SPI)

2023-04-10 | By Maker.io Staff

Although it’s a reasonably old standard, the Serial Peripheral Interface (SPI) is still a commonly used synchronous serial communication protocol for exchanging data between small devices, such as MCUs or registers. This article introduces newcomers in the maker scene to SPI and offers a refresher for those who are more experienced.

However, it’s recommended complete newcomers start by reading this article, which discusses the core principles of serial vs. parallel communication protocols and the difference between synchronous and asynchronous modes, before diving into the specifics of SPI.

Let’s get started!

The Benefits of Using Synchronous Serial Communication

In asynchronous serial communication, both parties agree on a specific data frame format before exchanging any information. This agreement includes a start and stop signal that distinguishes each message, as well as the number of bits in a message and the baud rate with which the data gets shifted from the sender to the receiver. These additional bits lead to communication overhead, which might result in millions of bits transmitted over time without carrying any information. In addition, incorrect baud rates at the receiving end result in the receiver translating the information to garbage, as it samples the incoming data at the wrong times. Interpreting the extra information also often requires more complex hardware and software solutions, which may be costly to implement in streamlined applications.

In contrast, synchronous serial communication relies on a shared clock signal that tells each communication party exactly when to write and read bits on the data line leading to much more straightforward hardware implementations that can be as simple as using a single shift register or buffer.

Sending and Receiving Data Bits

As there must only exist a single shared clock signal between all communication partners in SPI, this signal is generated by a controller (formerly known as the master device), typically an MCU or a development board. The peripherals (previously referred to as slaves) listen for that clock signal and react to it, typically using strictly pre-defined behavior (called a communication protocol in this behavior). Each device on the bus needs to know exactly how many bits to send and expect in specific scenarios.

In addition to the clock signal, each component on the bus has two data lines for exchanging information. One line sends data from the controller to the peripherals (PICO - Peripheral In Controller Out). The other transmits data from a peripheral to the controller (POCI - Peripheral Out Controller In). Formerly, these were labeled as MOSI and MISO respectively. Finally, each controller requires a CS (Chip Select) line that selects the peripheral the controller wants to communicate with. This additional line is necessary because there can only be precisely one device sending data on the bus at any time.

In addition, when the controller sends out data, it may only want specific peripherals to react to that information while the others should ignore it. Therefore, the CS line is typically active low, meaning it is held high when a device should ignore incoming data, or the bus is ready. Whenever a device’s CS line gets pulled low, that device knows that it should read incoming bits or that it can transmit data to the controller.

Wiring Multiple Peripherals

From the description above, SPI might seem rather unnecessarily complicated. However, consider the following example that connects a few SPI sensors to an Arduino:

An Overview of the Serial Peripheral Interface (SPI) Connect multiple SPI devices to the same bus, as shown in this image. Scheme-It link

Note that all sensors utilize the same data lines for receiving data from and sending bits to the Arduino – they share a common bus. However, each sensor has a separate CS line that lets the controller switch between devices.

Imagine that the controller wanted to read data from sensor one. It would then pull only that peripheral’s CS line (D7 in this example) low and keep the other device’s CS pins high. Sensor one would then listen for incoming data on its SDI (Serial Data In) pin, and the controller could then send a command to the sensor. When done, the sensor would respond with the requested data, and the controller could then pull sensor one’s CS chip high again to end the communication. Note that SPI might occupy numerous digital I/O lines on the controller, of which there might not be that many available.

Alternatively, some devices need to be daisy-chained so that data can overflow from one device in the chain to the next. In this case, all daisy-chained devices share the same CS line, and the SDI/SDO pins of the devices are chained, as shown in the following image:

An Overview of the Serial Peripheral Interface (SPI) This example shows how to daisy–chain multiple SPI peripherals. Scheme-It link

The controller sends data to the first device in the chain, which then, on its own, transmits data to the next device in the chain as required. This approach is often used when chaining registers or buffers.

Why Use SPI Instead of UART?

SPI introduces a few downsides compared to UART: namely the need for additional CS lines, stricter communication protocols, and the controller must handle all communication. Finally, due to high clock frequencies, SPI should only be utilized for short-distance communication up to a few feet. However, on the flip side, SPI supports multiple peripherals on the bus, it’s faster than asynchronous serial, and the peripherals can be simple devices.

Summary

SPI is a popular synchronous serial communication protocol often used in electronics projects. It requires a synchronized clock signal that all participants on the communication bus share. The controller typically generates this signal. Further, the bus utilizes two data lines: one for sending data from the controller to the peripherals and the other to transmit bits from the peripherals to the controller. When wired in parallel, each peripheral needs a separate CS line that the controller uses to select one device on the bus with which it wants to communicate. Some devices require daisy-chaining. In that case, all chained devices share the same CS line.