The Repair LibraryRead · Learn · Master

Buses and Communication Protocols — I2C, SPI, UART

How digital chips talk to each other — the bus concept, parallel versus serial, and the three staple serial protocols (UART, SPI, I2C) with their wires, trade-offs, and faults.

IntermediateLow Risk28 min read

What You Will Learn

  • You will learn what a bus is — a shared communication channel between chips — and the difference between parallel and serial communication.
  • You will learn the UART protocol: asynchronous, two-wire, framed by a baud rate and start/stop bits.
  • You will learn the SPI and I2C protocols: their wires, their shared clocks, and how each selects a device.
  • You will learn to tell the three protocols apart and to diagnose common bus faults.

What You Will Be Able To Do

  • You will be able to explain what a bus is and contrast parallel with serial communication.
  • You will be able to describe UART: asynchronous, TX/RX, baud rate, and start/stop framing.
  • You will be able to describe SPI and I2C — their wires, clocking, and device selection — and compare all three.
  • You will be able to identify which protocol a set of wires is and diagnose common bus faults.

Required Tools

No physical tools required. This is a conceptual section.

Section Overview

A digital system is rarely one chip — it's a processor talking to memory, sensors, displays, and other controllers, all of which must exchange data. This section is about how they talk. It starts with the bus — a shared set of wires that carries data between devices — and the choice between parallel communication (many bits at once over many wires) and serial (one bit at a time over few wires), which now dominates. Then it covers the three serial protocols you will meet constantly on real boards: UART, the simple asynchronous two-wire link; SPI, the fast clocked four-wire link; and I2C, the two-wire addressed bus that connects many devices. You'll learn each one's wires and trade-offs, how to tell them apart at a glance, and how to diagnose the faults each is prone to. This is how the isolated logic of the previous sections becomes a communicating system.

Why This Matters

Almost every fault that isn't inside a single chip is a communication fault — a sensor that won't respond, a display that stays blank, two boards that won't talk. Knowing the common protocols lets you recognize what you're looking at from the pin names and wire count, know what a healthy signal should look like on a scope, and target the right cause: a missing pull-up on an I2C bus, a baud rate mismatch turning UART data into garbage, a chip-select line stuck on SPI. These three protocols — UART, SPI, and I2C — appear in a huge share of electronics, from microcontroller boards to appliances to instruments, so they are among the highest-value things a technician can recognize and diagnose. This section turns "the chips aren't talking" from a mystery into a systematic check of a known, small set of possibilities.

Required Prerequisites

No consumables required. A microcontroller board with I2C, SPI, and UART peripherals makes ideal, reusable study material, but nothing is used up.

  • Optional: a microcontroller board and a couple of serial peripherals (an I2C sensor, an SPI display), plus pull-up resistors for the I2C lines
  • An oscilloscope or, ideally, a logic analyzer with protocol decoding to see the actual bus traffic; a USB-to-serial adapter for UART
  • No special hardware is required; the section stands on the concepts and recognizing the protocols

Real-World Applications

These three protocols are everywhere. I2C connects sensors, real-time clocks, small displays, and configuration chips to a controller using just two shared wires — open the average gadget and the SDA/SCL pair is usually there. SPI drives displays, SD cards, flash memory, and fast sensors where speed matters. UART is the classic serial link — device consoles, GPS modules, Bluetooth and cellular modems, and the debug port on countless boards. On the repair bench, recognizing which protocol a set of pins uses, confirming there's activity on the lines with a scope or logic analyzer, and knowing each protocol's typical faults is a core skill for any board where two parts must communicate — which is nearly all of them.

Common Challenges

  • Confusing the protocols. UART, SPI, and I2C look similar at first, but they differ in wire count, whether they share a clock, and how a device is selected. Anchoring each to its wires and clocking keeps them straight.
  • Forgetting I2C's pull-ups. I2C's two lines are open-drain and require pull-up resistors to work; without them, or with a line stuck LOW, the whole bus hangs. It's a common and easily-missed cause.
  • Mismatched settings. A UART with the wrong baud rate produces garbage characters, not silence; an SPI device with the wrong mode or a wrong chip-select simply won't respond. The wires can be perfect and communication still fail on a settings mismatch.

Safety Notes

Risk Level: Low. Bus signals are low-voltage, signal-level, and safe to probe. The usual digital cautions apply, plus a note on levels.

Professional Tips Before Starting

  • Count the wires and read the pin names. Two data wires labeled TX/RX with no clock is UART; four wires with a clock (SCLK, MOSI, MISO, CS) is SPI; two wires labeled SDA and SCL is I2C. The wiring identifies the protocol before you probe anything.
  • Reach for a logic analyzer with protocol decode. A scope shows activity; a logic analyzer that decodes I2C/SPI/UART shows the actual bytes and addresses, turning "there's some wiggling" into "device 0x68 is not acknowledging."
  • On I2C, check the pull-ups first. No pull-up resistors, or a line held LOW, hangs the entire two-wire bus — a very common fault that looks like every device on the bus has failed at once.

Understanding Buses and Communication Protocols

What a Bus Is

