The Three Pillars of Serial Communication
In the embedded firmware domain, microcontrollers must continuously share bytes with auxiliary peripherals: sensors, displays, memory registers, or other co-processors. Rather than utilizing bulky parallel buses that sap I/O pin lines, engineers implement three core serial communication protocols: UART, SPI, and I2C.
Each serial protocol represents a specific engineering compromise:
- **UART** (Universal Asynchronous Receiver-Transmitter) focuses on absolute wiring simplicity (just 2 lines) at the expense of asynchronous speed constraints.
- **I2C** (Inter-Integrated Circuit) offers elegant, multi-drop hardware bus addressing over 2 shared open-drain lines at moderate speeds.
- **SPI** (Serial Peripheral Interface) provides blazing, dedicated full-duplex synchronous speeds (10-50+ MHz) at the expense of excessive wire routing.
Wiring and Network Trade-offs
When scaling a sensor array, the network topology dictates pin routing limits.
The **I2C bus** is physically comprised of two pull-up resistor-terminated open-drain lines: Serial Data (SDA) and Serial Clock (SCL). Because of open-drain characteristics, any device can pull the line low safely. Devices are selected via a unique **7-bit or 10-bit software address** sent in the data frame. This allows up to 127 devices to share the exact same 2 pins!
The **SPI bus** is composed of: Master Out Slave In (MOSI), Master In Slave Out (MISO), Serial Clock (SCK), and a dedicated **Chip Select (CS)** line for *each* slave device. While it operates at ultra-high speeds because it does not suffer from high open-drain resistor rise-time delays, adding 5 SPI devices requires routing 5 distinct Chip Select wires, rapidly draining microcontroller GPIO registers.
Serial Protocol Comparison Table
| Parameters | UART | I2C | SPI |
|---|---|---|---|
| Pins Required | 2 (TX, RX) | 2 (SDA, SCL) | 3 + N Slaves (MOSI, MISO, SCK, CS) |
| Duplex | Full Duplex | Half Duplex | Full Duplex |
| Addressing | None (Point to Point) | 7 or 10-bit Software Address | Hardware (Chip Select line) |
| Typical Speed | 9600 - 115200 bps | 100kbps, 400kbps, 1.7Mbps, 3.4Mbps | 10 - 50+ Mbps |
Mistakes to Avoid in Bus Routing
❌ Forgetting Pull-up Resistors on I2C Lines
Since I2C drivers are open-drain, the bus *cannot* pull itself high. Without physical pull-up resistors (typically 4.7k or 10k) connected between the SDA/SCL lines and VCC, the bus will remain stuck in a low-voltage state permanently, leading to immediate communication timeouts.
❌ Mismatched SPI Clock Modes (CPOL / CPHA)
SPI supports four distinct clocking formats dictated by Clock Polarity (CPOL) and Clock Phase (CPHA). If the master microcontroller is configured to Mode 0 (CPOL=0, CPHA=0) while the sensor operates in Mode 3 (CPOL=1, CPHA=1), the master will sample data on the wrong clock edges, yielding corrupted, junk bytes.
Frequently Asked Questions
Can I connect a 5V I2C sensor to a 3.3V microcontroller directly?
Generally, no. Connecting a 5V open-drain line directly to 3.3V tolerant I/O pins will exceed absolute maximum voltage limits, leading to semiconductor degradation. You must use active bi-directional logic level translator ICs (e.g. BSS138-based modules).
What is Clock Stretching in I2C?
Clock stretching is a mechanism where a slow slave device holds the SCL clock line low to pause the transaction. The master cannot proceed until the slave releases the SCL line high, allowing slow microcontrollers to process internal data buffers safely.
Is there a limit to how many devices can share SPI?
Practically, the limit is bound by your microcontroller's remaining GPIO pins (for chip select lines) and bus capacitance. For extremely high node counts, engineers implement shift-register address decoders to select SPI slaves with fewer CS pins.
Conclusion
Selecting serial protocols is all about system resource management. Choose **SPI** for display panels and memory dumps where speed is king. Choose **I2C** for multi-sensor configurations where routing space is minimal. Choose **UART** for point-to-point command shells or GPS modules. Trace these protocols dynamically in our sensor interfacing pathway to build absolute industry competence.