SPI vs I2C: which is faster, and why the answer is both

SPI is faster because nothing caps its clock and it spends 8 clocks per byte; I2C spends 9 and stops at 3.4 Mbit/s. Four reasons the choice is not about speed.

SPI is faster. That is not close: for a 16-byte register read, I²C in its common Fast-mode delivers about 37 kB/s of payload and SPI at a routine 10 MHz delivers 1.2 MB/s — thirty times more — and the gap widens because no specification caps an SPI clock while I²C’s fastest bidirectional mode stops at 3.4 Mbit/s. The reasons are in the two protocols’ definitions: I²C spends nine bit-times on every byte and adds addressing overhead to every transaction; SPI spends eight and adds a chip-select wire instead.

But speed is the last reason to choose between them. I²C is two wires shared by every device on the board, addressed in software, with multi-controller arbitration built in and pull-up resistors doing the work of the drivers. SPI is three wires plus one more per device, full-duplex, push-pull, and — in TI’s words — “does not define a standard communication format”. Most boards use both: I²C for the sensors, the EEPROM, the PMIC and everything else that is slow and numerous, SPI for the display, the flash, the ADC and anything else that moves data. This article is what each one is, from NXP’s I²C specification, Motorola’s SPI block guide and TI’s notes on both, and how to decide.

Log-log plot of payload bytes per second for a 16-byte register read against bit clock from 100 kilohertz to 100 megahertz. Two parallel straight lines: I2C at 74 percent efficiency and SPI at 94 percent. The I2C line stops at marked ceilings — 100 kilobits per second Standard-mode, 400 kilobits Fast-mode, 1 megabit Fast-mode Plus, 3.4 megabits High-speed — and is greyed beyond. The SPI line continues to 100 megahertz with a note that its limit is the peripheral, not the specification. — Fig 1 — Payload rate for a 16-byte register read. I²C carries 74 % of its clock as payload (174 bit-times for 128 bits, with the ACK after every byte and the addressing overhead) and its clock is capped by mode: 36.8 kB/s in Fast-mode, 313 kB/s in High-speed mode. SPI carries 94 % (136 clocks, one command byte) and no specification caps its clock; at 10 MHz that is 1.18 MB/s. The gap is the clock, not the efficiency.

What I²C is

TI’s guide opens with the essentials: “I2C is a two-wire serial communication protocol using a serial data line (SDA) and a serial clock line (SCL). The protocol supports multiple target devices on a communication bus and can also support multiple controllers.” Every device hangs on the same two lines; the controller sends a START, a 7-bit address with a read/write bit, and the addressed target answers. Communication is “bidirectional, half-duplex” — one device talks at a time, on one line.

The physical layer is what makes the sharing possible. NXP’s specification: “the output stages of devices connected to the bus must have an open-drain or open-collector to perform the wired-AND function”. Any device can pull a line low; none can drive it high. The pull-up resistors do that, and TI’s SLVA704 spells out the consequence: open-drain “can either pull the bus down to a voltage (ground, in most cases), or ‘release’ the bus and let it be pulled up by a pull-up resistor”. Two devices driving at once cannot fight, because a low always wins — which is exactly the property the arbitration scheme relies on when two controllers start together, and the reason a target can hold the clock low to make the controller wait (clock stretching, UM10204 §3.1.9).

The price is on the edges. A pull-up resistor charging the bus capacitance is an RC, and the specification limits the load to 400 pF and the rise time per mode; that is what sets the speed classes. TI lists them: Standard-mode 100 kbit/s, Fast-mode 400 kbit/s, Fast-mode Plus 1 Mbit/s, High-speed mode 3.4 Mbit/s, and the write-only Ultra-Fast mode at 5 Mbit/s. Fast-mode Plus gets its speed from “increased drive current”; High-speed mode needs a controller code to enter it and “can also require an active pullup”. The I²C pull-up calculator turns the capacitance and the mode into the resistor.

Every byte is acknowledged: “each byte of data (including the address byte) is followed by one ACK bit from the receiver” (SLVA704). So a byte is nine bit-times, and a register read is START, address, ACK, register, ACK, repeated START, address, ACK, the data bytes with their ACKs, and STOP. For 16 bytes that is 174 bit-times carrying 128 bits of payload — 74 %.

What SPI is

TI’s SPI brief: “SPI was developed by Motorola in the 1980s”, and “unlike other serial protocols such as inter-integrated circuit (I2C), serial peripheral interface (SPI) does not define a standard communication format, allowing developers to tailor the protocol to specific application requirements.” There is no address, no acknowledge, no START or STOP. The controller drives a clock, drives data out on one line (PICO) while data comes back on another (POCI), and selects the peripheral it is talking to with a dedicated chip-select line. Four wires for one peripheral; “each peripheral has a dedicated chip-select (CS) line” for more, or a daisy chain, or a three-wire variant with a shared data line.

Because it is full-duplex — “data can be sent and received simultaneously” — a read is a write: the controller clocks out a command and the peripheral clocks back the answer in the same cycles. A 16-byte register read is one command byte and 16 data bytes, 136 clocks for 128 bits of payload — 94 %.

What SPI does define is the clock relationship, and it is the thing that goes wrong on first bring-up. Motorola’s block guide: “the CPOL clock polarity control bit specifies an active high or low clock”, and “the CPHA clock phase control bit selects one of two fundamentally different transmission formats”. With CPHA = 0 “the first edge on the SCK line is used to clock the first data bit”; with CPHA = 1 the first edge tells the peripheral to present its bit and “a half SCK cycle later, the second edge appears on the SCK pin. This is the latching edge for both the master and slave.” Four combinations, numbered 0 to 3, and the guide’s rule is that “clock phase and polarity should be identical for the master SPI device and the communicating slave device.”

