53  Wired Communication Protocols

Key Concepts

• Wired Communication: Transferring data over a physical conductor (copper cable, optical fibre) rather than radio waves; typically more reliable and higher bandwidth than wireless
• Differential Signalling: Transmitting data as the voltage difference between two wires rather than a single voltage; rejects common-mode noise and enables longer cable runs (RS-485, Ethernet)
• Single-Ended Signalling: Transmitting data as a voltage level on one wire relative to a common ground; simpler but more susceptible to noise (UART TTL, SPI, I²C)
• Baud Rate: The rate of symbol transmission; for binary signalling equals bit rate
• Bus Topology (Wired): Multiple devices sharing one communication medium (e.g., RS-485, CAN bus, I²C); requires arbitration or addressing to avoid collisions
• Point-to-Point Link: A dedicated wired connection between exactly two devices (USB, SPI, RS-232); no arbitration needed but scales poorly
• Fieldbus: An industrial wired network protocol (CAN, Modbus, PROFIBUS) connecting sensors and actuators to programmable logic controllers

53.1 In 60 Seconds

Before any IoT sensor reading reaches the cloud, it must first travel centimeters from the sensor chip to the microcontroller using one of three wired protocols: UART (2 wires, simple point-to-point at up to 115.2 kbps), I2C (2 wires with addressing for up to 112 devices at 400 kbps), or SPI (4+ wires for high-speed full-duplex at 10+ Mbps). Choosing the right protocol depends on your device count, speed requirements, and available pins.

53.2 Learning Objectives

By the end of this chapter, you will be able to:

• Identify the three main wired protocols (UART, I2C, SPI) and their physical characteristics
• Compare protocol trade-offs in wire count, speed, device support, and complexity
• Select the appropriate wired protocol for a given IoT sensor or peripheral scenario
• Explain synchronous vs asynchronous communication and how clock signals coordinate data transfer
• Apply protocol selection criteria to real-world IoT hardware design decisions

---

Minimum Viable Understanding (MVU)

If you only have 10 minutes, focus on these three essentials:

• UART uses 2 wires (TX/RX) for simple point-to-point links at up to 115.2 kbps (standard RS-232 maximum; many MCU UARTs support higher) – ideal for GPS modules, Bluetooth adapters, and serial debugging where only two devices communicate
• I2C uses 2 wires (SDA/SCL) with addressing to connect up to 112 devices at 400 kbps on a shared bus – the go-to protocol for temperature sensors, displays, and multi-sensor IoT projects
• SPI uses 4+ wires (MOSI/MISO/SCK/CS) for high-speed full-duplex transfers at 10+ Mbps – required when data rate matters, such as SD card logging or high-resolution TFT displays

53.3 Introduction

Wired communication protocols form the foundation of IoT device interconnection at the local level. Before any sensor reading reaches the cloud via Wi-Fi or LoRaWAN, it must first travel a few centimeters from the sensor chip to the microcontroller – and that short journey uses one of three wired protocols: UART, I2C, or SPI. Understanding these protocols is essential for anyone building IoT hardware.

This chapter provides an overview and comparison of these three protocols, then directs you to focused sub-chapters for deep dives into each one.

Sensor Squad: The Three Wired Highways

Sammy the Sensor looks at the wires on the circuit board and asks: “How do I send my temperature reading to the brain chip?”

Lila the LED explains: “Think of it like roads! There are three types of roads on our circuit board:”

• UART Road is like a two-lane country road – one lane going each way. Only two friends can talk, but it is simple and works great for chatting!
• I2C Road is like a school bus route – one bus (2 wires) picks up many students (sensors). Each student has a seat number (address), so the driver knows who to talk to.
• SPI Road is like a superhighway with dedicated lanes – super fast, but takes up more space (4+ wires). Perfect when you need to move a LOT of data quickly!

Max the Microcontroller adds: “I am the brain chip! I decide which road to use. If I only need one friend, I use UART. If I need lots of sensor friends, I use I2C. If I need speed, I go SPI!”

