i2c vs SPI
The two board-level buses solve different problems: i2c shares two wires among many slow devices; SPI spends more wires to go fast. Here's the whole trade-off, then a rule you can actually use.
Side by side
i2c vs SPI: the trade-offs at a glance
| Property | i2c | SPI |
|---|---|---|
| Wires | 2 (SDA + SCL), shared by all | 3 (MOSI/MISO/SCK) + one CS per device |
| Speed | 100 kHz / 400 kHz / 1 MHz | tens of MHz |
| Device selection | 7-bit address in-band | dedicated chip-select pin |
| Drive | open-drain + pull-ups | push-pull, no pull-ups |
| Duplex | half (one data wire) | full (separate in/out) |
| Acknowledgement | yes — ACK/NACK per byte | none built in |
| Adding a device | plug into the same two wires | route another CS line |
| Typical use | sensors, RTCs, expanders, small OLEDs | displays, SD cards, flash, fast ADCs |
The reasoning
Why i2c and SPI look so different
i2c optimises for sharing. Every device hangs on the same two wires and answers to its own 7-bit address, so wiring five sensors costs exactly the same two pins as wiring one. The price is speed: the open-drain lines that make sharing safe need pull-up resistors to yank the bus high, and that rise time caps practical clocks around 400 kHz–1 MHz.
SPI optimises for bandwidth. Push-pull drivers snap the lines high and low, separate in/out wires give full duplex, and there's no addressing overhead — the chip-select pin does that in hardware. The price is pins: four wires for the first device and another CS for each one after it, plus no acknowledgement, so you only find out a device is missing when the data comes back as garbage.
The rule: reading numbers a few times a second (temperature, pressure, motion, time) → i2c, and you get the whole Qwiic / STEMMA QT plug-together ecosystem for free. Streaming data where the update rate matters (pixels, audio, storage) → SPI. Most real projects use both at once.
Questions
i2c vs SPI FAQ
Is SPI faster than i2c?
Yes, by a wide margin. i2c runs at 100 kHz (Standard), 400 kHz (Fast-mode) or 1 MHz (Fast-mode Plus); SPI routinely runs at 10–50 MHz and beyond. If you're moving pixels to a display or blocks to an SD card, SPI. If you're reading a temperature every second, the speed difference is irrelevant.
Can i2c and SPI be used at the same time?
Yes — they're independent peripherals on separate pins. A very common layout is SPI for one fast device (display, SD card) and i2c for all the slow sensors. The buses don't interact.
Why does i2c need pull-up resistors and SPI doesn't?
i2c lines are open-drain: devices only pull the line low, and resistors pull it back high. That's what lets many devices share two wires safely. SPI drives its lines high and low actively (push-pull), which is faster but means each output belongs to one driver.
Which is better for long wires?
Neither is designed for distance — both are board-level buses. i2c degrades as bus capacitance grows (400 pF budget); SPI at high clock rates is worse over ragged wiring. For anything beyond ~1 m, slow the clock right down, or move to a real long-haul bus like RS-485 or CAN.
Do sensors come in both i2c and SPI versions?
Very often the same silicon speaks both — the BME280, LIS3DH and many others expose i2c and SPI on the same chip, selected by wiring. Breakout boards usually route the i2c pins to a connector (Qwiic / STEMMA QT) because two shared wires beat four-plus-chip-select for chaining sensors.
Related comparisons
SPI isn't the only alternative. i2c vs UART covers the other bus you'll meet on a dev board — and it's a different question entirely, since UART is point-to-point rather than a bus. If you're choosing from scratch rather than deciding between two, i2c vs SPI vs UART puts all three side by side. New to the bus itself? Start with what is i2c or the byte-level how i2c works.