A bus is a shared set of wires that carries data between chips or devices — a common communication channel that several parts connect to. Rather than run a private wire between every pair of devices, a bus lets them share a small set of lines by taking turns and following an agreed set of rules (a protocol). Some buses conceptually carry separate address, data, and control lines; the serial buses in this section keep it to just a couple of shared wires. The key idea is sharing: one channel, agreed rules, and a way to say which device a message is for.

Parallel versus Serial

There are two fundamental ways to move the bits of a message. Parallel communication sends many bits at once, each on its own wire — eight bits need eight wires. It can be fast, but it costs many pins and traces, and keeping all those wires in step gets harder as speed rises. Serial communication sends the bits one at a time over a single line (plus perhaps a clock). It uses far fewer wires, and — exactly like the shift register from Section 6.2 shifting one bit out per clock — it trades width for simplicity. Serial now dominates inter-chip and external communication precisely because few wires, well-timed, beat many wires that must stay aligned. All three protocols below are serial.

UART (Universal Asynchronous Receiver/Transmitter) is the classic serial link, and its defining feature is right in the name: it is asynchronous — there is no shared clock. It uses just two data wires, TX (transmit) and RX (receive), cross-connected between the two devices. Because there's no clock to mark each bit, both sides must agree in advance on the baud rate — the number of bits per second — and each byte is wrapped in framing: a start bit to signal the beginning and one or more stop bits to mark the end, so the receiver can find and time each byte from the agreed rate. UART is simple and point-to-point (two devices), the basis of the traditional serial port. Its signature fault: if the two sides' baud rates don't match, the receiver samples at the wrong times and you get garbage characters rather than silence — a classic tell.

SPI (Serial Peripheral Interface) is synchronous — it includes a shared clock, so no baud-rate agreement is needed; the clock itself times every bit. It typically uses four wires: SCLK (the clock), MOSI (data from the controller out to the peripheral), MISO (data from the peripheral back in to the controller), and SS/CS (slave-select / chip-select). One device is the controller (it drives the clock), the others are peripherals. Because both data lines exist, SPI is full-duplex — it can send and receive at the same time — and it is fast. Device selection is by chip-select: each peripheral gets its own CS line, so adding devices means adding CS lines. SPI trades extra wires for speed and simplicity.

I2C — The Two-Wire Addressed Bus

I2C (Inter-Integrated Circuit) is also synchronous, but it does the opposite of SPI's wire-for-speed trade: it uses just two wires shared by many devices — SDA (serial data) and SCL (serial clock). Instead of a chip-select per device, each device has an address, and the controller names the target device by putting its address on the bus, so one two-wire bus can serve many chips. The two lines are open-drain: devices can only pull them LOW, and pull-up resistors return them HIGH, which is what lets multiple devices share the lines safely — but it means the pull-ups are mandatory. I2C is slower than SPI, but its two-wires-for-many-devices economy is why it's everywhere sensors and small peripherals cluster.

Telling Them Apart

The three map onto a simple set of trade-offs:

| Protocol | Wires | Clock | Device selection | Speed | Typical use | |---|---|---|---|---|---| | UART | 2 (TX, RX) | None (asynchronous, baud rate) | Point-to-point (two devices) | Low–moderate | Serial consoles, GPS, modems | | SPI | 4 (SCLK, MOSI, MISO, CS) | Shared (synchronous) | One chip-select line per device | High | Displays, SD cards, flash | | I2C | 2 (SDA, SCL) | Shared (synchronous) | Address on the shared bus | Low–moderate | Sensors, RTCs, small displays |

To identify a protocol on a board: two wires with no clock and TX/RX naming is UART; four wires with a clock is SPI; two wires named SDA and SCL is I2C. Wire count and pin names give it away before you probe.

Common Mistakes

  • Mixing up the three protocols. They differ in wire count, clocking, and device selection — identify by the wires and pin names, not by guessing.
  • Omitting I2C pull-ups. I2C's open-drain SDA/SCL require pull-up resistors; without them the bus can't go HIGH and nothing works.
  • Assuming a wiring fault when settings mismatch. UART garbage is usually a baud-rate mismatch; an unresponsive SPI device is often a wrong mode or chip-select — the wires may be fine.
  • Ignoring logic-level compatibility. Two devices on a bus must share a logic level (e.g. 3.3 V); mismatched levels cause failure or damage.

Troubleshooting Guidance

Bus faults reward first identifying the protocol, then checking the small set of things that protocol is prone to. Start by naming it from the wires and pin labels — two wires TX/RX (UART), four wires with a clock (SPI), or two wires SDA/SCL (I2C) — because the likely faults differ. Then confirm there is activity: with an oscilloscope look for the lines toggling, and, far better, with a logic analyzer that decodes the protocol you can read the actual bytes, addresses, and acknowledgements. For I2C, check the pull-up resistors first — missing pull-ups, or an SDA or SCL line stuck LOW (a jammed device holding the line, or a short), hangs the entire bus and makes every device look dead at once; a healthy idle I2C bus sits HIGH on both lines. For UART, garbage characters point straight at a baud-rate or framing mismatch rather than a wiring fault, while total silence suggests no activity or swapped TX/RX. For SPI, an unresponsive peripheral is often a wrong or inactive chip-select, a wrong SPI mode, or a MISO/MOSI swap; confirm the clock is present (the clock-and-check habit from Section 6.3) since without SCLK a synchronous bus does nothing. Across all three, watch for a held/stuck line, a ground difference between separately-powered devices (they must share a ground reference), and logic-level mismatch. Because a bus is shared, one jammed device can take down the whole bus — so when everything on a bus is silent, suspect the shared lines and their pull-ups before condemning every chip.

