54 Wired Communication Fundamentals

In 60 Seconds

Wired communication protocols (I2C, SPI, UART) are the “languages” that microcontrollers use to talk to sensors and peripherals through physical wires. Key concepts include synchronous vs asynchronous clocking, point-to-point vs multi-drop topologies, master-slave bus arbitration, and full-duplex vs half-duplex transmission modes. Understanding these fundamentals is essential before working with specific protocols like I2C (2-wire), SPI (4-wire), or UART (2-wire async).

54.1 Learning Objectives

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

Explain the Binary Transmission Challenge: Describe how digital data is converted to electrical signals
Compare Synchronous vs Asynchronous: Differentiate clock-shared and independent-clock communication
Identify Network Topologies: Distinguish point-to-point, multi-drop, and multi-point configurations
Explain Master-Slave Architecture: Describe how bus access is controlled to prevent collisions
Choose Duplex Mode: Select full-duplex or half-duplex based on application requirements

54.2 Prerequisites

Before diving into this chapter, you should be familiar with:

Networking Basics: Understanding fundamental networking concepts including data transmission, protocols, and communication models
Binary and Digital Logic: Understanding binary numbers, voltage levels (HIGH/LOW), and basic digital electronics

54.3 Getting Started (For Beginners)

What Are Wired Communication Protocols? (Simple Explanation)

Analogy: Wired protocols are like different languages for talking through wires.

Just like humans have different languages (English, Spanish, Mandarin), electronic devices have different “languages” for communicating through wires (I2C, SPI, UART).

Diagram showing microcontroller connected to peripherals via UART, I2C, and SPI wired protocols — Figure 54.1: Microcontroller Peripheral Connections Using UART, I2C, and SPI

Why Wired Protocols?: Microcontrollers and sensors need a shared “language” (protocol) to communicate through wires.

The Three Main Protocols: Quick Comparison

Protocol	Wires Needed	Speed	Devices	Best For
UART	2 (TX, RX)	Slow-Medium	2 only	GPS, Bluetooth modules
I2C	2 (SDA, SCL)	Medium	Many (112)	Sensors, displays
SPI	4+ (MOSI, MISO, SCK, CS)	Fast	Many	SD cards, fast sensors

Putting Numbers to It

Wired Protocol Speed and Timing Comparison

Let’s quantify the speed differences and data transfer times for a common task: reading a 1024-byte data block.

Clock speeds (typical maximum rates): - UART: 115,200 baud → 115.2 kbps (standard), up to 921.6 kbps (fast) - I2C: 100 kHz (standard), 400 kHz (fast), 3.4 MHz (high-speed) → 100-3,400 kbps - SPI: 1-50 MHz → 1-50 Mbps (limited by wire length, not protocol)

Transfer time for 1024 bytes (8,192 bits) at standard speeds:

UART (115.2 kbps with 10 bits per byte for start/stop): \[T_{\text{UART}} = \frac{1024 \times 10}{115{,}200} = 88.9 \text{ ms}\]

I2C (400 kHz fast mode, including ACK bits): \[T_{\text{I2C}} = \frac{1024 \times 9}{400{,}000} = 23 \text{ ms} \quad \text{(3.9× faster)}\]

SPI (10 MHz): \[T_{\text{SPI}} = \frac{8{,}192}{10{,}000{,}000} = 0.82 \text{ ms} \quad \text{(108× faster than UART!)}\]

Battery impact: For a sensor reading 1024 bytes once per minute: - UART: Active 89 ms × 60 = 5.3 sec/hour → 5.3 × 24 = 127 sec/day → 0.71 mAh daily at 20 mA - SPI: Active 0.82 ms × 60 = 49 ms/hour → 49 × 24 = 1,176 ms/day → 0.0065 mAh daily at 20 mA (109× less energy)

This explains why high-throughput peripherals (SD cards, displays) use SPI, while simple sensors use I2C’s simpler 2-wire interface despite being slower.

Try It: Protocol Transfer Time Calculator

Show code