Bella the Battery warns: “Remember, more wires means more pins used up on Max. I2C is great because it uses only 2 wires for tons of sensors, saving pins and keeping things tidy!”

For Beginners: What Are Wired Protocols?

If you are new to electronics or IoT, here is the simplest explanation:

Wired protocols are the rules for how chips talk to each other over tiny copper wires on a circuit board. Think of them as different languages – each with its own grammar (timing rules), vocabulary (signal meanings), and number of speakers it supports.

Why does this matter? When you buy a temperature sensor for your Arduino or ESP32 project, the sensor’s datasheet will say “I2C interface” or “SPI interface.” You need to know:

1. Which wires to connect (each protocol uses different pins)
2. What code library to use (each protocol has different Arduino/MicroPython functions)
3. Whether it will work with your other sensors (some protocols share wires, others do not)

The good news: There are only three protocols to learn, and most IoT projects use I2C for sensors and SPI for storage or displays. If that is all you remember, you are already ahead!

53.4 Overview

Figure 53.1: The three main wired protocols for IoT: UART for point-to-point, I2C for multi-device, SPI for high-speed

The microcontroller sits at the center of all three buses, managing protocol-specific signaling on dedicated pins:

Figure 53.2: Signal lines from a microcontroller showing UART TX/RX, I2C SDA/SCL with shared bus, and SPI MOSI/MISO/SCK with individual chip-select lines

53.5 Wired Protocol Architecture

Understanding how each protocol physically connects devices is critical for PCB design and breadboard prototyping.

Figure 53.3: Physical wiring architecture of UART (crossed TX-RX), I2C (shared SDA/SCL with pull-up resistors), and SPI (shared bus with dedicated CS lines)

53.6 Chapter Contents

This topic is covered in four focused chapters:

53.6.1 1. Wired Communication Fundamentals

Foundational concepts for understanding all wired protocols:

• Binary transmission challenge and signal encoding
• Synchronous vs asynchronous communication
• Network topologies: point-to-point, multi-drop, multi-point
• Master-slave architecture and collision prevention
• Full-duplex vs half-duplex communication

53.6.2 2. UART and RS-232

Serial point-to-point communication for legacy and simple devices:

• RS-232 voltage levels and connector pinouts
• UART frame structure: start bit, data bits, parity, stop bit
• Baud rate configuration and common settings
• Arduino/ESP32 code examples
• Troubleshooting baud rate and voltage level issues

53.6.3 3. I2C Protocol

Two-wire bus for connecting multiple sensors and displays:

• SDA and SCL signal lines with pull-up resistors
• 7-bit addressing and device discovery (I2C scanner)
• Read and write transactions with ACK/NACK
• Clock stretching for slow devices
• Common devices: BME280, SSD1306, MPU6050

53.6.4 4. SPI Protocol

High-speed full-duplex interface for fast peripherals:

• MOSI, MISO, SCK, and chip select signals
• SPI modes (CPOL/CPHA) and clock configuration
• Multi-slave configurations with dedicated CS lines
• Protocol comparison and selection guide
• SD card and display interfacing

53.7 Quick Protocol Comparison

Protocol	Wires	Speed	Devices	Duplex	Clock	Best For
UART	2	115.2 kbps (RS-232 max)	2	Full	None (async)	GPS, Bluetooth, debugging
I2C	2	400 kbps	112	Half	SCL (sync)	Sensors, displays, EEPROMs
SPI	4+	10+ Mbps	Many	Full	SCK (sync)	SD cards, fast sensors, displays

53.8 Protocol Selection Decision Flow

Choosing the right wired protocol is one of the first hardware decisions in an IoT project. Use this decision tree:

Figure 53.4: Decision tree for wired protocol selection: device count, speed, and pin constraints lead to UART, I2C, or SPI

53.9 Communication Timing Comparison

Understanding how data moves on the wire is essential for debugging. This diagram shows the fundamental timing difference between asynchronous (UART) and synchronous (I2C, SPI) protocols:

Figure 53.5: Timing comparison: UART uses start/stop bits (no clock), I2C uses SCL with ACK handshake, SPI uses CS activation with simultaneous MOSI/MISO transfer