Verification & Testing Methods

Check your understanding before moving on:

  • [ ] Explain what a bus is and the difference between parallel and serial communication.
  • [ ] Describe UART: asynchronous, TX/RX, baud rate, and start/stop framing, and what a baud mismatch produces.
  • [ ] Describe SPI and I2C — their wires, shared clocks, and how each selects a device.
  • [ ] Identify which protocol a set of wires is, and name the first thing to check on a silent I2C bus.

Then try the practice exercises below — protocol reasoning and diagnosis, no powered work required.

Practice Exercises

  1. Name the protocol (5 minutes, reasoning). For each wiring, name the protocol: (a) two wires labeled SDA and SCL with pull-up resistors; (b) two wires labeled TX and RX with no clock; (c) four wires labeled SCLK, MOSI, MISO, and CS.
  2. Parallel vs serial (5 minutes, reasoning). In your own words, state the core trade-off between parallel and serial communication, and explain why serial has come to dominate inter-chip links despite sending only one bit at a time.
  3. Match the trade-off (10 minutes, reasoning). Which protocol best fits each need and why: (a) connect a dozen small sensors using as few wires as possible; (b) drive a display as fast as possible; (c) a simple point-to-point debug console with no clock line?
  4. Diagnose a dead bus (10 minutes, reasoning). Every device on an I2C bus is unresponsive at once. Explain, in order, what you would check first and why — including the role of the pull-up resistors and what a stuck-LOW SDA or SCL line does to the whole bus.

These core ideas — the bus, parallel versus serial, and the wires, clocking, and device-selection of UART, SPI, and I2C — are tested in the Chapter Quiz at the end of this chapter, where a score of 80% is required to continue.

Key Takeaways

  • A bus is a shared set of wires carrying data between devices under an agreed protocol; parallel sends many bits at once over many wires, while serial sends one bit at a time over few wires and now dominates (the shift-register idea from Section 6.2).
  • UART is asynchronous with no shared clock: two wires (TX, RX), an agreed baud rate, and start/stop framing per byte; point-to-point, and a baud-rate mismatch yields garbage characters.
  • SPI is synchronous (shared clock): four wires (SCLK, MOSI, MISO, CS), full-duplex and fast, with one chip-select line per peripheral — more devices means more CS lines.
  • I2C is synchronous with just two wires (SDA, SCL) shared by many devices selected by address; its open-drain lines require pull-up resistors, and it is slower than SPI but wire-thrifty.
  • Tell them apart by wire count and pin names: two async TX/RX (UART), four with a clock (SPI), two named SDA/SCL (I2C).
  • Diagnose by protocol: check I2C pull-ups and stuck-LOW lines first (a jammed line hangs the whole bus), read UART garbage as a baud/framing mismatch, and check SPI chip-select and clock — and confirm shared ground and matching logic levels across the bus.

Skills Learned

  • You can now explain what a bus is and contrast parallel with serial communication.
  • You can now describe UART: asynchronous, TX/RX, baud rate, and start/stop framing.
  • You can now describe SPI and I2C — their wires, clocking, and device selection — and compare all three.
  • You can now identify which protocol a set of wires is and diagnose common bus faults.
  • You can now name the first checks for a silent I2C bus and for UART garbage characters.

Glossary Additions

  • bus — a shared set of wires that carries data between chips or devices under an agreed protocol; rather than a private wire per pair of devices, a bus lets several parts share a small set of lines, with a way to indicate which device a message is for.
  • UART — Universal Asynchronous Receiver/Transmitter: an asynchronous serial link with no shared clock, using two wires (TX and RX), an agreed baud rate, and start/stop bits framing each byte; simple and point-to-point, and a baud-rate mismatch produces garbage characters.
  • SPI — Serial Peripheral Interface: a synchronous serial link with a shared clock, typically four wires (SCLK, MOSI, MISO, and chip-select CS), full-duplex and fast, in which each peripheral is selected by its own chip-select line.
  • I2C — Inter-Integrated Circuit: a synchronous two-wire serial bus (SDA data and SCL clock) shared by many devices that are selected by address; its open-drain lines require pull-up resistors, and it is slower than SPI but uses only two wires for a whole bus of devices.
  • baud rate — the number of bits per second at which an asynchronous link such as UART sends data; because UART has no shared clock, both ends must agree on the baud rate, and a mismatch causes the receiver to sample at the wrong times and produce garbage.

Suggested Next Sections

Must read next:

  • Common Digital Failure Modes — the closing section of the digital chapter: how digital circuits actually fail — stuck bits, bad clocks, dead buses, corrupted logic — and the systematic method for diagnosing them.

Recommended: