Wiring a sensor or a small screen to a microcontroller means meeting three initials that keep appearing in datasheets, I2C, SPI and UART. They are the common languages that chips use to pass data over a few wires, and choosing the wrong one leads to tangled wiring, slow readings or a bus that refuses to work with a second device. Each suits a different situation. Learning how they wire up, how fast they run and how many devices they handle lets you read a module’s datasheet and know at a glance which one your project actually needs.
How each one wires up
UART is the simplest. Two devices connect with two data wires that cross over, one sending while the other receives, plus a shared ground. There is no clock wire; both sides agree in advance on a speed, the baud rate, and each keeps its own timing. It is a point-to-point link between exactly two endpoints and nothing more.
I2C uses just two shared wires for everyone, a data line and a clock line, both pulled up to the supply voltage. Every device listens on the same pair, and each has a unique address so the controller can call one at a time. SPI uses a clock, two separate data lines for the two directions, and one extra select wire per device, so more chips mean more pins. Getting any of them working starts with the board’s connections, the ground covered in the primer on what the general-purpose pins do.
Speed, wiring and device count
These three traits trade against each other. SPI is the fastest, running into tens of megabits a second because it has dedicated lines and a shared clock, but each added device wants its own select pin, so the wiring grows with the count. It also lacks a built-in way for a device to confirm it received the data.
I2C trades speed for tidiness. Standard modes run at 100 or 400 kilobits a second, slower than SPI, but the two-wire bus stays two wires no matter how many devices hang off it, up to the limit of the addresses and the electrical load. UART sits in the middle for speed on short links and is refreshingly simple, but because it has no addressing it joins only two devices, which is why fanning out to many parts is not its job.
| Trait | I2C | SPI | UART |
|---|---|---|---|
| Wires | Two shared | Three plus one select each | Two plus ground |
| Typical speed | 100 to 400 kbit per second | Tens of Mbit per second | Low, set by baud |
| Devices | Many, by address | Many, one pin each | Two only |
| Clock wire | Yes, shared | Yes, shared | None |
| Best at | Several slow parts | Fast single devices | Simple two-way links |
Clocked and clockless links
A quiet but important split is whether a shared clock wire keeps both sides in step. I2C and SPI are synchronous: the controller drives a clock line that times every bit, so the two ends never drift apart and speeds can climb. UART is asynchronous, with no clock between the chips, so each side counts out bits from its own timer at the agreed baud rate.
That difference explains their limits. A clocked bus tolerates higher speeds and longer device chains because the timing is shared, while a clockless link is simpler and needs fewer wires but depends on both ends holding matched rates. A small mismatch in baud settings garbles UART data, a common first stumble when two boards refuse to understand each other.
Which parts use each
Datasheets tend to sort themselves by need. Small environmental sensors, the temperature, humidity, pressure and light chips, and real-time clocks usually speak I2C, since they send little data and benefit from sharing two wires with several siblings on one bus. Reading a handful of these at once is a natural fit, the kind of task the primer on pulling readings from sensors works through.
SPI shows up where data moves fast or in bulk, such as memory cards, colour displays and high-rate motion sensors, because its speed keeps the screen or card responsive. UART carries streams between whole modules, GPS receivers, some radio and Bluetooth boards, and the debugging console that prints text back to your computer. The right bus is often decided for you the moment you choose the part.
Choosing for a project
Let the module decide first, because a part often supports only one interface and the datasheet settles it. Where you do have a choice, match the protocol to the shape of the problem. Several slow sensors sharing a couple of wires point to I2C. One device that must be fast, a display or a memory card, points to SPI. A single stream to or from another board points to UART.
Pin budget matters on small boards. If pins are scarce and you have many parts, I2C keeps the wiring down. If one part must run quickly and you can spare the pins, SPI earns them. When a design outgrows a single controller and boards must talk to each other, that is a broader question addressed in the explainer on linking multiple boards, which reaches past any single bus.
Where this leaves you
The three are not rivals so much as tools for different jobs, and most real projects use more than one at the same time. A typical build might read four I2C sensors on two wires, drive an SPI screen for speed, the kind of panel the notes on fitting a screen to a build cover, and keep a UART line open to a computer for debugging, all from one microcontroller without conflict.
When you are unsure, count your devices and their speed. Many slow parts favour the shared two-wire bus, one fast part favours dedicated lines, and a lone stream between two endpoints favours the clockless pair. Start from those questions, check what the specific chip supports, and the right choice usually names itself before you pick up a single jumper wire.
Quick answers
What is the difference between I2C and SPI?
I2C uses two shared wires and device addresses to talk to many chips, trading speed for low wiring. SPI uses separate data lines, a clock and a select wire per device, which makes it much faster but adds a pin for every chip. In short, I2C favours many slow parts on few wires, while SPI favours fewer parts that need speed.
Which protocol should I use for a sensor?
Check the sensor’s datasheet first, since many support only one. If it offers a choice and you are reading several small, slow sensors, I2C keeps the wiring to two shared lines. If the sensor streams data quickly, such as a high-rate motion chip, SPI suits it better. For most temperature, humidity and pressure parts, I2C is the common and convenient pick.
Why does UART only connect two devices?
UART has no addressing scheme and no shared select mechanism, so nothing on the line can say which device a message is meant for. Its two data wires simply carry a stream from one endpoint to the other and back. Without a way to single out targets, adding a third device would leave them talking over each other, so UART stays a point-to-point link between two parts.