53.10 Common Pitfalls

Common Wired Protocol Mistakes

1. Missing I2C pull-up resistors. I2C requires 4.7 kOhm pull-up resistors on SDA and SCL lines. Without them, the bus will not work at all – you will read all zeros or all ones. Many breakout boards include pull-ups, but if you connect multiple boards, you may end up with too many pull-ups in parallel (effectively lowering resistance), which also causes failures.

2. UART baud rate mismatch. If the transmitter sends at 9600 baud but the receiver expects 115200, you will see garbage characters (or nothing). Always verify both sides use the same baud rate, data bits (usually 8), parity (usually none), and stop bits (usually 1) – often written as “8N1”.

3. SPI mode mismatch (CPOL/CPHA). SPI has four modes (0-3) that define when data is sampled relative to the clock edge. If master and slave use different modes, data will be shifted or corrupted. Always check the peripheral datasheet for the required SPI mode.

4. Forgetting voltage level translation. A 3.3V ESP32 connected directly to a 5V UART device can damage the ESP32. Always use a logic level converter (bidirectional MOSFET-based) when mixing 3.3V and 5V devices.

5. I2C address conflicts. Two devices with the same 7-bit address on the same bus will cause collisions. Run an I2C scanner sketch first to detect all devices and check for conflicts. Some devices allow address configuration via address pins (A0, A1, A2).

53.11 Worked Example: Designing a Weather Station Bus

Scenario: You are building an IoT weather station with the following components connected to an ESP32:

Component	Interface Options	Data Rate Needed	Notes
BME280 (temp/humidity/pressure)	I2C or SPI	Low (1 reading/sec)	Default I2C address: 0x76
SSD1306 OLED (128x64 display)	I2C or SPI	Medium (10 fps)	Default I2C address: 0x3C
NEO-6M GPS Module	UART only	Low (1 fix/sec)	9600 baud default
MicroSD Card	SPI only	High (logging at 1 kB/sec)	Requires SPI
BH1750 Light Sensor	I2C only	Low (1 reading/sec)	Default address: 0x23

Step 1: Identify fixed-interface components.

• GPS module = UART (no choice). Uses pins GPIO16 (RX2), GPIO17 (TX2) on ESP32.
• MicroSD card = SPI (no choice). Uses the default SPI bus: GPIO23 (MOSI), GPIO19 (MISO), GPIO18 (SCK), GPIO5 (CS).

Step 2: Decide on shared-bus components.

• BME280, SSD1306, and BH1750 all support I2C. Their addresses (0x76, 0x3C, 0x23) are all different, so no conflicts.
• Putting these three on I2C saves pins: only GPIO21 (SDA) and GPIO22 (SCL) needed for all three.

Step 3: Verify no conflicts exist.

Bus	Devices	Wires Used	Pins
UART2	GPS (NEO-6M)	2	GPIO16, GPIO17
I2C	BME280 (0x76), OLED (0x3C), Light (0x23)	2	GPIO21, GPIO22
SPI	MicroSD	4	GPIO23, GPIO19, GPIO18, GPIO5
Total	5 devices	8 wires	8 pins

Putting Numbers to It

GPIO Pin Utilization: Protocol Selection Impact

Let us quantify how protocol choice affects precious GPIO pin count on an ESP32:

Scenario 1: All I2C-capable devices on SPI (hypothetical worst case for I2C-capable devices): - Each SPI device needs: MOSI, MISO, SCK (shared) + CS (dedicated) - For the 3 I2C-capable devices (BME280, OLED, BH1750) on SPI: 3 shared + 3 CS = 6 GPIO pins (vs. 2 pins total on I2C – a difference of 4 GPIO pins for just these three devices) - BUT: sensors and displays do not need SPI speed, wasting high-speed bus capability

Scenario 2: All devices on individual UART (impossible): - Each UART device needs: TX, RX (2 pins) - For 5 devices: \(5 \times 2 = 10\) GPIO pins - ESP32 has only 3 hardware UART ports → cannot support 5 devices