{
  const bits = dataBytes * 8;
  // UART: 10 bits per byte (start + 8 data + stop), 115200 baud
  const uartBaud = 115200;
  const uartBits = dataBytes * 10;
  const tUart_ms = (uartBits / uartBaud) * 1000;
  // I2C: 9 bits per byte (8 data + 1 ACK), 400 kHz fast mode
  const i2cHz = 400000;
  const i2cBits = dataBytes * 9;
  const tI2c_ms = (i2cBits / i2cHz) * 1000;
  // SPI: 8 bits per byte, 10 MHz
  const spiHz = 10000000;
  const tSpi_ms = (bits / spiHz) * 1000;

  // Battery: mAh/day = active_s_per_day * mA / 3600
  const uartActiveSecDay = (tUart_ms / 1000) * readFreqPerMin * 60 * 24;
  const spiActiveSecDay  = (tSpi_ms  / 1000) * readFreqPerMin * 60 * 24;
  const uartMah = (uartActiveSecDay * currentMA) / 3600;
  const spiMah  = (spiActiveSecDay  * currentMA) / 3600;
  const ratio   = tUart_ms / tSpi_ms;

  const fmt = (n, dp=2) => n < 0.001 ? n.toExponential(dp) : n.toFixed(dp);

  return htl.html`
    <div style="font-family: Arial, sans-serif; padding: 1rem; background: #f8f9fa; border-radius: 6px; border-left: 4px solid #16A085;">
      <h4 style="margin-top:0; color: #2C3E50;">Transfer Time for ${dataBytes.toLocaleString()} bytes</h4>
      <table style="width:100%; border-collapse:collapse; font-size:0.9em;">
        <thead>
          <tr style="background:#2C3E50; color:white;">
            <th style="padding:8px; text-align:left;">Protocol</th>
            <th style="padding:8px; text-align:right;">Transfer Time</th>
            <th style="padding:8px; text-align:right;">vs UART</th>
            <th style="padding:8px; text-align:right;">Daily Energy (${currentMA} mA)</th>
          </tr>
        </thead>
        <tbody>
          <tr style="background:white;">
            <td style="padding:8px; font-weight:bold; color:#E67E22;">UART (115.2 kbps)</td>
            <td style="padding:8px; text-align:right;">${fmt(tUart_ms)} ms</td>
            <td style="padding:8px; text-align:right; color:#7F8C8D;">baseline</td>
            <td style="padding:8px; text-align:right;">${fmt(uartMah, 4)} mAh</td>
          </tr>
          <tr style="background:#f0faf8;">
            <td style="padding:8px; font-weight:bold; color:#16A085;">I2C (400 kHz fast)</td>
            <td style="padding:8px; text-align:right;">${fmt(tI2c_ms)} ms</td>
            <td style="padding:8px; text-align:right; color:#16A085;">${(tUart_ms/tI2c_ms).toFixed(1)}× faster</td>
            <td style="padding:8px; text-align:right;">${fmt((tI2c_ms/1000)*readFreqPerMin*60*24*currentMA/3600, 4)} mAh</td>
          </tr>
          <tr style="background:white;">
            <td style="padding:8px; font-weight:bold; color:#3498DB;">SPI (10 MHz)</td>
            <td style="padding:8px; text-align:right;">${fmt(tSpi_ms)} ms</td>
            <td style="padding:8px; text-align:right; color:#3498DB;">${fmt(ratio, 0)}× faster</td>
            <td style="padding:8px; text-align:right;">${fmt(spiMah, 4)} mAh</td>
          </tr>
        </tbody>
      </table>
      <p style="font-size:0.85em; color:#7F8C8D; margin-bottom:0;">
        Energy = (transfer time per reading × readings/day × active current) / 3600.
        SPI uses <strong>${fmt(uartMah/spiMah, 0)}× less energy</strong> than UART for this workload.
      </p>
    </div>
  `;
}

Sensor Squad: Talking Through Wires!

“Before we go wireless, let’s talk about how I physically connect to Max using wires!” said Sammy the Sensor. “There are three main languages: UART, I2C, and SPI.”

Max the Microcontroller explained each one. “UART is the simplest – just two wires, one for sending and one for receiving. It is like a walkie-talkie where each person has their own channel. Perfect for connecting to a GPS module or Bluetooth chip. But it only works between two devices.”

“I2C is cleverer,” said Lila the LED. “Just two wires – a data wire and a clock wire – but up to 112 devices can share them! Each device has a unique address, and Max calls out addresses to talk to specific ones. It is like a classroom where the teacher calls on students by name.”

“And SPI is the speed demon,” added Bella the Battery. “Four wires, but it can transfer data really fast. Each device gets its own ‘chip select’ wire so Max can choose exactly who to talk to. The trade-off is needing more wires for more devices. Choose UART for simple two-device links, I2C for lots of sensors on few wires, and SPI when speed matters most!”

Comparison of UART point-to-point, I2C multi-drop bus, and SPI multi-point topologies — Figure 54.2: UART, I2C, and SPI Topology Comparison

Alternative View: Wired Protocol Speed vs Complexity Trade-off

This variant visualizes the fundamental trade-off between protocol speed and implementation complexity - useful for choosing the right protocol for your project.

Figure 54.3: Wired Protocol Speed vs Complexity - Each step right adds wires but increases speed

Key Insight: I2C is the “sweet spot” for most IoT sensor applications - minimal wires (2) with multi-device support. Only move to SPI when I2C’s ~400 kbps isn’t fast enough.

When to Use Which Protocol?

Scenario	Best Choice	Why
Connect a GPS module	UART	GPS modules typically use serial
Connect 5 sensors	I2C	One bus for many devices
Read an SD card	SPI	Needs high speed
Connect a display	I2C or SPI	Depends on display type

Rule of thumb:

I2C = Default choice for most sensors (simple, few wires)
SPI = When you need speed (SD cards, high-res displays)
UART = Legacy devices, GPS, Bluetooth modules

Why Wired Communication Matters for IoT

At the local level, IoT devices communicate using wires. Sensors connect to microcontrollers via I2C, SPI, or UART. Industrial equipment uses RS-232. Understanding these protocols is essential for interfacing sensors, displays, and peripherals in IoT systems.

54.4 The Challenge: Transmitting Binary Data

54.4.1 Fundamental Problem

All IoT ecosystems communicate using binary protocols - endless trails of 0s and 1s.

Serial data transmission flow converting analog sensor reading to binary digital value — Figure 54.4: Serial Data Transmission from Sensor Reading to Digital Value

The problem to solve:

How can we send 0s and 1s from one place to another?

Engineers have developed many solutions, each optimized for different scenarios.

54.4.2 Design Considerations

Choice of protocol depends on:

Factor	Questions	Impact
Distance	Same PCB? Same room? Same building?	Wire length limits speed
Speed	How fast must data move?	Faster = more complex circuitry
Safety	Security requirements? Interference?	Shielding, encryption costs
Cost	Budget constraints?	More wires = higher cost
Power	Battery or mains powered?	Low power = slower speeds

54.5 Overview of Wired Communication Standards

54.5.1 Comparison Table

Protocol	Wires	Sync/Async	Speed	Distance	Devices	Topology	IoT Use Case
RS-232	3-9	Async	20 kbps (std)	15m	2	Point-to-point	GPS modules, serial debugging
I2C	2	Sync	400 kbps	<1m	112	Multi-drop	Sensors, displays, EEPROMs
SPI	4+	Sync	10+ Mbps	<1m	Many	Multi-point	SD cards, displays, high-speed sensors

At local level (same room/building), wired communication is most common for IoT device interconnections.

Overview diagram of common wired communication protocols for IoT: UART for serial communication, I2C for multi-device bus, SPI for high-speed peripherals, RS-232/RS-485 for industrial, and Ethernet for networking — Figure 54.5: Common wired communication standards for IoT including UART, I2C, SPI, and Ethernet

Table 54.1

Table: Wired Communication Standards Comparison

NAME	SYNC/ASYNC	TYPE	DUPLEX	MAX DEVICES	MAX SPEED (Kbps)	MAX DISTANCE (m)	PIN COUNT
RS-232	async	point-to-point	full	2	20	30	3
RS-422	async	multi-drop	half	10	10,000	4,000	1
RS-485	async	multi-point	half	32	10,000	4,000	2
I2C	sync	multi-master	half	112	3,400	<1	2
SPI	sync	multi-master	full	Many	>10,000	<1	3+1
1-Wire	async	master/slave	half	Many	16	1,000	1
USB 2.0	async	master/slave	half	127	480,000	5	4
USB 3.0	async	master/slave	full	255	5,000,000	5	8

54.6 Common Misconception

“More Wires = Always Better Performance”

Misconception: “SPI is always faster than I2C because it uses more wires (4+ vs 2), so I should always choose SPI for better performance.”

Reality: While SPI can achieve higher speeds (10+ Mbps vs 400 kHz), the real-world performance difference is often negligible for most IoT applications:

Quantified Examples:

BME280 Temperature Sensor:
- I2C @ 400 kHz: Reading temp/humidity/pressure takes ~8 ms
- SPI @ 10 MHz: Same reading takes ~5 ms
- Difference: 3 ms savings (37% faster)
- Reality: For a weather station reading every 10 seconds, this 3 ms difference is irrelevant (0.03% of cycle time)
0.96” OLED Display (128x64 px):
- I2C @ 400 kHz: Full screen refresh ~60 ms
- SPI @ 8 MHz: Full screen refresh ~30 ms
- Difference: 30 ms savings (50% faster)
- Reality: Both achieve 15+ fps, imperceptible to human eye
SD Card Data Logging:
- I2C (not supported): N/A
- SPI @ 25 MHz: 512-byte sector write ~200 µs
- Reality: Here SPI is essential not because of “more wires” but because SD cards don’t support I2C protocol

Why the misconception?

Pin count does not equal performance: I2C’s 2-wire limitation isn’t the bottleneck; it’s the pull-up resistor RC time constant (rise time limits frequency)
Protocol overhead: I2C has 7-bit addressing + ACK bits (9 bits per byte), while SPI has 8 bits per byte - but for multi-byte transfers, this overhead is ~10%
Real bottleneck: Sensor conversion time (BME280 takes 8 ms to measure, regardless of interface speed)

When SPI truly matters:

High-throughput: SD cards, high-resolution TFT displays (320x240+), camera modules
Continuous streaming: Audio I2S (2.8 Mbps for 44.1 kHz stereo), DMA-driven data acquisition
Low latency: Real-time motor control loops (<1 ms cycle time)

The trade-off: SPI saves 1-5 ms per transaction but costs 2-3 extra GPIO pins per device. For battery-powered IoT nodes with limited pins, I2C is often superior despite lower speed.

Alternative View: Wired Interface Selection Flowchart

This variant presents wired communication selection through a decision-tree lens - useful for IoT designers choosing between UART, I2C, SPI, and RS-485 for specific hardware requirements.

Figure 54.6: Decision flowchart for selecting wired communication interface based on distance, device count, speed, and pin constraints

54.7 Key Concepts

Before diving into specific protocols, understand these fundamental concepts:

54.7.1 Protocol

Definition: A set of rules and conventions governing information exchange between devices.

Example: TCP/IP (seen in previous chapters) is a protocol suite for internet communication.

54.7.2 Synchronous vs Asynchronous Communication

Figure 54.7: Synchronous vs Asynchronous Communication Timing

Synchronous:

Devices share a common clock transmitted on a dedicated wire
Data synchronized to clock edges
Simpler, more reliable
Examples: I2C, SPI

Asynchronous:

No clock wire transmitted
Devices run independent clocks at same speed
Data lines used for synchronization (start/stop bits)
Example: RS-232, UART

54.7.3 Peer Communication

Definition: Entities at the same layer of a network that communicate with each other.

Peer-to-peer communication diagram showing two devices directly connected and communicating without intermediary, both acting as equals in bidirectional data exchange — Figure 54.8: Peer communication showing direct device-to-device connections

In wired bus protocols, even master-slave relationships are peer communication at the data link layer (OSI Layer 2) – the master and slave use the same shared medium and the same framing format:

Master and slave devices communicating as peers at the data link layer (Layer 2) — Figure 54.9: Master-Slave Peer Communication at Layer 2

In wired protocols: Master and slave are peers at the same protocol layer, even though the master controls bus access.

54.7.4 Point-to-Point, Multi-Drop, Multi-Point

Three connection topologies: point-to-point with single dedicated link between two devices, multi-drop with multiple devices on shared bus, and multi-point with selective device addressing — Figure 54.10: Point-to-point, multi-drop, and multi-point network topologies

The diagram below maps these topologies directly to the wired protocols used in IoT:

Figure 54.11: Point-to-Point, Multi-Drop, and Multi-Point Topology Comparison

Point-to-Point:

Two devices using dedicated wires
Example: RS-232

Multi-Drop:

Many devices sharing same set of wires (bus)
Example: I2C

Multi-Point:

One master connecting to multiple slaves via dedicated wires
Example: SPI with multiple chip select lines

54.7.5 Master/Slave Networks

Master device:

Controls communication channel
Initiates all transactions
Determines when communication finishes

Slave devices:

Respond to master requests
Cannot talk directly to each other
Must wait for master to grant access

Prevents collisions: Only master controls when devices transmit.

54.7.6 Full-Duplex vs Half-Duplex

Full-Duplex:

Both endpoints can transmit simultaneously
Requires separate wires for each direction
Example: SPI (MOSI and MISO wires)

Half-Duplex:

Only one endpoint transmits at a time
Can share single wire (bidirectional)
Example: I2C (SDA line shared)

54.8 Worked Example: Selecting Wired Protocols for a Smart Greenhouse Controller

Scenario: You are designing an ESP32-based greenhouse controller. It must read data from 6 sensors, drive an LCD display, and log data to an SD card. The ESP32 has 34 GPIO pins, but 12 are already used for Wi-Fi antenna, boot selection, and power management. That leaves 22 usable GPIOs.

Peripherals to connect:

Device	Data Rate	Update Frequency	Notes
BME280 (temp/humidity/pressure)	<100 kbps	Every 10 sec	Available in I2C and SPI
BH1750 (light sensor)	<100 kbps	Every 10 sec	I2C only
SCD30 (CO2 sensor)	<100 kbps	Every 30 sec	I2C only
Soil moisture (analog)	N/A	Every 60 sec	ADC pin, not a bus protocol
2.4” TFT Display (320x240)	~6 Mbps	5 fps continuous	SPI recommended
MicroSD card	~5 Mbps	On data write	SPI only

Step 1: Identify protocol constraints

BH1750 and SCD30 are I2C-only – no choice for these
MicroSD is SPI-only – no choice
BME280 supports both I2C and SPI
TFT display strongly prefers SPI (I2C is too slow for 5 fps at 320x240)

Step 2: Calculate GPIO usage for each configuration

Option A: I2C bus + SPI bus (hybrid)

Bus	Devices	GPIO Pins
I2C (shared SDA + SCL)	BME280, BH1750, SCD30	2 pins
SPI (shared MOSI, MISO, SCK)	TFT display, SD card	3 pins + 2 CS pins = 5 pins
Total		7 pins

Option B: Everything on SPI (where possible)

Bus	Devices	GPIO Pins
SPI bus 1	BME280, TFT, SD card	3 + 3 CS = 6 pins
I2C (still needed)	BH1750, SCD30	2 pins
Total		8 pins

Step 3: Evaluate performance

For the TFT display at 5 fps with 320x240 pixels x 16 bits/pixel:

Data per frame: 320 x 240 x 2 bytes = 153,600 bytes
Data rate needed: 153,600 x 5 fps = 768,000 bytes/sec = 6.14 Mbps
I2C max (fast-mode plus): 1 Mbps – too slow (would get <1 fps)
SPI at 20 MHz: sufficient (achieves 5+ fps easily)

For the BME280 sensor (24 bytes per reading, once every 10 sec):

I2C at 400 kHz: 24 bytes x 9 bits/byte (with ACKs) / 400,000 = 0.54 ms
SPI at 10 MHz: 24 bytes x 8 bits / 10,000,000 = 0.019 ms
Difference: 0.52 ms – completely irrelevant for a 10-second interval

Try It: GPIO Pin Budget Calculator

Estimate the GPIO pins needed for your own bus configuration.

Show code

