I2C vs SPI vs UART: A Beginner's Guide to Sensor Interfaces

Written and fact-checked by Compoden's engineering team, India. Every wire count, speed figure and pin behaviour below is standard to the protocol, not vendor-specific marketing. Published 24 August 2026 · Last updated 24 August 2026.

Open any sensor's datasheet and you'll see one of three acronyms: I²C, SPI, or UART. They're the three ways a sensor talks to your microcontroller, and none of them are interchangeable — a sensor built for I²C cannot be rewired onto SPI just by connecting different pins. You don't need to master the electrical theory to use any of them, but knowing what each protocol actually trades off makes wiring faster and debugging a lot less confusing when something doesn't respond.

What's the real difference between I2C, SPI and UART?

Interface	Wires	Typical speed	Devices per bus	Addressing	Best for
I²C	2 (SDA, SCL, shared)	100 kHz–400 kHz standard, up to 3.4 MHz	Many (address-based, up to 127)	7-bit address per device	Most sensors, OLED/LCD displays, IMUs
SPI	4 + 1 chip-select per device	Several MHz to tens of MHz	Many (one CS line each)	None — selected by CS pin, not an address	SD cards, fast displays, ADCs, flash memory
UART	2 (TX, RX, point-to-point)	9600–115200 baud typical	One (strictly one-to-one per pair)	None — wired, not addressed	GPS modules, GSM/SIM modules, board-to-PC serial

The pattern worth remembering: I²C trades speed for wire count and lets many devices share one bus by address. SPI trades wire count for speed and has no addressing at all — every device gets its own dedicated select line instead. UART has no addressing either, but it isn't a bus in the first place — it's a private line between exactly two devices, which is why you can't simply "add a third sensor" onto a UART link the way you can on I²C.

How does I2C actually let many devices share two wires?

I²C works because every device on the bus listens for its own 7-bit address before responding — SDA carries the data, SCL carries a shared clock the "controller" (usually your microcontroller) drives, and every device just watches the line and only replies when its own address is called. This is why the classic I²C failure is an address clash: two modules with the same fixed address (two identical OLED displays, for example) can't coexist on one bus without one of them being reconfigured, often via a solder jumper or an ADR pin pulled to a different level. The upside is real: a single ESP32 running a handful of GPIOs can talk to a temperature sensor, a pressure sensor, a real-time clock and a display all on the same two wires, at the cost of speed that tops out well below SPI.

Why is SPI faster, and what does that extra wire count actually cost?

SPI is faster because it has no addressing overhead and no shared-bus arbitration to negotiate — the controller drives a dedicated clock (SCK) and data lines (MOSI, MISO), and simply pulls a device's own chip-select (CS) line low to talk to it. Because each device needs its own CS pin, a build with four SPI devices needs four extra GPIOs beyond the three shared data/clock lines, which is the real trade-off: SPI is not "harder" to wire per device, it costs one more pin per device than I²C does. That's exactly why SPI shows up where raw throughput actually matters — an SD card writing a data log, or a colour display refreshing fast enough not to look laggy — and why it's a poor fit for a build with many low-speed sensors, since you'll run out of free GPIOs on the select lines long before you run out of bandwidth.

If UART can only talk to one device, why is it still useful?

UART is deliberately the simplest of the three — one wire out (TX), one wire in (RX), and both sides just need to agree on a baud rate (9600 and 115200 are the two you'll see most). There's no addressing and no bus to share because UART was never designed to be a bus at all — it's a direct serial link between exactly two devices, which is precisely why a GPS module, a GSM/SIM800-class modem, or a Bluetooth serial module each get their own dedicated UART pins (or a software-serial pair) rather than sharing a line the way I²C sensors do. The same protocol is what your board uses to talk to your computer over USB during upload and debugging — Serial.begin() in Arduino code is configuring the same UART hardware, just pointed at your laptop instead of a sensor.

When is the "slower" or "more wires" option actually the right choice?

Picking the fastest or the simplest option by default is exactly how a build ends up wired wrong. SPI genuinely is faster, but choosing it for a project with six low-speed sensors means burning six extra GPIOs on chip-select lines you didn't need — I²C's shared bus wins that build even though it's the "slower" option on paper. Conversely, I²C's shared-bus convenience is the wrong choice the moment two devices ship with the same fixed address and no way to change it — at that point, SPI's per-device select line stops being an inconvenience and becomes the only way to have both modules on the same board at once. And UART's one-to-one limitation, which looks like a weakness next to I²C's many-devices-per-bus design, is exactly why it's the right choice for a GPS module: nothing about talking to a GPS receiver benefits from bus-sharing, and UART's simplicity means less protocol overhead sitting between your firmware and the position fix.

Which interface does your ESP32 or Arduino support?

Every modern Arduino and ESP32 board exposes all three natively — the datasheet or pinout diagram will label the default I²C pins (SDA/SCL), the default SPI pins (MOSI/MISO/SCK, plus you choose any free GPIO for CS), and one or more UART ports (the ESP32 has three hardware UARTs; an Arduino Uno has one, shared with USB, which is why a second UART device on an Uno usually needs a software-serial library instead). Confirm the specific pin numbers for your exact board before wiring — they vary by board family even within the same chip series, and getting this wrong is one of the most common first-project debugging dead ends. Most breakout modules from our Sensors collection and Dev Boards collection ship with the interface already fixed by the manufacturer, so the practical question is rarely "which protocol should I pick" — it's "which pins does this specific module need," and Soldr will map that out for the exact board and part you're holding.

Frequently asked questions

Can a sensor use more than one interface?
Some can — many IMU and pressure-sensor chips support both I²C and SPI on the same silicon, with the mode selected by how one pin is wired at power-up. Once selected, only one interface is active; you can't use both at the same time on one device.

Do I2C aur UART mein kya difference hai?
I²C shares two wires across many devices using addresses, while UART is a private two-wire link between exactly one pair of devices with no addressing at all. If you need to add more than one device to a bus, I²C is built for that; UART is not.

Why won't my I2C device respond even though it's wired correctly?
The most common causes are an address clash with another device on the same bus, a missing pull-up resistor on SDA/SCL (some breakout boards omit it, assuming another module on the bus provides it), or a 3.3V device being driven by a 5V-logic board without a level shifter.

Is SPI always faster than I2C in practice?
Yes, at the protocol level — but the real-world difference depends on your clock configuration and cable length. For most beginner projects the difference only matters for SD cards and fast displays; a temperature reading once a second is comfortably inside I²C's speed even at its slowest setting.

Related reading: What Is UART Serial? Wiring and Errors, Logic Levels (3.3V vs 5V): Wiring and Common Errors, and see all three protocols wired for a real sensor in BMP280 Explained (I²C in practice, on a real ESP32 build).

Browse genuine, board-ready modules in our Sensors and Dev Boards collections. Wiring up something tricky? Ask Soldr for the exact connections on the exact board and part you have.