What's SPI? A Hardware Guide to the Serial Peripheral Interface

The Direct Answer: What's SPI and Why It Dominates the Bench

SPI (Serial Peripheral Interface) is a synchronous, full-duplex, four-wire serial communication bus used to connect microcontrollers to high-speed peripherals like displays, SD cards, and flash memory. Unlike asynchronous protocols, SPI relies on a shared clock line to synchronize data transfer, allowing it to push massive bandwidth over short distances. If you need to move bulk data quickly across a single printed circuit board or a short breadboard setup, SPI is the default choice.

Originally developed by Motorola in the 1980s, SPI operates on a strict controller-peripheral (historically master-slave) architecture. The controller generates the clock signal and initiates all transfers, while peripherals respond. Because it lacks the complex arbitration and addressing overhead of I2C, SPI achieves significantly higher throughput, routinely running at 10 MHz to 80 MHz on modern silicon.

Bus Mechanics: Wires, Speeds, and Physical Layer Realities

To understand what's SPI at the physical layer, you must look at the actual copper traces. SPI requires three shared lines for the entire bus, plus one dedicated routing line per peripheral.

Physical Wiring and Pull-Up Requirements

A common misconception is that SPI requires pull-up resistors like I2C. It does not. SPI lines (SCK, MOSI, MISO) are driven by push-pull output stages, meaning they actively pull high to VCC and low to GND. Adding pull-ups to these lines will only cause current contention and increase rise/fall times, degrading signal integrity at high speeds.

SPI vs. I2C vs. UART: Picking the Right Protocol

Knowing what's SPI is only half the battle; you must know when not to use it. Here is how SPI stacks up against the other two major embedded protocols when evaluating distance, speed, and device count.

The Verdict: Choose SPI when bandwidth is the bottleneck and you have fewer than four peripherals. Choose I2C when you have 10+ low-bandwidth sensors (like temperature or IMUs) and want to save GPIO pins. Choose UART for communicating with external modules like cellular modems or PC terminals.

Minimal Working Exchange: Wiring and Code

Let's look at a raw SPI transaction. We will read the WHO_AM_I register (0xD0) from a BMP280 sensor using an ESP32 DevKit V1. This bypasses high-level libraries to show the actual bus mechanics.

Wiring Table

Raw SPI Exchange Code (Arduino IDE)

#include <SPI.h>

const int CS_PIN = 5;
const uint8_t WHO_AM_I_REG = 0xD0;

void setup() {
  Serial.begin(115200);
  pinMode(CS_PIN, OUTPUT);
  digitalWrite(CS_PIN, HIGH); // Deassert CS immediately

  // Initialize SPI bus with Mode 0 (CPOL=0, CPHA=0) and MSB first
  SPI.begin();
}

void loop() {
  // 1. Configure bus speed and mode for this specific transaction
  SPI.beginTransaction(SPISettings(4000000, MSBFIRST, SPI_MODE0));

  // 2. Assert Chip Select (pull LOW)
  digitalWrite(CS_PIN, LOW);

  // 3. Send the register address with the READ bit set (0x80 | 0xD0 = 0xD0 for BMP280)
  SPI.transfer(WHO_AM_I_REG | 0x80);

  // 4. Clock out the response byte by sending a dummy byte (0x00)
  uint8_t chipID = SPI.transfer(0x00);

  // 5. Deassert Chip Select (pull HIGH)
  digitalWrite(CS_PIN, HIGH);

  // 6. End transaction to release the bus
  SPI.endTransaction();

  Serial.print("BMP280 Chip ID: 0x");
  Serial.println(chipID, HEX); // Should print 0x58

  delay(2000);
}

Debugging the Bus: Sniffing and Classic Failures

When your SPI bus returns 0xFF or 0x00, guessing is a waste of time. You need a logic analyzer (like a Saleae Logic Pro 8 or a budget DSLogic Plus) connected to all four shared lines plus the CS line. Set your analyzer's sample rate to at least 4x your SPI clock speed (e.g., 100 MS/s for a 20 MHz bus) to accurately capture edge transitions.

The Classic Failures

• Baud Mismatch: The most common bench error. Your MCU might default to 8 MHz, but the peripheral datasheet specifies a 4 MHz maximum. The peripheral fails to clock in the bits, returning garbage. Fix: Drop the SPI clock to 1 MHz to verify connectivity, then step up.
• Missing CS Pull-Up: If your peripheral acts erratically after an MCU reset, it's likely because the CS line floated during boot, causing the peripheral to latch onto noise. Fix: Solder a 10kΩ resistor between CS and VCC.
• CPOL/CPHA Mode Mismatch: SPI has four modes (0, 1, 2, 3) defining clock polarity and phase. If the sensor expects Mode 3 (Clock idles HIGH) and you send Mode 0 (Clock idles LOW), the peripheral will sample data on the wrong clock edge. Fix: Check the datasheet timing diagram and adjust SPI_MODE0 through SPI_MODE3 in your code.
• The SPI 'Address Clash': SPI doesn't use software addresses, so a traditional I2C address clash is impossible. However, an 'address clash' in SPI parlance means you've wired two CS lines to the same GPIO, or you've run out of GPIOs. Fix: Use a 74HC138 3-to-8 line decoder to expand a single CS pin into eight independent hardware routes.