UART vs I2C vs SPI: Which Protocol to Use and Why

Quickstart

Use this as a fast chooser when you’re staring at a dev board and a pile of sensors. If you do nothing else, decide your top constraint (wires, speed, distance, number of devices) and pick the protocol that matches it.

Overview

UART, I2C, and SPI are the “workhorse” serial protocols you’ll see across microcontrollers, sensor boards, radios, and SBCs. They overlap in what they can do, but they differ in wiring, bus topology, timing, and failure modes. Choosing well makes your design cheaper, more reliable, and easier to debug.

Core concepts

Think of these protocols as answers to two questions: Who decides when bits move? and How do devices share the wires? Once you internalize that, “which one should I use?” gets much easier.

1) Asynchronous vs synchronous

UART is asynchronous: both sides must agree on the “beat” (baud rate) ahead of time, then decode bits by timing. I2C and SPI are synchronous: the clock line defines when bits are sampled, which tends to be more robust at speed — but adds wiring and timing rules.

2) Push-pull vs open-drain (why I2C needs pull-ups)

I2C lines are typically open-drain/open-collector: devices can pull the line low, but they don’t drive it high. A resistor (pull-up) brings the line back high. This enables safe multi-device sharing on the same wire, but it also means the rise time depends on resistance and bus capacitance — a common source of flaky I2C.

3) Addressing vs chip-select

I2C uses addresses on the bus. You can connect many devices as long as their addresses don’t collide and the bus stays electrically healthy. SPI usually uses a dedicated chip select (CS) per slave device: it scales well electrically at high speed, but costs GPIO pins.

4) Full-duplex vs half-duplex

UART is effectively full-duplex with separate TX/RX lines. SPI is naturally full-duplex (MOSI and MISO) during a transaction. I2C is typically half-duplex on the shared SDA line (one direction at a time), which is fine for sensors and control.

Step-by-step

Here’s a practical workflow that avoids the most common traps. The goal is not “pick a protocol” — it’s to pick one that works reliably in your environment and stays easy to debug months later.

Step 1 — Write your constraints (30 seconds)

Step 2 — Choose using the decision matrix

Step 3 — Wire it like you want it to work

Step 4 — Validate with a 2-minute smoke test

Before writing “real” firmware, do a quick loopback or discovery test. It catches 80% of integration issues early. The snippet below focuses on common Linux/SBC workflows (USB-UART dongles and quick CLI checks).

# UART smoke test (Linux):
# 1) Identify the device (examples: /dev/ttyUSB0, /dev/ttyACM0, /dev/serial0)
ls -l /dev/ttyUSB* /dev/ttyACM* 2>/dev/null

# 2) Configure and listen (115200 8N1, raw, no echo)
stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb -ixon -ixoff raw -echo
cat /dev/ttyUSB0

# 3) In another terminal, send a line
echo "ping" > /dev/ttyUSB0

# I2C presence check (Linux):
# - Requires i2c-tools. If you see addresses in the grid, your wiring + pull-ups likely work.
sudo i2cdetect -y 1

Step 5 — Implement the first “known good” transaction

Your first goal is a minimal transaction you can reproduce. For I2C, that might be “scan the bus then read one register.” For SPI, it might be “read device ID.” Once that works, build upward.

#include <Wire.h>

static bool i2cReadReg(uint8_t addr7, uint8_t reg, uint8_t *out, size_t n) {
  Wire.beginTransmission(addr7);
  Wire.write(reg);
  if (Wire.endTransmission(false) != 0) {  // false = repeated start
    return false;
  }
  size_t got = Wire.requestFrom((int)addr7, (int)n, (int)true);
  for (size_t i = 0; i < got; i++) out[i] = (uint8_t)Wire.read();
  return got == n;
}

void setup() {
  Serial.begin(115200);
  Wire.begin();          // SDA/SCL pins are board-specific
  Wire.setClock(100000); // start slow; increase after it's stable

  // Quick I2C scan (prints discovered 7-bit addresses)
  Serial.println("I2C scan:");
  for (uint8_t a = 1; a < 127; a++) {
    Wire.beginTransmission(a);
    if (Wire.endTransmission() == 0) {
      Serial.print(" - found 0x");
      if (a < 16) Serial.print('0');
      Serial.println(a, HEX);
    }
  }

  // Example register read
  const uint8_t dev = 0x76; // change to your device address
  uint8_t whoami = 0x00;    // change to your register (e.g., WHO_AM_I)
  uint8_t val = 0;
  if (i2cReadReg(dev, whoami, &val, 1)) {
    Serial.print("Reg 0x00 = 0x");
    if (val < 16) Serial.print('0');
    Serial.println(val, HEX);
  } else {
    Serial.println("I2C read failed (check address, pull-ups, wiring, clock).");
  }
}