Scenario 3: Mixed protocols (optimal) – our solution: - UART: 2 pins (GPS mandatory) - I2C: 2 pins (3 devices share bus via addressing) - SPI: 4 pins (SD card mandatory) - Total: 8 pins for 5 devices

Pin savings by using I2C instead of SPI for the three shared-bus devices: \[\text{Pins saved} = 6 \text{ (SPI for 3 devices)} - 2 \text{ (I2C for 3 devices)} = 4 \text{ GPIO pins}\]

Alternative: I2C vs SPI for display:

• I2C OLED: Uses shared SDA/SCL (0 additional pins beyond the 2 already used by other I2C sensors)
• SPI OLED: Would need dedicated CS pin → +1 GPIO (plus MOSI/MISO/SCK if not already used by SD card)

For an ESP32 with GPIO0–GPIO39 (roughly 25 usable general-purpose pins after power, flash, and boot-strapping reservations), saving 4 pins for I2C devices = ~16% more GPIO available for future expansion. This matters when adding buttons, status LEDs, or additional sensors later.

Step 4: Hardware checklist.

• Add 4.7 kOhm pull-up resistors on SDA and SCL (check if breakout boards already have them)
• Use 3.3V power for all components (ESP32 is 3.3V logic)
• Configure UART2 at 9600 baud 8N1 to match GPS default
• Use SPI Mode 0 for SD card (standard for most SD libraries)

Result: Five peripherals connected using only 8 GPIO pins by mixing all three protocols strategically.

Figure 53.6: Weather station wiring: ESP32 using UART2 for GPS, I2C for BME280/OLED/BH1750, and SPI for MicroSD – all five peripherals on 8 GPIO pins

53.12 Knowledge Check

Test your understanding of wired communication protocols:

53.13 Learning Path

Recommended order:

1. Start with Fundamentals to understand core concepts
2. Learn UART/RS-232 for simple serial communication
3. Master I2C for multi-sensor projects
4. Add SPI for high-speed data logging

Quick Selection Guide

• GPS module or Bluetooth? → UART
• Temperature sensor or OLED display? → I2C
• SD card or TFT display? → SPI
• Multiple sensors on limited pins? → I2C
• Need maximum speed? → SPI

Common Mistake: Pull-Up Resistor Miscalculation on I2C Buses

The Problem: Many developers know I2C requires pull-up resistors but fail to calculate the correct value when combining multiple breakout boards.

Real Scenario: A smart greenhouse controller connects five I2C devices: - BME280 sensor board (has onboard 10kΩ pull-ups) - SSD1306 OLED display (has onboard 4.7kΩ pull-ups) - DS3231 RTC module (has onboard 4.7kΩ pull-ups) - ADS1115 ADC board (no onboard pull-ups) - Custom PCB with MPU6050 (added 4.7kΩ pull-ups)

Developer’s thought: “Each board has pull-ups, so I’m good!”

Reality check:

Parallel conductance formula: G_total = G1 + G2 + G3 + G4
G_total = 1/10kΩ + 1/4.7kΩ + 1/4.7kΩ + 1/4.7kΩ
G_total = 0.100 + 0.213 + 0.213 + 0.213 = 0.739 mS  (milliSiemens)
R_total = 1/G_total = 1/0.000739 S = 1.35 kΩ

Problem identified: A 4.7kΩ pull-up is a widely used starting value for standard-mode I2C (100 kHz); the I2C specification actually defines a minimum pull-up resistance based on bus capacitance. The parallel combination of four sets creates 1.35kΩ — nearly 3.5× too low (i.e., too strong a pull-up).

Consequences:

• Excessive current draw: (5V - 0.4V) / 1.35kΩ = 3.4 mA per line (SDA + SCL = 6.8 mA total)
• Rise time too fast for long traces (capacitance limits violated)
• Marginal signal levels at far end of bus
• Intermittent communication errors at higher speeds

Correct Solution:

1. Remove all but one set of pull-ups: Desolder resistors from 3 boards, keep only one 4.7kΩ set

2. OR use external calculated values: Remove all onboard pull-ups, add single 4.7kΩ to the main controller board

