Spi

SPI, short for Serial Peripheral Interface, is a synchronous serial communication protocol that moves data between a controller and one or more peripheral devices using separate dedicated wires for sending and receiving data simultaneously, plus a shared clock line and a dedicated select line for each connected device. Unlike I2C's shared, addressed two-wire bus, SPI gives each device its own dedicated select wire and uses full duplex data lines, meaning data can flow in both directions at the exact same time rather than taking turns — a design that trades more wires for dramatically higher achievable speed. How SPI actually moves data in both directions at once between a controller and a selected peripheral looks like this:

A few things are worth knowing about why SPI's extra wires buy it genuinely different capabilities than I2C's shared, addressed bus:

SPI is genuinely full duplex, meaning data physically moves in both directions across the controller-to-peripheral link at the exact same instant, which is a fundamentally different capability from I2C's shared bus where only one direction of data can move at any given moment. SPI uses two completely separate data lines — commonly called MOSI, for controller-out-peripheral-in, and MISO, for controller-out-peripheral-in reversed — so a byte shifting out of the controller to the peripheral and a byte shifting from the peripheral back to the controller happen simultaneously on the same clock edges, not as two sequential, separate operations. This genuinely simultaneous bidirectional transfer is a real structural advantage SPI has over I2C's shared single data wire, and it's a direct reason SPI reaches meaningfully higher effective throughput for applications that genuinely need data moving both directions continuously, like reading back status while streaming out configuration data.

SPI's reliance on one dedicated select line per peripheral device is both its biggest structural advantage and its most significant practical limitation, since it makes individual device addressing dead simple at the hardware level but means the pin count needed grows directly with the number of connected devices. Because there's no software-level addressing scheme the way I2C uses — the controller simply chooses which single device to talk to by physically pulling that specific device's select line low — there's no address collision risk and no addressing overhead eating into the data transfer itself, making SPI's protocol overhead genuinely minimal. But this simplicity comes at a direct wiring cost: connecting ten SPI peripherals to one controller needs ten separate select lines in addition to the three shared data and clock lines, a pin count that climbs linearly with device count in a way I2C's shared, addressed two-wire bus simply doesn't face.

SPI has no official, formally standardized specification the way I2C does, which has resulted in several incompatible variations in clock polarity and clock phase — collectively called SPI mode — that two devices must agree on before communication will work correctly at all. Because different chip manufacturers independently settled on slightly different conventions for exactly when data should be sampled relative to the clock edge — whether the clock idles high or low, and whether data is sampled on the clock's rising or falling edge — four distinct SPI modes exist, and connecting two devices configured for different modes will reliably fail to communicate correctly even though both devices are nominally speaking "SPI." This is exactly why SPI peripheral datasheets always specify their required mode explicitly, and why troubleshooting a non-functioning SPI link often starts with checking that both sides agree on the same mode setting before investigating anything more exotic.

SPI's simple shift-register-based design and lack of addressing overhead let it reach meaningfully higher clock speeds than I2C under comparable electrical conditions, routinely running at tens of megahertz and sometimes well beyond, which is exactly why SPI dominates applications needing to move larger amounts of data quickly, like flash memory chips, high-resolution displays, and fast analog-to-digital converters. Where I2C's open-drain signaling and address-matching overhead cap practical speeds in the hundreds of kilohertz to low megahertz range, SPI's dedicated point-to-point-style wiring per device and simple, overhead-free shift-register protocol let it scale to much higher clock rates without the same electrical and protocol limitations holding it back — the direct tradeoff for that speed being exactly the extra select-line wiring and the lack of a shared, flexibly addressable bus that I2C provides instead.

Read SPI as dedicated wiring traded for raw speed and full duplex capability, the structural opposite of I2C's shared, addressed economy: separate MOSI and MISO lines let data move both directions genuinely simultaneously, one select line per device replaces software addressing with dead-simple hardware selection at the cost of growing pin count, and the lack of a single formal SPI standard means mode compatibility has to be checked explicitly — together making SPI the right choice specifically when raw throughput matters more than minimizing wire count, the exact opposite priority from the situations where I2C wins instead.