void loop() {}

Step 6 — SPI example: read a device ID (transaction discipline)

SPI isn’t hard — it’s strict. Most issues come from CS timing, wrong SPI mode, or clocking faster than your wiring can handle. The snippet below shows a simple JEDEC ID read (common for SPI flash). Even if you’re not using flash, the structure is reusable: assert CS → transfer → deassert CS.

#include <SPI.h>

static const int PIN_CS = 10; // change for your board

void setup() {
  Serial.begin(115200);
  pinMode(PIN_CS, OUTPUT);
  digitalWrite(PIN_CS, HIGH);

  SPI.begin();

  // These settings MUST match the device datasheet:
  // - clock speed: start low (e.g., 1 MHz), increase later
  // - data mode: SPI_MODE0/1/2/3 (CPOL/CPHA)
  SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0));

  // Read JEDEC ID (0x9F) - typical for SPI flash
  digitalWrite(PIN_CS, LOW);
  SPI.transfer(0x9F);
  uint8_t manufacturer = SPI.transfer(0x00);
  uint8_t memoryType   = SPI.transfer(0x00);
  uint8_t capacity     = SPI.transfer(0x00);
  digitalWrite(PIN_CS, HIGH);

  SPI.endTransaction();

  Serial.print("JEDEC ID: ");
  Serial.print(manufacturer, HEX); Serial.print(" ");
  Serial.print(memoryType, HEX);   Serial.print(" ");
  Serial.println(capacity, HEX);

  Serial.println("If this looks wrong: check SPI mode, CS pin, wiring, and lower SCLK.");
}

void loop() {}

Common mistakes

If you’ve ever said “the datasheet says it should work,” this section is for you. These are the repeat offenders that cause most UART/I2C/SPI headaches in real builds.

FAQ

Is UART the same thing as RS-232?

No. UART is a digital serial framing method (start/stop bits, baud rate). RS-232 is a physical/electrical standard with different voltage levels and signaling conventions. If you connect TTL UART directly to RS-232, it often won’t work (and can be unsafe).

How many devices can I put on an I2C bus?

Practically: as many as you can support without address conflicts and without breaking the bus electrically. The limiting factors are usually pull-ups, bus capacitance (wiring length + device inputs), and whether devices behave well with clock stretching and arbitration. If the bus gets flaky, split it (multiple I2C peripherals) or slow it down.

Why does SPI need more wires than I2C?

SPI trades pins for speed and simplicity of timing. I2C shares two lines among many devices using addressing, while SPI typically needs a chip select per device so the master can talk to one slave at a time with minimal overhead.

What’s the biggest “gotcha” for each protocol?

UART: configuration mismatch and level standards. I2C: pull-ups and address confusion. SPI: mode/CS timing and signal integrity at high clocks. If you remember those three, you’ll avoid most pain.

Can I run I2C over a long cable?

You can, but it’s often a trap. I2C was designed for short, on-board connections. Long cables add capacitance and noise. If you must, lower clock speed, use proper cabling and grounding, and consider bus extenders or switching to a differential protocol for reliability.

What if I need both speed and multiple devices?

A common pattern is: I2C for slow control/sensors and SPI for high-bandwidth devices (display, flash, high-rate ADC). Split responsibilities rather than forcing one protocol to do everything.

Cheatsheet

A scan-fast summary you can keep open while wiring and configuring.

Wrap-up

UART, I2C, and SPI all move bytes — but they shine in different scenarios: UART for simple point-to-point and debugging, I2C for many low/medium-speed peripherals on two wires, and SPI for fast, clocked transfers when you can afford chip-select pins.

The fastest way to get unstuck is to treat bus bring-up as a short, repeatable process: confirm electrical basics, pick conservative settings, validate one transaction, then scale. If you save one thing from this post, save the Cheatsheet.

Related posts

• Toolchains Explained: GCC, Clang, and Cross-Compiling
• ESP32 Starter Guide: GPIO, Wi-Fi, and Real Projects
• Arduino to Prototyping: Sensors, Actuators, and Clean Wiring
• Raspberry Pi as a Home Server: Safe Setup and Use Cases
• MQTT Explained: The Message Bus Behind Many IoT Systems
• Bluetooth Low Energy Basics: Advertising, GATT, and Power