Serial protocols: UART, SPI, I2C

ALearning Material

Microcontrollers rarely work alone: they talk to sensors, displays, memory, and other chips. They do so over serial communication protocols, where data is sent one bit at a time over a few wires. The three you'll use constantly (‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍UART, SPI, and I2C) each suit different situations, and knowing which to use (and how each works) is essential to interfacing any peripheral.

UART (Universal Asynchronous Receiver/Transmitter): asynchronous point-to-point serial: two wires (TX, RX), no shared clock (both sides agree on a baud rate). Simple, common for device-to-device or to a PC (e.g. debug output, a GPS module). Two devices only.

SPI (Serial Peripheral Interface): synchronous (a shared clock), fast, full-duplex, master/ slave with usually 4 wires (clock SCLK, MOSI, MISO, and a chip-select per slave). Fast and simple per-device, but needs a separate chip-select line for each slave. Good for high-speed peripherals (displays, SD cards, fast ADCs).

UART: TX <-> RX        (2 wires, async, baud rate, 2 devices)
SPI:  SCLK, MOSI, MISO, + CS per slave   (sync, fast, full-duplex, a wire per slave)
I2C:  SDA, SCL         (2 wires shared bus, addressed devices, many on one bus)

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍I2C (Inter-Integrated Circuit): synchronous, only two wires (data SDA + clock SCL) shared by many devices, each with a unique address. Slower than SPI but very wire-efficient: many sensors on one two-wire bus. Great for connecting lots of low-speed sensors. The choice: UART for simple two-device async links; SPI for speed (few devices, but a wire per slave); I2C for many devices on few wires (addressed bus, slower). The disciplines: know the three protocols and their wires/speed/topology, and choose by the situation (simple link / speed / many-devices-few-wires). These are how an MCU connects to the world.

Syntax you need here. The three buses, in the form you actually type. Each has a setup call, a transfer call, and one parameter that must match at both ends:

// UART - asynchronous, point to point. THE BAUD RATE MUST MATCH ON BOTH SIDES.
Serial.begin(115200);                  // start the port at 115200 baud
Serial.print(value);                   // no newline
Serial.println("text");                // with a newline
Serial.printf("t=%lu v=%d\n", t, v);   // where the core provides it
if (Serial.available()) {              // bytes waiting in the receive buffer
    char c = Serial.read();            // one byte; -1 if nothing is there
}
Serial.readStringUntil('\n');          // a whole line, up to the delimiter

// I2C - two wires, many devices, each with a 7-bit ADDRESS
Wire.begin();
Wire.beginTransmission(0x68);          // the device address
Wire.write(REG_ADDR);                  // usually: which register you want
Wire.endTransmission(false);           // false = repeated START, keep the bus
Wire.requestFrom(0x68, 2);             // read 2 bytes back
uint8_t hi = Wire.read(), lo = Wire.read();

// SPI - four wires, fast, one chip select PER device
SPI.begin();
SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0));
digitalWrite(CS, LOW);                 // select THIS device: active LOW
uint8_t in = SPI.transfer(out);        // full duplex: one byte out, one byte in
digitalWrite(CS, HIGH);                // deselect
SPI.endTransaction();

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍The parameter that must match is different for each bus, and getting it wrong fails differently. UART needs the baud rate agreed in advance, because there is no clock line: a mismatch gives consistent garbage rather than silence, which is the signature to recognise. I2C needs the address, and a device that is absent, unpowered or at a different address simply does not acknowledge, so endTransmission returns non-zero and you read zeros or 0xFF. SPI needs the mode, the clock polarity and phase pair, and a mode mismatch gives data shifted by one bit, which looks like a plausible but wrong number.

Two habits save time. Print at a fixed rate rather than every loop iteration, since a serial port at 115200 baud carries about 11 kilobytes per second and a chatty loop blocks on the transmit buffer, which quietly turns a fast control loop into a slow one. And pull the I2C bus up: SDA and SCL are open-drain and do not idle high without resistors, typically 4.7 kilohms, which many breakout boards already carry.

Why it exists. A microcontroller must communicate with many peripherals (sensors, displays, memory, other MCUs), and serial protocols send data over a few wires. UART, SPI, and I2C are the three standard choices, each with different speed, wiring, and topology trade-offs, so knowing how each works and when to use it is essential to interfacing any peripheral, the core of connecting an embedded system to the world.

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍Mental model. The three protocols are like three ways to have a conversation. UART is two people talking directly with no clock, just an agreed pace (baud rate), simple but only two of them. SPI is a fast conversation led by a conductor's beat (the clock), but you need a separate 'attention' line to address each listener. I2C is a group on a party line (two shared wires) where you call each device by name (address) before talking. Many can share, but it's slower.