3. For long buses or high capacitance: Calculate required minimum pull-up resistance using the NXP I2C specification formula:

   R_min (Ω) = t_r (ns) / (0.8473 × C_bus (pF)) × 1000
   
   Where:
   t_r  = maximum rise time allowed (1000 ns for standard-mode 100 kHz I2C)
   C_bus = total bus capacitance in pF (traces + input capacitances of all devices)
   
   Example: C_bus = 200 pF
   R_min = 1000 ns / (0.8473 × 200 pF) × 1000
         = 1000 / 169.46 × 1000 = 5903 Ω ≈ 5.9 kΩ → choose 6.8 kΩ (nearest standard value)

Quick Check Rule: Measure actual pull-up resistance with multimeter (power off, one end lifted). If below 3kΩ for a standard-speed bus, you have too many parallel pull-ups.

Why This Matters: Pull-up calculation errors are the #1 cause of “I2C works on my desk but fails in the field” bugs. Temperature changes affect resistance, making marginal designs unreliable.

Try It: I2C Pull-Up Resistance Calculator

Enter the pull-up resistor values on your I2C boards to see the effective parallel resistance and whether it is within spec.

viewof r1 = Inputs.range([1, 100], {
  label: "Board 1 pull-up (kΩ)",
  step: 0.1,
  value: 10
})
viewof r2 = Inputs.range([0, 100], {
  label: "Board 2 pull-up (kΩ, 0 = none)",
  step: 0.1,
  value: 4.7
})
viewof r3 = Inputs.range([0, 100], {
  label: "Board 3 pull-up (kΩ, 0 = none)",
  step: 0.1,
  value: 4.7
})
viewof r4 = Inputs.range([0, 100], {
  label: "Board 4 pull-up (kΩ, 0 = none)",
  step: 0.1,
  value: 4.7
})
viewof vcc = Inputs.select([3.3, 5.0], {
  label: "Supply voltage (V)",
  value: 5.0
})
viewof cbus = Inputs.range([10, 400], {
  label: "Bus capacitance (pF)",
  step: 10,
  value: 100
})

{
  // Collect non-zero resistances (in Ω)
  const resistors = [r1, r2, r3, r4]
    .filter(v => v > 0)
    .map(v => v * 1000);

  const G_total = resistors.reduce((acc, r) => acc + 1 / r, 0);
  const R_total = G_total > 0 ? 1 / G_total : Infinity;
  const R_kOhm = R_total / 1000;

  // I2C spec minimum pull-up (NXP UM10204): R_min = t_r / (0.8473 * C_bus)
  // t_r = 1000 ns (standard mode), C_bus in pF → result in kΩ
  const t_r = 1000; // ns for standard 100 kHz mode
  const R_min_kOhm = t_r / (0.8473 * cbus); // kΩ
  const R_max_ohm = (vcc - 0.4) / (3e-3); // max to keep I_OL ≤ 3 mA: R = (Vcc-Vol)/3mA, in Ω
  const R_max_display = R_max_ohm / 1000; // kΩ

  // Current per line when pulled LOW
  const I_low_mA = (vcc - 0.4) / R_total * 1000;

  // green = in spec, red = too low, orange = too high
  const statusColor = R_kOhm >= R_min_kOhm && R_kOhm <= R_max_display
    ? "#16A085"
    : R_kOhm < R_min_kOhm
    ? "#E74C3C"
    : "#E67E22";

  const statusText = R_kOhm >= R_min_kOhm && R_kOhm <= R_max_display
    ? "PASS - Pull-up value is within I2C spec"
    : R_kOhm < R_min_kOhm
    ? "FAIL - Too low (too many parallel pull-ups). Remove some."
    : "WARNING - Too high (may cause slow rise times at high capacitance).";

  return htl.html`<div style="font-family: Arial, sans-serif; padding: 16px; border-radius: 6px; background: #f8f9fa; border-left: 4px solid ${statusColor};">
    <table style="width:100%; border-collapse: collapse;">
      <tr>
        <td style="padding:4px 8px; color:#2C3E50;"><strong>Effective pull-up resistance</strong></td>
        <td style="padding:4px 8px; font-size:1.2em; font-weight:bold; color:${statusColor};">${R_kOhm.toFixed(2)} kΩ</td>
      </tr>
      <tr>
        <td style="padding:4px 8px; color:#7F8C8D;">I2C spec minimum (for ${cbus} pF bus)</td>
        <td style="padding:4px 8px; color:#7F8C8D;">${R_min_kOhm.toFixed(2)} kΩ</td>
      </tr>
      <tr>
        <td style="padding:4px 8px; color:#7F8C8D;">Max for 3 mA sink current @ ${vcc}V</td>
        <td style="padding:4px 8px; color:#7F8C8D;">${R_max_display.toFixed(1)} kΩ</td>
      </tr>
      <tr>
        <td style="padding:4px 8px; color:#2C3E50;"><strong>Current per line (pulled LOW)</strong></td>
        <td style="padding:4px 8px; color:#2C3E50;">${I_low_mA.toFixed(2)} mA</td>
      </tr>
    </table>
    <div style="margin-top:12px; padding:8px 12px; background:${statusColor}20; border-radius:4px; color:${statusColor}; font-weight:bold;">
      ${statusText}
    </div>
  </div>`;
}

