To read an SPI timing diagram, look at the clock (SCLK) idle state to determine CPOL (0 for LOW, 1 for HIGH) and the data sampling edge to determine CPHA (0 for leading edge, 1 for trailing edge). This combination defines your SPI Mode (0-3). If the diagram shows SCLK resting LOW and data changing on the rising edge, you need SPI Mode 0. Misinterpreting these two parameters is the number one reason SPI peripherals fail to initialize on the workbench.
Decoding the SPI Timing Diagram: CPOL, CPHA, and SPI Modes
Unlike I2C, which relies on a standardized software protocol, SPI (Serial Peripheral Interface) is a raw hardware shift register. The microcontroller and the peripheral must agree on exactly when to shift bits in and out. The Analog Devices SPI Guide formalizes this into four distinct modes based on Clock Polarity (CPOL) and Clock Phase (CPHA).
CPOL (Clock Polarity): Dictates the idle state of the SCLK line when Chip Select (CS) is asserted but no clock pulses are occurring. If the datasheet timing diagram shows SCLK resting at 0V (LOW) before the first pulse, CPOL = 0. If it rests at VCC (HIGH), CPOL = 1.
CPHA (Clock Phase): Dictates which edge of the clock pulse the data is sampled on. If MOSI/MISO data is valid and sampled on the leading (first) edge of the clock pulse, CPHA = 0. If it is sampled on the trailing (second) edge, CPHA = 1.
| SPI Mode | CPOL | CPHA | SCLK Idle State | Data Sampled On |
|---|---|---|---|---|
| Mode 0 | 0 | 0 | LOW | Rising (Leading) Edge |
| Mode 1 | 0 | 1 | LOW | Falling (Trailing) Edge |
| Mode 2 | 1 | 0 | HIGH | Falling (Leading) Edge |
| Mode 3 | 1 | 1 | HIGH | Rising (Trailing) Edge |
Workbench Tip: Most modern sensors (like the ADXL345 or BMP280) default to Mode 0 or Mode 3. If your timing diagram shows data shifting out on the falling edge while the clock idles LOW, you are looking at Mode 1—a notorious trap because many basic Arduino libraries hardcode Mode 0.
Physical Layer: Wiring, Logic Levels, and Pull-up Realities
A common misconception among hobbyists transitioning from I2C is that SPI requires pull-up resistors. Let's clear up the physical layer requirements.
| Parameter | SPI Specification | Practical Workbench Limit |
|---|---|---|
| Wires | 4 (SCLK, MOSI, MISO, CS) | +1 for every additional slave device (CS) |
| Speed | Up to 100MHz+ (Silicon dependent) | 10MHz - 20MHz for reliable breadboard wiring |
| Addressing | Hardware Chip Select (CS) lines | No software addressing; requires 1 GPIO per slave |
| Distance | Not formally defined | < 30cm at 10MHz; < 1 meter at 1MHz |
| Drivers | Push-Pull (Totem Pole) | Strong drive capability, no bus capacitance limits like I2C |
The Pull-up Resistor Reality
Because SPI uses push-pull drivers for SCLK, MOSI, and MISO, you do not need pull-up resistors on the data or clock lines. Adding them will actually degrade your rise times at high speeds. However, the Chip Select (CS) line is a different story. If your microcontroller reboots or the GPIO pin floats during initialization, a floating CS line can accidentally activate the SPI slave. If multiple slaves activate simultaneously, they will both drive the MISO line, causing a short circuit and data corruption. Always place a 10kΩ pull-up resistor between VCC and the CS line of every SPI slave.
Logic Level Translation
If you are connecting a 5V Arduino Mega to a 3.3V ESP32 or a 3.3V sensor, do not rely on internal clamping diodes. Use a dedicated logic level shifter like the TXB0104 or a BSS138 MOSFET-based bidirectional shifter to prevent frying the slave's silicon.
Minimal Working Exchange: ESP32 to ADXL345 Accelerometer
Let's wire an ESP32-WROOM-32 to an ADXL345 accelerometer and read the Device ID register to verify our timing diagram configuration. The ADXL345 datasheet specifies SPI Mode 3 (CPOL=1, CPHA=1) for 4-wire operation.
| ESP32 GPIO | ADXL345 Pin | Function |
|---|---|---|
| GPIO 18 (VSPI SCK) | SCL / SCLK | SPI Clock |
| GPIO 23 (VSPI MOSI) | SDA / SDI | Master Out Slave In |
| GPIO 19 (VSPI MISO) | SDO / ALT ADDRESS | Master In Slave Out |
| GPIO 5 (VSPI CS) | CS | Chip Select (Add 10k pull-up to 3.3V) |
| 3V3 | VCC | Power (3.3V only!) |
| GND | GND | Common Ground |
#include
#define CS_PIN 5
#define READ_BIT 0x80 // ADXL345 requires MSB high for reads
#define DEVID_REG 0x00 // Device ID register address
void setup() {
Serial.begin(115200);
pinMode(CS_PIN, OUTPUT);
digitalWrite(CS_PIN, HIGH); // Deselect slave
// Initialize hardware SPI (VSPI on ESP32)
SPI.begin();
delay(100);
// ADXL345 requires SPI Mode 3, Max 5MHz for initial setup
SPI.beginTransaction(SPISettings(5000000, MSBFIRST, SPI_MODE3));
digitalWrite(CS_PIN, LOW);
// Send register address with READ_BIT set
SPI.transfer(DEVID_REG | READ_BIT);
// Clock out the data
uint8_t devid = SPI.transfer(0x00);
digitalWrite(CS_PIN, HIGH);
SPI.endTransaction();
if (devid != 0xE5) {
Serial.print("Error: ADXL345 not found. Got DEVID: 0x");
Serial.println(devid, HEX);
Serial.println("Check CPOL/CPHA mode and wiring.");
} else {
Serial.println("Success: ADXL345 DEVID matches 0xE5.");
}
}
void loop() {
// Main application logic
} Sniffing and Debugging: When the Timing Diagram Lies
When your code compiles but returns 0xFF or 0x00 for every register read, it is time to hook up a logic analyzer. A Saleae Logic Pro 8 (or a $15 24MHz Cypress FX2 clone) is mandatory for this. Connect the probes to SCLK, MOSI, MISO, and CS, and set the trigger to the falling edge of CS.
The Classic Failure Modes
- CPOL/CPHA Mismatch: If your logic analyzer decodes the MOSI data perfectly, but the MISO data looks like random garbage or is shifted by exactly one bit, your SPI Mode is wrong. The master is sampling the MISO line on the wrong clock edge before the slave has finished driving it. Flip CPHA and try again.
- Baud Rate Mismatch and Ringing: If you push the ESP32 to 20MHz on a breadboard, the SCLK square wave will look like a sawtooth due to parasitic capacitance. The slave will see multiple clock edges (ringing) and shift out extra bits. Fix: Drop the baud rate to 1MHz for debugging. For production, add 33Ω series termination resistors on the MOSI and SCLK lines near the master to dampen reflections.
- CS Address Clash (Missing Pull-up): If MISO shows a solid HIGH or LOW line that refuses to change, or if the logic analyzer flags a "Contention Error", you likely have two SPI devices driving the MISO bus simultaneously. This happens when a CS line floats during MCU boot. Verify your 10kΩ pull-ups on all CS lines.
Protocol Decision Tree: SPI vs. I2C vs. UART
Choosing the right bus prevents architectural dead-ends. Use this decision matrix to select your protocol based on physical constraints.
| Condition / Constraint | Winning Protocol | Concrete Part / Implementation Pick |
|---|---|---|
| High throughput (>1Mbps), short distance (<30cm), few devices | SPI | ESP32-WROOM-32 (Hardware VSPI on GPIO 18, 19, 23, 5) |
| Many low-speed sensors, limited GPIOs, 2-wire constraint | I2C | TCA9548A I2C Multiplexer + BME280 sensors (4.7kΩ pull-ups) |
| Long distance (>1m), point-to-point, asynchronous data | UART / RS-485 | MAX485 transceiver module with 120Ω termination resistor |
| High speed, long distance, multi-drop network | CAN Bus | MCP2515 CAN Controller + TJA1050 Transceiver |
Final Verdict and Default Recommendation
Do not default to SPI just because it is "faster." SPI consumes a GPIO pin for every single slave device, which rapidly exhausts your microcontroller's pinout on complex boards.
The Default Pick: If your project involves high-bandwidth peripherals like SD cards, SPI RAM (e.g., ESP-PSRAM64), or TFT LCD displays, you must use SPI. Configure it on the ESP32-WROOM-32 using the dedicated hardware VSPI pins (GPIO 18, 19, 23, 5) to offload the CPU via DMA. For everything else—temperature sensors, OLED screens, and IMUs that only need a few bytes per second—use I2C. When using SPI, always verify the datasheet's timing diagram for CPOL/CPHA, and never omit the 10kΩ pull-up on the CS line.
