Serial Protocol Selection Guide: UART, I2C, SPI, and RS-485 Compared

A serial protocol transmits data one bit at a time sequentially over a shared medium. While modern microcontrollers like the ESP32 or STM32 support dozens of peripheral interfaces, 95% of embedded hardware designs rely on just four foundational serial protocols: UART, I2C, SPI, and RS-485. Choosing the wrong one leads to signal degradation, bus lockups, and wasted GPIO pins. This guide cuts through the theory and provides a decision-forward framework to select, wire, and debug the exact serial protocol your project requires.

The Physical Layer: Bus Mechanics and Wiring Requirements

Before writing a single line of code, you must understand the physical constraints of the bus. A protocol is only as robust as its physical layer. Below is the definitive bus mechanics reference for standard 3.3V/5V embedded systems.

Physical Wiring and Pull-Up Requirements

The most common hardware mistake in serial communication is ignoring the physical biasing of the lines. Here are the strict physical requirements for each bus:

• I2C Pull-Ups: I2C uses open-drain outputs. The bus physically requires pull-up resistors to the logic high voltage (usually 3.3V). The standard value is 4.7kΩ. If your bus capacitance exceeds 200pF (e.g., long wires or many devices), drop the resistor to 2.2kΩ to maintain the RC rise-time constant, otherwise the SDA/SCL edges will round off and cause bit errors.
• SPI Chip Selects: SPI does not use addressing; it uses individual Chip Select (CS) lines. Every slave needs its own CS wire routed back to the master. CS lines are typically active-low and must be pulled high (10kΩ) to prevent false triggering during microcontroller boot-up when GPIOs are floating.
• RS-485 Termination: RS-485 uses differential signaling (A and B lines). For runs over 10 meters or speeds above 115.2 kbps, you must place a 120Ω termination resistor across the A and B lines at both physical ends of the bus to match the characteristic impedance of standard twisted-pair cable and prevent signal reflections.
• UART Common Ground: UART is single-ended. The TX and RX lines are referenced to ground. If the ground potential between the two devices differs by more than a few volts, you will fry the UART transceiver. Always run a dedicated GND wire alongside TX/RX.

Decision Tree: Picking Your Protocol by Constraints

Stop guessing. Use this decision matrix to map your project constraints directly to a specific protocol and a concrete hardware implementation.

Minimal Working Exchange: Wiring and Code

Abstract theory fails on the workbench. Below are minimal, verified wiring and code exchanges for the two most common embedded scenarios: an I2C environmental sensor and a UART GPS receiver, both hosted on an ESP32 DevKit v1.

Scenario A: I2C Sensor (BME280) to ESP32

Wiring Table:

Code (Arduino IDE / ESP32 Core):

#include <Wire.h>
#include <Adafruit_BME280.h>

Adafruit_BME280 bme;

void setup() {
  Serial.begin(115200);
  // Initialize I2C with custom pins if needed, otherwise defaults are 21/22
  Wire.begin(21, 22); 
  
  if (!bme.begin(0x76)) { // 0x76 is default for Adafruit, 0x77 for Bosch raw
    Serial.println("Could not find a valid BME280 sensor, check wiring!");
    while (1);
  }
}

void loop() {
  Serial.print("Temp: "); Serial.print(bme.readTemperature());
  Serial.print(" *C | Pressure: "); Serial.print(bme.readPressure() / 100.0F);
  Serial.println(" hPa");
  delay(2000);
}

Scenario B: UART GPS (NMEA) to ESP32

Wiring Table:

Code (Arduino IDE / ESP32 Core):

#include <HardwareSerial.h>

// Use UART2 (GPIO 16 RX, GPIO 17 TX)
HardwareSerial gpsSerial(2);

void setup() {
  Serial.begin(115200); // Debug console
  gpsSerial.begin(9600, SERIAL_8N1, 16, 17); // GPS baud, format, RX pin, TX pin
}

void loop() {
  while (gpsSerial.available()) {
    char c = gpsSerial.read();
    Serial.write(c); // Stream NMEA sentences to debug console
  }
}

Classic Failures and How to Sniff the Bus

When the bus fails, it rarely fails silently. Here are the three most common physical and logical failures, their exact symptoms, and how to debug them using modern tools.

1. The Missing Pull-Up (I2C)

Symptom: The microcontroller hangs on Wire.endTransmission(), or the I2C scanner sketch returns no devices. A multimeter reads SDA and SCL floating randomly between 0.5V and 1.5V instead of a solid 3.3V idle state.
The Fix: Solder 4.7kΩ resistors between SDA and 3.3V, and SCL and 3.3V. Many cheap breakout boards include 10kΩ pull-ups, which are too weak for buses with more than two devices. Parallel them or add external 4.7kΩ resistors to lower the equivalent resistance.

2. Baud Rate Mismatch (UART)

Symptom: The serial monitor outputs garbage characters, diamond symbols, or random ASCII instead of readable text.
The Fix: Verify the exact baud rate of both devices. A common trap is GPS modules that default to 38400 baud while the host code initializes at 9600. Use an oscilloscope to measure the width of the start bit (the first low pulse). A 104µs start bit width equals 9600 baud; an 8.6µs width equals 115200 baud.

3. Address Clash and NACKs (I2C)

Symptom: You wire two identical sensors (e.g., two INA219 current monitors) to the same bus, but only one responds. The second sensor throws a NACK (Not Acknowledged) error.
The Fix: Run an i2c_scanner sketch to map the bus. If both devices default to address 0x40, you must physically alter the address. On the INA219, this requires bridging specific A0/A1 jumper pads on the PCB with solder. If the device lacks address pins, insert a TCA9548A I2C Multiplexer to route the master to isolated downstream buses.

How to Sniff and Debug the Bus

When a multimeter isn't enough, you need to see the digital waveform. The industry standard for bench debugging is a logic analyzer.

• The Tool: A Saleae Logic 8 (or a cheaper Sigrok/PulseView compatible clone like the $15 FX2LP-based analyzers) is mandatory for serious protocol work.
• Sample Rate Rule: Always set your logic analyzer sample rate to at least 4 times the bus speed. For a 400 kHz I2C bus, sample at a minimum of 2 MS/s (Mega-samples per second). For a 10 MHz SPI bus, you need at least 40 MS/s to accurately capture the clock edges and decode the MOSI/MISO data.
• Protocol Decoding: Modern software like Saleae Logic 2 or PulseView will automatically decode the raw 1s and 0s into human-readable hex values, register addresses, and ACK/NACK bits, instantly revealing if a slave is ignoring the master's register write commands.

By anchoring your design to the physical constraints of the bus, wiring the required biasing components, and verifying the waveform with a logic analyzer, you eliminate the guesswork from embedded serial communication. Default to I2C for local sensors, SPI for high-speed payloads, and RS-485 for long-haul industrial links, and your hardware will communicate reliably on the first power-up.