Four rows of clock waveforms over one byte, one per SPI mode. Modes 0 and 1 idle low, modes 2 and 3 idle high. In each row the sampling edges are marked with dots: rising edges for modes 0 and 3, falling edges for modes 1 and 2. A data line above shows eight bits changing on the opposite edge to the sampling edge. — Fig 2 — The four SPI modes of SBOA621 table 3. CPOL sets the idle level of the clock; CPHA sets whether data is sampled on the first edge of each cycle (CPHA = 0) or the second (CPHA = 1). Mode 0 and mode 3 both sample on rising edges and are the two most peripherals speak. The block guide's rule: "clock phase and polarity should be identical for the master SPI device and the communicating slave device."

The lines are push-pull, driven hard both ways, so there is no RC edge and no 400 pF rule; the clock is whatever the controller’s divider and the peripheral’s datasheet allow. The block guide derives the master’s rate from the bus clock and a divisor, and the peripheral’s datasheet gives the maximum it can follow. Tens of megahertz is ordinary.

Which is faster, in numbers

Two things separate the rates: the efficiency and the clock.

The efficiency is close. For the 16-byte read, I²C carries 74 % of its bit-times as payload and SPI 94 %; on a long transfer both approach their per-byte figures, 8/9 and 8/8. That is a factor of 1.3, not 30.

The clock is the whole difference. I²C’s fastest bidirectional mode is 3.4 Mbit/s, and the modes most devices actually implement are 400 kbit/s and 1 Mbit/s, because the pull-up has to charge the bus in the rise time the mode allows. SPI’s clock is bounded by the parts, and 10 MHz is a conservative figure for a flash or a display and 50 MHz is common.

16-byte register read           bit-times   efficiency   payload rate
I²C Standard-mode 100 kbit/s    174         74 %         9.2 kB/s
I²C Fast-mode 400 kbit/s        174         74 %         36.8 kB/s
I²C Fast-mode Plus 1 Mbit/s     174         74 %         92 kB/s
I²C High-speed 3.4 Mbit/s       174         74 %         313 kB/s
SPI at 1 MHz                    136         94 %         118 kB/s
SPI at 10 MHz                   136         94 %         1.18 MB/s
SPI at 50 MHz                   136         94 %         5.9 MB/s

If the question is which one moves a frame buffer, a flash image or a stream of ADC samples, the answer was never in doubt. If the question is which one reads a temperature sensor every second, the rate is irrelevant and the other considerations decide.

The four reasons the choice is not about speed

Wires and pins. I²C is two lines for the whole board. SPI is three plus a chip select per device, and TI’s brief lists the ways around that — a daisy chain “reduces the number of required CS lines, as only one is needed for the entire chain” — each with its own cost. A microcontroller with eight I²C peripherals uses two pins; with eight SPI peripherals, eleven.

Two bus diagrams. Left, I2C: a controller and three peripherals all hang on the same two lines, SDA and SCL, each line with one pull-up resistor to the supply. Right, SPI: a controller with SCLK, PICO and POCI lines shared by three peripherals, and a separate chip-select line from the controller to each peripheral, making six wires for three devices. — Fig 3 — The wiring the two protocols ask for. I²C is two shared open-drain lines with one pull-up each, however many devices; the address in the first byte picks the target. SPI is three shared lines plus one chip select per peripheral — SBOA621's "single controller, multiple peripherals (independent chip select)" — so the wire count grows with the device count, and every line is push-pull.

Who can talk. I²C “is a true multi-controller bus including collision detection and arbitration” (UM10204), and targets can stall the controller by stretching the clock. SPI has one controller by construction; a peripheral cannot signal that it is busy except through a separate line. For a board where two processors share sensors, or where a slow device needs to hold the bus, I²C has the mechanism and SPI does not.

Addressing and the format. An I²C target has an address, fixed or pin-strapped, and the transaction format is the specification’s: any controller can talk to any target with the same code. SPI’s format is the peripheral’s own — TI’s brief walks through one device’s 24-bit frame with a read/write bit, seven address bits and eight data bits, and the next device will differ. Every SPI driver is written for its part; every I²C driver is the same driver with a different register map.

Distance and drive. I²C’s open-drain lines and 400 pF limit keep it on one board, or on a short cable with the pull-ups recalculated; TI’s guide notes that Fast-mode “can be used by the controller if the bus capacitance and drive capability allow”. SPI’s push-pull lines drive a longer trace at a given rate, but at tens of megahertz they are transmission lines with all that implies.

Choosing

Use I²C for what is slow, numerous and shared: sensors, EEPROMs, PMICs, GPIO expanders, clock generators, anything that is read a few times a second and would be a waste of pins on SPI. Use SPI for what moves data: displays, flash and SD cards, ADCs and DACs at any real sample rate, radios, anything where the transfer is the product.

When a part offers both — many sensors do — the choice is the pin count against the rate at which it will actually be read, and it usually comes out as I²C. When a design has both buses, keep them both: the temptation to put the fast device on I²C to save pins costs thirty to a hundred times the transfer time, and the temptation to put the sensors on SPI costs a chip select and a driver each.

And whichever bus, the physical layer has its own page: the I²C pull-up is a calculation, not a habit, and an SPI clock at 20 MHz over an unterminated trace of any length is a signal-integrity question before it is a protocol one.