Try It: Protocol Pin Budget Calculator

Select which devices you need and see the GPIO pin cost of each protocol choice.

viewof n_i2c = Inputs.range([0, 8], {
  label: "I2C-capable devices (sensors, displays)",
  step: 1,
  value: 3
})
viewof n_uart = Inputs.range([0, 3], {
  label: "UART devices (GPS, Bluetooth, RS-232)",
  step: 1,
  value: 1
})
viewof n_spi_only = Inputs.range([0, 4], {
  label: "SPI-only devices (SD card, flash)",
  step: 1,
  value: 1
})

{
  // Mixed protocol (optimal)
  const uart_pins = n_uart * 2;
  const i2c_pins = n_i2c > 0 ? 2 : 0;  // all share SDA/SCL
  const spi_shared = n_spi_only > 0 ? 3 : 0; // MOSI/MISO/SCK shared
  const spi_cs = n_spi_only;             // one CS per SPI device
  const spi_pins = spi_shared + spi_cs;
  const mixed_total = uart_pins + i2c_pins + spi_pins;

  // All SPI (treating I2C devices as SPI alternatives)
  const all_spi_total = (n_i2c + n_spi_only) > 0
    ? 3 + n_i2c + n_spi_only
    : 0;
  const all_spi_with_uart = uart_pins + all_spi_total;

  const savings = all_spi_with_uart - mixed_total;

  const colors = {
    uart: "#3498DB",
    i2c: "#16A085",
    spi: "#E67E22",
    total: "#2C3E50"
  };

  return htl.html`<div style="font-family:Arial,sans-serif; padding:16px; border-radius:6px; background:#f8f9fa;">
    <h4 style="color:#2C3E50; margin-top:0;">GPIO Pin Budget</h4>
    <table style="width:100%; border-collapse:collapse; margin-bottom:12px;">
      <thead>
        <tr style="background:#2C3E50; color:white;">
          <th style="padding:8px; text-align:left;">Protocol</th>
          <th style="padding:8px; text-align:center;">Devices</th>
          <th style="padding:8px; text-align:center;">Pins (Mixed)</th>
          <th style="padding:8px; text-align:center;">Pins (All SPI)</th>
        </tr>
      </thead>
      <tbody>
        <tr style="background:#3498DB15;">
          <td style="padding:8px; color:${colors.uart};"><strong>UART</strong></td>
          <td style="padding:8px; text-align:center;">${n_uart}</td>
          <td style="padding:8px; text-align:center;">${uart_pins}</td>
          <td style="padding:8px; text-align:center;">${uart_pins}</td>
        </tr>
        <tr style="background:#16A08515;">
          <td style="padding:8px; color:${colors.i2c};"><strong>I2C devices</strong></td>
          <td style="padding:8px; text-align:center;">${n_i2c}</td>
          <td style="padding:8px; text-align:center;">${i2c_pins} (shared bus)</td>
          <td style="padding:8px; text-align:center;">${n_i2c > 0 ? `+${n_i2c} CS lines (share SPI bus)` : "0"}</td>
        </tr>
        <tr style="background:#E67E2215;">
          <td style="padding:8px; color:${colors.spi};"><strong>SPI-only devices</strong></td>
          <td style="padding:8px; text-align:center;">${n_spi_only}</td>
          <td style="padding:8px; text-align:center;">${spi_pins} (${spi_cs} CS)</td>
          <td style="padding:8px; text-align:center;">shared above</td>
        </tr>
        <tr style="background:#2C3E5020; font-weight:bold;">
          <td style="padding:8px; color:${colors.total};"><strong>TOTAL GPIO pins</strong></td>
          <td style="padding:8px; text-align:center;"></td>
          <td style="padding:8px; text-align:center; font-size:1.1em; color:#16A085;">${mixed_total}</td>
          <td style="padding:8px; text-align:center; font-size:1.1em; color:#E74C3C;">${all_spi_with_uart}</td>
        </tr>
      </tbody>
    </table>
    <div style="padding:10px 14px; border-radius:4px; background:${savings > 0 ? '#16A08520' : '#7F8C8D20'}; color:${savings > 0 ? '#16A085' : '#7F8C8D'}; font-weight:bold;">
      ${savings > 0
        ? `Using I2C saves ${savings} GPIO pin${savings > 1 ? 's' : ''} compared to using SPI for all devices.`
        : savings === 0
        ? `Mixed and all-SPI use the same number of pins for this configuration.`
        : `All-SPI uses fewer pins in this edge case (unusual).`}
    </div>
  </div>`;
}

🏷️ Label the Diagram

Code Challenge

53.14 Summary and Key Takeaways

Wired communication protocols are the essential building blocks for connecting sensors, displays, and peripherals to IoT microcontrollers. Here are the key points to remember:

Concept	Key Takeaway
Three protocols	UART (async, 2-wire, point-to-point), I2C (sync, 2-wire, multi-device bus), SPI (sync, 4+ wire, high-speed full-duplex)
UART	Simplest protocol, no clock needed, both sides must agree on baud rate. Best for GPS, Bluetooth, debug consoles. Limited to 2 devices.
I2C	Shared bus with addressing. 7-bit addresses support up to 112 devices on just 2 wires. Requires pull-up resistors. 400 kbps standard mode.
SPI	Fastest option (10+ Mbps). Full-duplex with dedicated CS lines per slave. Uses more pins but delivers the highest throughput.
Protocol mixing	Real IoT projects often use all three: UART for GPS/serial, I2C for sensors, SPI for storage and displays. Plan pin allocation early.
Voltage levels	Always match logic levels (3.3V vs 5V). Use level converters when mixing, or risk permanent hardware damage.
Debugging	Most wired protocol issues come from: baud rate mismatch (UART), missing pull-ups (I2C), wrong SPI mode, or forgotten CS wiring (SPI).

53.15 What’s Next

Topic	Chapter	Description
Synchronous vs Asynchronous Communication	Wired Communication Fundamentals	Deep dive into bus topologies, master-slave architecture, and full-duplex vs half-duplex signalling
Serial Point-to-Point Links	UART and RS-232	UART frame structure, baud rate configuration, and Arduino/ESP32 code examples
Two-Wire Multi-Device Bus	I2C Protocol	7-bit addressing, clock stretching, ACK/NACK handshakes, and common sensor integration
High-Speed Full-Duplex Interface	SPI Protocol	SPI modes (CPOL/CPHA), multi-slave CS wiring, and SD card interfacing
Choosing the Right Sensor	Sensor Fundamentals and Types	How to match sensor interface types (UART, I2C, SPI) to your project requirements
Hardware Prototyping	Prototyping Hardware	Hands-on wiring guidance for connecting sensors and peripherals to Arduino, ESP32, and Raspberry Pi