i2c vs UART
Different problem entirely from i2c vs SPI: UART isn't a bus at all — it's a point-to-point link. Here's when each one is the obvious choice.
Side by side
i2c vs UART: the trade-offs at a glance
| Property | i2c | UART |
|---|---|---|
| Wires | 2 (SDA + SCL), shared by all devices | 2 (TX, RX) — crossed, per link |
| Topology | bus — many devices, one pair of wires | point-to-point — exactly two devices |
| Clock | shared, on SCL | none — each side times its own bits |
| Device selection | 7-bit address in-band | n/a — only one device on the link |
| Drive | open-drain + pull-ups | push-pull, no pull-ups |
| Setup | address known, no rate to agree on | both ends must match baud rate |
| Typical use | sensors, RTCs, expanders, small displays | GPS, Bluetooth/WiFi modules, PC serial console |
The reasoning
Why i2c and UART don't compete for the same job
i2c and SPI both connect a controller to several peripherals, so comparing them is a real trade-off. UART connects exactly two devices, full stop — there's no addressing because there's nothing to address. That single design choice explains every other difference: no shared clock means both ends must independently agree on a baud rate beforehand (9600, 115200…) or bits land in the wrong place; no shared bus means the lines can be simple push-pull with no pull-up resistors at all, since nobody else is listening for a collision.
That's also why UART shows up everywhere it does: GPS modules, Bluetooth/WiFi radios, GSM modems and RS-232 debug consoles all stream continuous data to exactly one listener — a natural fit for a simple two-wire, no-clock, no-addressing link. The moment a project needs a second GPS module, though, UART has nothing to offer; that's squarely i2c's job.
The rule: exactly one other device, streaming continuously → UART. Several devices you'll read occasionally, especially ones that already ship as Qwiic/STEMMA QT breakouts → i2c. Most real projects use both — UART for a radio or GPS, i2c for the sensor chain — since the two peripherals never interact and cost nothing to run side by side.
Questions
i2c vs UART FAQ
Does UART need pull-up resistors like i2c?
No. UART's TX and RX lines are push-pull — each end actively drives both high and low — so there's nothing to pull up. That's also why UART has no shared-bus concept: it's strictly point-to-point, one TX/RX pair per link.
Can I connect more than two devices with UART?
Not on a simple TX/RX link — it's inherently point-to-point. Multi-drop variants exist (RS-485 turns UART framing into a shared differential bus), but plain 3.3 V/5 V UART only ever talks to one other device at a time.
Why do my UART devices need matching baud rates but i2c devices don't?
UART has no shared clock line — each side times its own bits internally, so both ends must agree on the bit rate in advance (9600, 115200, etc.) or the receiver samples at the wrong moments and gets garbage. i2c sends its clock on SCL, so the receiver just follows it — no rate to configure at all.
Which is better for GPS modules and Bluetooth/WiFi modules?
UART, almost universally — these modules stream continuous data (NMEA sentences, AT commands) rather than answering discrete register reads, and UART's simple two-wire point-to-point link suits that. i2c shines when several distinct devices share one bus instead.
Can I run i2c and UART on the same project?
Yes, freely — they're independent peripherals on separate pins with no interaction. A common layout is UART for a GPS or radio module and i2c for a chain of sensors, both wired to the same microcontroller at once.
Related comparisons
The comparison people reach for more often is i2c vs SPI — that's the real either/or, since both are buses that can carry many devices. Weighing all three at once? i2c vs SPI vs UART is the side-by-side. And if you're here because a part speaks UART and you wish it spoke i2c, the TFmini Plus is a good example of a sensor that does both — it ships in UART mode and needs one serial command to switch.