Common misunderstandings.

• "All serial protocols are interchangeable." They differ in speed, wires, and topology: UART (2 devices, async), SPI (fast, a wire per slave), I2C (many devices, 2 shared wires, addressed, slower), choose by the situation.
• "SPI vs I2C is just speed." It's also wiring/topology: SPI needs a chip-select per slave (more wires for many devices), while I2C shares two wires among many addressed devices. I2C wins on wire count, SPI on speed.
• "UART needs a clock line." UART is asynchronous‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍, no shared clock; both sides just agree on the baud rate, which is why a mismatched baud rate garbles the data.

Connections. Serial protocols build on the GPIO/peripherals of the MCU (the GPIO lesson and the Turn-2 STM32 lesson: the MCU has UART/SPI/I2C peripherals), are how the projects read sensors and report data (the UART reporter project, the data loggers), use DMA for efficiency (the Turn-2 STM32-peripherals lesson), and connect to the C++/Python serial lessons (the host side). The standard way an embedded system talks to peripherals.

BImmediate Active Recall

CConceptual Questions

Answer each in your own words in the box, then reveal the model answer to compare. These ask why, not how, and your answers are saved.

DPractice Problems

P1 (easy). Compute the bus loading for a sensor node.

(a) A UART runs at 115200 baud, 8N1. Compute the bits per character frame, the byte rate, and the time to send one byte. How long does a 40-byte telemetry line take? (b) An I2C bus at 400 kHz polls six sensors at 50 Hz. Each read is: start, address byte, register byte, repeated start, address byte, six data bytes, stop, with every byte costing 9 bit-times (8 data plus the acknowledge). Compute the bits and the time per transaction, the total bus time per 20 ms cycle, and the bus utilisation.

P2 (medium). Choose the bus for four peripherals on one board, and justify each on a number: an ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍SD card logging at 200 kB/s, a temperature sensor read once a second, a 9-axis IMU read at 500 Hz returning 18 bytes, and a debug link to a PC.

Give the bus, the clock rate needed, the pin count, and the one attribute that decides it. Then state what goes wrong if the IMU is put on the same I2C bus as the temperature sensor at 100 kHz.

P3 (harder). Two boards exchange data over UART and receive garbage: mostly plausible-looking bytes with occasional framing errors.

Work through the diagnosis: list the candidate causes in the order you would check them, with the specific symptom each produces and the measurement that confirms it. Compute the worst-case clock tolerance a UART link can survive and say where that number comes from. Finish with the design change that removes the whole class of problem.

EFeynman Exercise

Explain to a beginner, using three ways to have a conversation: (1) two people talking directly at an agreed pace with no conductor (UART): simple but only two of them, (2) a fast conversation led by a conductor's beat where you need a separate 'attention' signal for each listener (SPI), and (3) a group on a shared party line where you call each person by name before talking (I2C). Many can share but it's slower.

FError Analysis Framework

• Treating UART, SPI, and I2C as interchangeable. Why: they're all serial. Recognise: they differ in speed/wires/topology; the wrong one fits poorly. ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍Avoid: choose by the situation (simple link / speed / many devices on few wires).
• Thinking SPI vs I2C is only about speed. Why: SPI is faster, so use it. Recognise: you ignore wiring. SPI needs a chip-select per device; I2C shares 2 wires. Avoid: weigh speed (SPI) vs wire-efficient many-device bus (I2C).
• Expecting UART to have a clock line. Why: synchronous serial has a clock. Recognise: UART is async, no clock; a baud mismatch garbles data. Avoid: set both sides to the same baud rate (no shared clock to resync).
• Hanging many SPI devices off one chip-select. Why: fewer wires is simpler. Recognise: SPI addresses slaves by separate chip-selects; sharing one breaks it. Avoid: give each SPI slave its own chip-select (or use I2C for many devices).

GMini Challenge

Design the peripheral communication for an embedded sensor node: it must connect to a PC for debug, a fast display, and several low-speed environmental sensors. Choose the protocol for each, specify the wiring, and explain how matching each protocol to the situation interfaces everything efficiently.

Quiz Check

A quick auto-graded check, separate from the recall cards above. Your score is pooled with the recall cards into this module's Mastery score, and completing this lesson requires the quiz submitted with pooled mastery at 80% or above.