I2C, SPI, and Serial Interfaces for IoT Sensors
I2C, SPI, UART, serial communication, sensor interface, ESP32, Arduino, bus protocol
I2C’s SDA and SCL lines are open-drain: a device can only pull the line low, never drive it high. The pull-up resistor and the bus’s own parasitic capacitance – wire, pins, ESD structures – are what pull the line back up, and that recovery is not instant. It is a first-order RC charging transient, the same time constant \(\tau=RC\) that governs any resistor charging a capacitor. The I2C specification cares whether the line crosses from its low threshold to its high threshold before the next clock edge needs it there, which is exactly why this chapter’s own key-concepts line hedges its pull-up value with a clock speed – “4.7 kohm at 100 kHz” – instead of naming one resistor for every mode. The wire itself is a separate story: at I2C’s clock frequencies, and even its fast edge-rate harmonics, the bus is only a tiny fraction of a wavelength long, so it behaves as a lumped RC network rather than a transmission line – which is why I2C design worries about capacitance and pull-up value, not the cable matching an RF antenna feed line must have.
Open-drain rise through a pull-up into bus capacitance:
\[V(t) = V_{DD}\left(1-e^{-t/RC}\right), \qquad \tau=RC\]
I2C rise time is specified between \(0.3V_{DD}\) and \(0.7V_{DD}\):
\[t_r = RC\,\ln\!\left(\frac{0.7}{0.3}\right) \approx 0.847\,RC\]
A bus stays a lumped element, not a transmission line, while its physical length is much shorter than the signal wavelength:
\[\ell \ll \lambda = \frac{c}{f}\]
By the end of this chapter, you will be able to:
Sensor communication protocols are the foundation of IoT data acquisition. Every sensor reading must travel from the physical sensor to your microcontroller through a defined communication interface. Understanding these protocols enables you to design reliable, efficient sensor networks.
Think of communication protocols like different languages. Just as people need to speak the same language to understand each other, sensors and microcontrollers need to “speak” the same protocol to exchange data. The most common “languages” are I2C (pronounced “eye-squared-see” or “eye-two-see”), SPI (“spy”), and UART (“you-art”). Each has different rules about how many wires to use, how fast to talk, and how to address specific devices.
I2C (Inter-Integrated Circuit) is a two-wire synchronous protocol perfect for connecting multiple sensors using minimal GPIO pins. It uses:
Reading sensor data over I2C follows a two-phase pattern: first write the register address you want to read, then request the data bytes. The endTransmission(false) sends a Repeated START instead of a STOP, keeping the bus locked for the subsequent read.
For learning, trace the transaction before reading code:
START.REPEATED START.STOP.#include <Wire.h>
#define I2C_SDA 21
#define I2C_SCL 22
#define BMP280_ADDR 0x76
#define BMP280_CHIP_ID_REG 0xD0
void setup() {
Serial.begin(115200);
Wire.begin(I2C_SDA, I2C_SCL);
// Read chip ID register to verify communication
uint8_t chipId;
readI2CRegister(BMP280_ADDR, BMP280_CHIP_ID_REG, &chipId, 1);
Serial.print("BMP280 Chip ID: 0x");
Serial.println(chipId, HEX); // Should print 0x58 for BMP280
}
void readI2CRegister(uint8_t addr, uint8_t reg, uint8_t* data, uint8_t len) {
Wire.beginTransmission(addr);
Wire.write(reg); // Phase 1: Write register address
Wire.endTransmission(false); // Repeated START (no STOP)
Wire.requestFrom(addr, len); // Phase 2: Read data bytes
for(int i = 0; i < len; i++) {
if(Wire.available()) {
data[i] = Wire.read();
}
}
}
void loop() { }Estimate total bus capacitance to determine if your I2C bus will work reliably. The I2C specification limits bus capacitance to 400 pF for standard mode and fast mode.
This simulation demonstrates how I2C bus scanning works. Add devices to the bus, then click “Scan Bus” to see the master controller query each address and detect ACK/NACK responses.
SPI (Serial Peripheral Interface) is a synchronous, full-duplex communication protocol using four lines: MISO (Master In Slave Out), MOSI (Master Out Slave In), SCK (Serial Clock), and CS (Chip Select). Unlike I2C, SPI supports simultaneous bidirectional data transfer.
| Feature | I2C | SPI |
|---|---|---|
| Wires | 2 (SDA, SCL) | 4+ (MISO, MOSI, SCK, CS per device) |
| Speed | 100 kHz - 3.4 MHz (standard/fast/high-speed) | 1-100 MHz |
| Topology | Multi-master, multi-slave | Single master (typical), multi-slave |
| Addressing | 7-bit addresses (112 usable) | Hardware CS pins (limited by GPIO) |
| Data Transfer | Half-duplex (sequential) | Full-duplex (simultaneous) |
| Protocol Overhead | START, STOP, ACK/NACK | Minimal (just CS selection) |
| Typical Use | Multiple sensors, displays | High-speed: SD cards, displays, ADCs |
| GPIO Efficiency | High (2 pins for many devices) | Low (3 shared + 1 CS per device) |
Calculate the effective data throughput for your SPI configuration based on clock speed and transaction overhead.
Choose I2C when:
Choose SPI when:
Option A: I2C bus (BME280 + BH1750 + MPU6050): Wire count 2 (SDA, SCL shared), GPIO usage 2 pins total for 3+ sensors, max speed 400kHz (~44kB/s), read latency ~100-200us per sensor at 400kHz (address + register overhead), power during transfer ~1mA, cable length up to 1-3 meters with 4.7k pull-ups
Option B: SPI bus (BME280 + SD card + TFT display): Wire count 3 shared + 1 CS per device = 6 pins for 3 devices, max speed 10-40MHz (1-5MB/s), read latency ~10us per sensor (direct register access), power during transfer ~5-10mA (higher clock), cable length 10-30cm max at high speeds
Decision Factors: For battery-powered environmental monitoring nodes with 3-5 slow sensors, I2C saves pins and power while 400kHz is adequate for 100Hz sensor reads. For data logging to SD card (500kB/s sustained), displays (30fps video), or high-speed ADCs (1MSPS), SPI is mandatory. Hybrid approach: use I2C for slow sensors, SPI for SD/display. Watch for I2C address conflicts - BME280 has only 2 addresses (0x76, 0x77), limiting you to 2 per bus without multiplexer.
UART (Universal Asynchronous Receiver/Transmitter) is the simplest serial protocol, using just two wires for point-to-point communication without a clock signal. Unlike I2C and SPI, UART is asynchronous – both sides must agree on the baud rate (bits per second) beforehand.
UART is commonly used for GPS modules (NMEA sentences at 9600 bps), Bluetooth modules (HC-05 AT commands), GSM/cellular modems, and debug/logging output. Many sensors provide UART as a simpler alternative to I2C/SPI, though at lower data rates.
Open this only after you understand the wiring rule: sensor TX connects to MCU RX, sensor RX connects to MCU TX, and both devices must use the same baud rate.
// Reading GPS data over UART (Serial2 on ESP32)
#define GPS_RX 16
#define GPS_TX 17
void setup() {
Serial.begin(115200); // USB debug output
Serial2.begin(9600, SERIAL_8N1, GPS_RX, GPS_TX); // GPS at 9600 baud
}
void loop() {
while (Serial2.available()) {
char c = Serial2.read();
Serial.print(c); // Forward GPS NMEA sentences to USB
}
}Calculate the effective data throughput for a UART connection based on baud rate and frame configuration.
| Feature | I2C | SPI | UART |
|---|---|---|---|
| Wires | 2 | 3 + 1/device | 2 |
| Topology | Bus (multi-device) | Bus (multi-device) | Point-to-point |
| Clock | Synchronous (shared) | Synchronous (shared) | Asynchronous (agreed) |
| Speed | 100 kHz - 3.4 MHz | 1-100 MHz | 9600 - 921600 bps |
| Duplex | Half-duplex | Full-duplex | Full-duplex |
| Best For | Many slow sensors | High-speed data | Simple serial devices |
The troubleshooting, bus-budget, and worked-example material is now a focused child chapter instead of a second treatment inside this page.
Key protocol takeaways: