i2c vs SPI vs UART
The three serial buses every microcontroller ships with, and they solve three different problems: i2c shares two wires among many devices, SPI spends wires to go fast, and UART links exactly two devices with no bus at all.
Side by side
i2c vs SPI vs UART at a glance
| Property | i2c | SPI | UART |
|---|---|---|---|
| Wires | 2, shared (SDA, SCL) | 3 shared + 1 CS each | 2 (TX, RX), per link |
| Topology | bus — many devices | bus — many devices | point-to-point (2) |
| Speed | 100 kHz–1 MHz | tens of MHz | up to a few Mbps |
| Device select | 7-bit address | chip-select pin | n/a (one device) |
| Clock | shared, on SCL | shared, on SCK | none — agreed baud |
| Duplex | half | full | full |
| Pull-ups | required | none | none |
| Best for | sensors, RTCs, displays | displays, SD, flash | GPS, Bluetooth, console |
The reasoning
Why i2c, SPI and UART all exist
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 the same two pins as wiring one. The price is speed — the open-drain lines that make sharing safe need pull-up resistors, and that caps practical clocks around 400 kHz–1 MHz. Full detail in i2c vs SPI.
SPI optimises for bandwidth. Push-pull drivers snap the lines high and low, separate in/out wires give full duplex, and a hardware chip-select does the addressing — no protocol overhead. The price is pins: four wires for the first device and another chip-select for each one after it.
UART optimises for simplicity. It isn't a bus at all — just a TX/RX pair between two devices, with no shared clock, so both ends must agree on a baud rate in advance. Perfect for a single streaming device (GPS, a radio module, a serial console); useless the moment you need a second one.
The rule
How to choose between i2c, SPI and UART
A rule that holds for almost every hobby project:
- Reading numbers a few times a second — sensors, RTCs, small displays, expanders → i2c. You also get the plug-together Qwiic / STEMMA QT ecosystem for free.
- Streaming data where the rate matters — pixels, audio, storage → SPI.
- Talking to exactly one continuous device — GPS, Bluetooth/Wi-Fi modules, a PC serial console → UART.
Most real builds use two or three at once, and they never interfere — see the FAQ. For the pairwise deep dives: i2c vs SPI and i2c vs UART.
Questions
i2c vs SPI vs UART FAQ
Which is fastest — i2c, SPI or UART?
SPI, by a wide margin: tens of MHz, versus 100 kHz–1 MHz for i2c and typically up to a few Mbps for UART. If you're moving pixels to a display or blocks to an SD card, SPI. For sensors read a few times a second, the speed difference is irrelevant.
Which uses the fewest wires?
i2c and UART both use two signal wires, but differently: i2c's two are shared by every device on the bus, while UART's two (TX and RX) connect exactly one pair of devices. SPI needs three shared wires plus one chip-select per device, so it grows fastest as you add peripherals.
Can I use i2c, SPI and UART at the same time?
Yes — they're independent peripherals on separate pins. A very common layout is UART for a GPS or radio module, SPI for a fast display or SD card, and i2c for a chain of sensors, all on one microcontroller at once.
What is the difference between i2c and CAN bus?
i2c is a short-range, board-level bus (centimetres, one enclosure). CAN is a rugged, differential, multi-master bus built for metres of noisy automotive wiring with error handling built in. Same idea — a shared bus — at completely different scales; past a metre or so, CAN or RS-485 takes over from i2c.
Which should a beginner start with?
i2c. Two shared wires, addressable devices, and the plug-together Qwiic/STEMMA QT ecosystems mean you can chain sensors with no soldering and no wiring math. Move to SPI when a project needs the bandwidth, and to UART when you're talking to a single streaming module like GPS.
Go deeper on a pair
Three at once is a lot. If you've already narrowed it down, the head-to-heads go further: i2c vs SPI for the two-bus decision (the common one — displays and SD cards versus sensors), and i2c vs UART for the point-to-point case. Once you've picked i2c, what is i2c is the primer and how i2c works is the byte-level detail.