32 SPI Protocol

32.2 Overview: SPI Trades Wires For Deterministic Transfers

SPI is a short-distance synchronous serial bus for connecting a controller to board-level peripherals such as displays, ADCs, flash memory, radio modules, and sensors. The controller supplies the clock, selects exactly one peripheral with a chip-select line, and shifts data over MOSI and MISO at the same time.

The design trade is simple: SPI avoids addressing overhead and open-drain pull-up limits, but it spends pins. Shared SCLK, MOSI, and MISO lines can serve several peripherals, yet each independently selected peripheral usually needs its own CS line and its own timing contract.

That makes SPI attractive when the product needs predictable bursts of data rather than a self-describing network. A display controller can stream pixels, an external flash chip can clock blocks of bytes, and an ADC can return samples with tight timing because the controller owns the transaction cadence. The same explicitness is also the risk: if firmware asserts the wrong CS, uses the wrong clock phase, clocks too fast for the layout, or assumes a device releases MISO when it does not, there is no bus-level address scan or ACK layer to explain the mistake.

The overview decision is therefore a board-level fit decision. SPI is usually a good match inside one PCB, between stacked boards, or across a very short harness inside the same enclosure. It is weaker as a field cable or shared installation bus because signal integrity, grounding, connector stubs, and device-count wiring become the dominant constraints. For longer or noisier boundaries, a local SPI peripheral should normally sit behind a microcontroller, gateway, or transceiver that exposes CAN, RS-485, Ethernet, or a wireless interface to the outside world.

Use Figure 32.1 to follow one selected SPI transfer across its clock and two data directions.

+

The controller first asserts SS, selecting one peripheral and framing the transfer. SCLK then supplies the edges that shift and sample bits. MOSI carries controller-to-peripheral data while MISO carries peripheral-to-controller data, so a bit can move in each direction during the same clock cycle. Deasserting SS ends the frame and should release that peripheral’s MISO driver. The diagram explains SPI’s deterministic timing and wire cost together: multiple devices may share clock and data, but each selected device needs controlled chip-select behaviour and only one peripheral may drive MISO.

What actually grows when a fourth peripheral joins an SPI bus? Figure 32.2 makes the answer countable.

+

Three wires in Figure 32.2 run to every peripheral at once: the clock and the two data lines. Those do not multiply. What multiplies is the set of select lines beside them, one per device, each returning to its own pin on the controller. SPI has no address field, so that dedicated line is the only way to say who is being spoken to. A fourth peripheral therefore costs a fourth chip-select pin and a fourth entry in the firmware that raises and lowers it. Read the figure as a budget rather than a picture: pins and bookkeeping scale with the device count, while the shared bus and its timing stay the same.

32.3 Practitioner: Treat Each Peripheral As A Timing Contract

An SPI design is not complete when the four signal names are wired. Each peripheral datasheet defines clock mode, maximum clock rate, bit order, command framing, CS timing, bus idle behavior, and whether MISO is released when the device is not selected. Capture those terms before the board is routed and before firmware is written.

Use a per-device contract, not a single bus note. A microSD card, display controller, radio transceiver, and ADC can all share the same SPI controller while needing different clock rates, modes, setup times, and command sequences. The driver should configure those fields at the transaction boundary, and the schematic should make it obvious which GPIO owns each chip select. If an RTOS, DMA engine, or interrupt handler can start transfers from multiple tasks, add a bus lock and record who is allowed to change mode or speed.

Read the CPOL and CPHA figure to see how CPOL and CPHA define idle level and sampling edge.

+

First inspect CPOL, which sets whether SCLK rests low or high. CPHA then decides whether receivers sample on the first clock transition or the second, with data changing on the opposite edge. Their two binary choices produce four modes; a controller in mode 0 and a peripheral expecting mode 3 can appear active while sampling unstable bits. The mode is therefore a shared endpoint contract, not a controller preference. Verify it with the data sheet and a trace that includes SS, SCLK, MOSI, and MISO at the peripheral pins.

Those four clock modes have datasheet numbers, not just polarity/phase jargon, and it is worth naming them because most peripheral datasheets specify "Mode 2" or similar rather than spelling out CPOL and CPHA. The four combinations of the idle clock level (CPOL) and the sampling edge (CPHA) are:

