What Is SPI (Serial Peripheral Interface)?

Detailed Explanation

SPI is built around four signals:

• SCLK (Serial Clock) — generated by the controller, sets the bit rate.
• MOSI (Controller Out, Peripheral In) — carries data from controller to peripheral.
• MISO (Controller In, Peripheral Out) — carries data from peripheral to controller.
• CS (Chip Select) — one per peripheral; the controller drives it low to address a specific device.

Because SPI is full-duplex, a controller can shift data out on MOSI and read data in on MISO during the same clock cycle. There is no addressing scheme on the bus itself — device selection is handled entirely by which CS line is asserted, which is why each peripheral needs its own.

Clock polarity (CPOL) and clock phase (CPHA) define one of four SPI "modes" (0–3), determining whether data is sampled on the rising or falling clock edge, and whether the clock idles high or low. Both controller and peripheral must agree on the same mode — this is one of the most common sources of "SPI isn't working" bugs.

Practical Examples

A typical use case is reading a sensor: an SPI accelerometer is wired with SCLK, MOSI, and MISO shared with other SPI devices on the same bus, and its own dedicated CS line back to a GPIO pin on the microcontroller. The firmware drives CS low, shifts out a register-read command on MOSI while clocking, reads the response on MISO, then releases CS high.

Flash memory chips, SD cards (in SPI mode), display controllers, and many ADCs/DACs all commonly use SPI because of its simplicity and speed compared to a shared-bus protocol.

Design Considerations

• Trace length and signal integrity: at higher clock rates (tens of MHz), keep SCLK/MOSI/MISO traces short and length-matched, and watch for ringing caused by an unmanaged trace impedance on long traces or cables.
• Number of available CS lines: each additional SPI peripheral consumes one more GPIO, which can become a constraint on pin-limited microcontrollers. If only a point-to-point link to a single device is needed, UART avoids this overhead entirely — at the cost of the throughput SPI provides.
• Mode compatibility: confirm CPOL/CPHA against the peripheral's datasheet before wiring anything — getting this wrong is the single most common cause of garbled SPI reads.
• Pull-ups on CS: an idle (unselected) CS line should be pulled high so the peripheral doesn't see spurious activity during power-up.
• Choosing between SPI, I2C, and UART: each protocol suits a different scenario — for a structured protocol-selection guide covering all three, see SPI vs I2C vs UART: which to use.
• SPI on Raspberry Pi: for enabling SPI0 via device tree overlay and using it from Python with spidev (including clock rate considerations and mode configuration), see Raspberry Pi GPIO Interfacing.
• SPI driver development: Writing robust SPI drivers — with correct mode configuration, DMA or interrupt handling, and error recovery for production hardware — is part of the embedded firmware services Zeus Design's software team provides for microcontroller-based designs.

Common Mistakes

• Forgetting that MISO is high-impedance (not driven) when a peripheral's CS is not asserted — without a pull-up, an idle bus can read noise.
• Sharing one CS line across multiple devices, which causes bus contention since SPI has no built-in arbitration.
• Mismatched SPI mode between controller and peripheral. Getting CPOL or CPHA wrong typically produces reads that all return 0xFF even when a logic analyser shows MISO activity — the MCU is sampling on the wrong clock edge. See the SPI CPOL/CPHA troubleshooting thread for a worked diagnosis example.
• Running the clock faster than the peripheral's datasheet maximum, which works intermittently on the bench but fails in production temperature ranges.