I2C vs SPI vs UART: Choosing the Right Microcontroller Peripheral Bus

Why the three buses still matter #

Every microcontroller board eventually has to talk to something else — a sensor, a display, a memory chip, a wireless module or a host computer. Long before USB, Ethernet or PCIe enter the picture, most of that conversation happens over three low-speed serial interfaces: I2C, SPI and UART.

They are not competitors in the sense that one is "best." Each makes a different trade between pin count, speed, wiring complexity and how many devices can share the same wires. Understanding those trade-offs is what lets an engineer pick the right bus instead of copying the last schematic they saw.

This guide compares the three on the dimensions that actually drive a design decision, then looks at how the choice shows up in real components buyers specify every day.

I2C: two wires, many devices #

I2C (Inter-Integrated Circuit, often written I²C) is a synchronous, multi-master, multi-slave bus that uses just two open-drain lines: SDA (serial data) and SCL (serial clock). Both are held high by pull-up resistors and pulled low by whichever device is driving.

Each transaction begins with a 7-bit or 10-bit address that selects one slave, which is why many devices can share the same two wires. The clock is generated by the master, so slaves do not need their own timing reference.

Typical speed tiers:

• Standard mode — 100 kbit/s
• Fast mode — 400 kbit/s
• Fast mode plus — 1 Mbit/s
• High-speed mode — 3.4 Mbit/s

Where I2C shines:

• Boards crowded for pins — two wires serve a whole network of peripherals.
• Slow control paths: temperature sensors, PMICs, RTCs, small EEPROMs, touch

controllers.

• Systems where you want to probe "what is on the bus" by scanning addresses.

The cost is speed and some protocol overhead. The open-drain lines and pull-ups also limit how fast you can reliably toggle, and bus capacitance restricts cable length and device count.

SPI: fast, simple, point to point #

SPI (Serial Peripheral Interface) is a synchronous, full-duplex bus built around four signals:

• SCLK — clock driven by the master
• MOSI — master out, slave in
• MISO — master in, slave out
• CS/SS — chip-select, one dedicated line per slave

There is no addressing in SPI. Instead, a separate chip-select line tells each slave when to listen. That makes the hardware simple but costs a pin per device.

SPI has no official speed ceiling in the same way I2C does; in practice it runs from a few Mbit/s up to tens of Mbit/s on capable MCUs. Because it is full duplex and unaddressed, it is the default choice for:

• Flash and serial memory (NOR/NAND, EEPROM)
• Display and touch interfaces
• ADCs, DACs and radio front ends that move real data, not just registers
• Any peripheral where throughput matters more than pin savings

The main downside is wiring: every additional device needs another CS line, and long shared-clock runs can get noisy at high speeds.

UART: asynchronous, peer to peer #

UART (Universal Asynchronous Receiver/Transmitter) is the oldest of the three and the simplest in concept. Two devices exchange bytes over TX and RX lines with no shared clock. Instead, both sides agree on a baud rate and sample the line at fixed intervals.

Because there is no clock line, UART is strictly point to point — one TX talks to one RX. Common baud rates range from 9600 up to several Mbit/s, depending on the silicon and signalling levels.

A couple of practical notes:

• The raw logic-level UART (3.3 V or 5 V) is often converted to a standard

interface. A USB-to-UART bridge such as FT232RL lets a PC talk to a board's debug console. RS-232 adds ±12 V signalling for legacy gear, and RS-485 turns the pair into a differential bus that reaches long distances and supports multi-drop networks.

• UART has no addressing and no built-in error checking beyond an optional

parity bit, so protocol framing is the application's responsibility.

UART remains the workhorse for boot logs, firmware download, GPS modules, Bluetooth/Wi-Fi AT commands and general debug — anywhere a simple text or byte stream between two nodes is enough.

How to choose: a practical comparison #

The decision usually comes down to how many devices you have, how fast the data is, and how many pins you can spare.

A useful rule of thumb:

• Many sensors, tight on pins → I2C.
• One fast device, throughput critical → SPI.
• Talking to a host, a module, or a console → UART.

Real boards almost always use all three at once. An STM32F103C8T6, for example, integrates I2C, SPI and several UARTs on the same package, so the question is not which bus wins but how each peripheral is wired.

Sourcing notes for common bridge and MCU parts #

The bus you pick shows up directly in the bill of materials. A few patterns recur across designs:

• USB-UART bridges such as FT232RL turn a PC's USB port into a logic-level

serial link for programming and debug. They are commodity parts with long lifecycles but occasional allocation pressure during peak demand.

• MCUs with all three interfaces — the STM32F103 family is a common example

— let one chip serve sensors (I2C), flash (SPI) and a host link (UART) without external glue logic.

• SPI serial flash (Winbond W25Q and similar) remains the default firmware

store, which is why SPI is rarely optional on a modern board.

• When a design needs to reach outside the enclosure, a UART-to-RS-485

transceiver extends the same protocol across meters of cable in industrial and automotive environments.

For any of these, confirm the exact orderable part number, package and date code before committing to stock, because suffix and temperature-grade differences between otherwise identical parts are easy to miss.

Conclusion #

I2C, SPI and UART are not outdated relics — they are the everyday glue that connects an MCU to the rest of a design. I2C saves pins for many slow devices, SPI delivers speed for memory and data paths, and UART gives a simple peer link for consoles and modules. Most boards use all three, so the real task is matching each peripheral to the bus whose trade-offs fit it, then specifying the exact bridge, transceiver or microcontroller that implements it.