Mode 0 is the most common default, but always confirm the mode in the peripheral datasheet. A controller configured for the wrong mode may sample on the wrong edge and return shifted or corrupted bytes, or no valid response. In this 8-bit Mode 0 transfer with active-low select and MSB-first bit order, SS (also called CS) stays low for the whole byte, SCLK pulses eight times, and bits shift on MOSI and MISO together. Mode 0 itself does not prescribe bit order or select polarity.

Four wires do all the work here, and each name already encodes a direction. Figure 32.4 maps them between a controller and an SD card.

+

The two boxes in Figure 32.4 are a controller and a card, with four wires between them and a legend that expands every name. Two carry data in opposite directions at the same time, which is what full duplex means here: a byte goes out while a byte comes back. The third is the clock, and the note that the controller generates it is the reason the card never sets the speed. The fourth is chip select, marked active low, so the card listens only while that line is held down. The strip underneath states the trade plainly: no addresses, a separate select line per device, and a clock measured in megahertz.

32.4 Under The Hood: The Bus Is Fast Because It Is Simple

SPI does not define a universal packet format, address field, arbitration scheme, acknowledgement, or error recovery method. That simplicity is why transfers can be efficient on a PCB, but it also means the application must define the safety rails: retries, status checks, CRC use when available, and what happens after a failed transaction.

Electrical details matter. The controller drives SCLK and MOSI, the selected peripheral drives MISO, and all devices share ground and compatible voltage levels. Long traces, weak return paths, too many stubs, or multiple peripherals driving MISO can create failures that look like firmware bugs.

The clock edge is the contract between digital logic and the physical route. CPOL defines the idle clock level; CPHA defines which edge captures the bit. At low speed with short wires, the wrong mode may still produce recognizable but shifted data. At higher speed, propagation delay, edge rate, ringing, crosstalk, and setup/hold margin decide whether a receiver samples the intended bit. That is why SPI speed should be validated on the final routing, not only on a development jumper.

Failure handling is also device-specific. Some flash memories expose status bits while an erase is in progress, some sensors require dummy clocks before valid data, some radios need an interrupt or ready pin before reading a FIFO, and some devices add CRC fields that firmware must actually check. Without those guards, a transfer can return bytes that are electrically valid but semantically stale, misaligned, or from the wrong command phase.

Use Figure 32.5 to check the electrical assumptions beneath a logically correct SPI transfer.

+

Start at the controller and selected peripheral, then follow SCLK, MOSI, MISO, and select as physical conductors rather than abstract names. Their logic levels must be compatible, their return path controlled, and their edges clean enough at the receiver. Unselected peripherals must release MISO so two outputs do not contend. Longer traces, connectors, level shifters, or many loads can add delay and ringing that a slower bench setup hides. The SPI interface is accepted only when timing and voltage are measured at the receiving pins under the intended rate and topology.

SPI is one option among several wired buses, and the choice between them is made link by link. Figure 32.6 places that choice on the platform that has to live with it.

+

Figure 32.6 is a schematic rather than a comparison table. A single platform block sits at the centre with dashed lines to the panels around it, and the one substantive label says that each serial protocol is strongest in a different use. Take that as the section’s summary, not as data. Nothing in the drawing ranks the buses or gives a speed, a distance or a pin count, and it should not be quoted as though it did. The comparison that matters is in the cards above: short board-level runs with a fast clock favour this bus, while long cable runs, multi-drop wiring, or scarce pins point somewhere else.

Follow Figure 32.7 to decide whether SPI’s speed and duplex path justify its wiring cost.

+

Start by rejecting board buses when distance or noise calls for a cabled physical layer. For a short link, ask how many devices share it and whether they need full duplex or high sustained rate. SPI becomes attractive when deterministic clocked transfer matters and enough pins remain; I2C may fit many moderate-rate peripherals, while UART may fit a simple point-to-point stream. The route also exposes hidden costs: select lines, level compatibility, recovery, and test access. Record the measured traffic and physical layout so “need full duplex” is a requirement rather than a habitual answer.