{
  const i2cPins = i2cDevices > 0 ? 2 : 0;
  const spiShared = spiDevices > 0 ? 3 : 0;
  const spiCS    = spiDevices;
  const spiPins  = spiShared + spiCS;
  const uartPins = uartDevices * 2;
  const total    = i2cPins + spiPins + uartPins;
  const remaining = availableGPIO - total;
  const ok = remaining >= 0;

  return htl.html`
    <div style="font-family:Arial,sans-serif; padding:1rem; background:#f8f9fa; border-radius:6px; border-left:4px solid ${ok ? '#16A085' : '#E74C3C'};">
      <h4 style="margin-top:0; color:#2C3E50;">GPIO Budget Summary</h4>
      <table style="width:100%; border-collapse:collapse; font-size:0.9em;">
        <thead>
          <tr style="background:#2C3E50; color:white;">
            <th style="padding:8px; text-align:left;">Bus</th>
            <th style="padding:8px; text-align:right;">Pins Used</th>
            <th style="padding:8px; text-align:left;">Breakdown</th>
          </tr>
        </thead>
        <tbody>
          ${i2cDevices > 0 ? `<tr style="background:white;"><td style="padding:8px; color:#16A085; font-weight:bold;">I2C (${i2cDevices} devices)</td><td style="padding:8px; text-align:right;">${i2cPins}</td><td style="padding:8px; color:#7F8C8D;">SDA + SCL (shared by all)</td></tr>` : ''}
          ${spiDevices > 0 ? `<tr style="background:#f0f4f8;"><td style="padding:8px; color:#3498DB; font-weight:bold;">SPI (${spiDevices} devices)</td><td style="padding:8px; text-align:right;">${spiPins}</td><td style="padding:8px; color:#7F8C8D;">MOSI+MISO+SCK (3) + ${spiDevices} CS pins</td></tr>` : ''}
          ${uartDevices > 0 ? `<tr style="background:white;"><td style="padding:8px; color:#E67E22; font-weight:bold;">UART (${uartDevices} devices)</td><td style="padding:8px; text-align:right;">${uartPins}</td><td style="padding:8px; color:#7F8C8D;">${uartDevices} × (TX + RX)</td></tr>` : ''}
          <tr style="background:#2C3E50; color:white;">
            <td style="padding:8px; font-weight:bold;">Total bus pins</td>
            <td style="padding:8px; text-align:right; font-weight:bold;">${total}</td>
            <td style="padding:8px;"></td>
          </tr>
        </tbody>
      </table>
      <p style="font-size:1em; font-weight:bold; color:${ok ? '#16A085' : '#E74C3C'}; margin-bottom:0;">
        ${ok
          ? `${remaining} GPIO pins remain free (out of ${availableGPIO}) for actuators, LEDs, buttons.`
          : `Over budget by ${-remaining} pins! Reduce devices or use an I2C GPIO expander.`}
      </p>
    </div>
  `;
}

Step 4: Decision

Decision	Choice	Reasoning
BME280 interface	I2C	0.5 ms extra is irrelevant; saves 1 CS pin
TFT display	SPI	I2C physically cannot deliver 5 fps (needs 6 Mbps)
SD card	SPI	Only option; shares bus with TFT
BH1750, SCD30	I2C	Only option

Final design: 2 buses (I2C + SPI), 7 GPIO pins total, leaving 15 GPIOs free for actuators (relay, pump, fan). The key insight is that bus protocol selection should be driven by data rate requirements and device constraints, not by a blanket “faster is better” assumption. The BME280 gains nothing measurable from SPI, while the TFT display absolutely requires it.

Common Pitfalls

1. Assuming Wired Communication Is Always More Reliable Than Wireless

Poorly terminated connectors, damaged cables, and ground loops cause wired communication errors that can be harder to diagnose than RF issues. Fix: test wired connections with a protocol analyser or oscilloscope, not just a continuity tester.

2. Ignoring Electrical Isolation Requirements

Connecting IoT devices on different ground potentials without isolation can cause destructive ground loops or expose devices to dangerous voltages. Fix: use optoisolators or isolated transceivers when connecting devices across different power domains.

3. Mixing RS-232 and RS-485 Without Level Conversion

RS-232 uses ±12 V signalling; RS-485 uses differential ±5 V signalling. Connecting them directly will damage the transceivers. Fix: always use the appropriate level-shifter or transceiver chip when converting between wired communication standards.

🏷️ Label the Diagram

Code Challenge

54.9 Summary

This chapter introduced the fundamental concepts of wired communication:

Binary transmission challenge: Converting digital data to electrical signals requires standardized protocols
Synchronous vs asynchronous: Clock-shared protocols (I2C, SPI) are simpler; independent-clock protocols (UART) need start/stop bits
Network topologies: Point-to-point for dedicated links, multi-drop for shared buses, multi-point for star configurations
Master-slave architecture: Prevents collisions by having one device control bus access
Full vs half duplex: Trade-off between simultaneous bidirectional communication and wire count

54.10 Knowledge Check

Quiz: Wired Communication Fundamentals

54.11 What’s Next

Topic	Chapter	Description
UART and RS-232	UART and RS-232	Deep dive into asynchronous serial communication used for GPS modules, Bluetooth adapters, and debug consoles
I2C Protocol	I2C Protocol	Two-wire synchronous bus with addressing — the default choice for sensors, displays, and EEPROMs
SPI Protocol	SPI Protocol	High-speed full-duplex interface used for SD cards, TFT displays, and fast ADCs
Wired Communication Overview	Wired Communication Protocols	Survey of all major wired protocols used at the IoT device layer
Wired Ethernet	Wired Access: Ethernet	How Ethernet extends wired communication from the device to the network level
Network Access and Physical Layer	Network Access and PHY	Physical-layer fundamentals that underpin both wired and wireless IoT connections