Comparison

SPI vs I2C

You have one free I2C bus and six spare GPIO pins on your STM32. Adding three more sensors is trivial over I2C — they share two wires, each with a 7-bit address. Add one high-speed ADC and the I2C bus is the bottleneck; you route a SPI bus instead and run the ADC at 10 MHz with its own CS line. That GPIO-versus-speed calculus is made dozens of times in every embedded design, and this comparison gives you the numbers to make it correctly.

ECE, EI

Side-by-side comparison

ParameterSPII2C
Wires per SlaveMOSI, MISO, SCK, CS — 4 minimum; +1 CS per extra slaveSDA, SCL shared by all slaves — always 2 wires
Max SpeedUp to 80 MHz (STM32H7); 10–50 MHz practicalStandard 100 kHz; Fast-mode 400 kHz; Fast-mode+ 1 MHz
Full DuplexYes — MOSI and MISO simultaneouslyNo — half duplex on single SDA line
AddressingNo address; CS pin selects slave7-bit or 10-bit address in every transaction
Pull-up ResistorsNot required (push-pull drivers)Required — 4.7 kΩ (100 kHz), 2.2 kΩ (400 kHz) to VDD
Bus Capacitance LimitNot a bus topology — no cumulative capacitance issue400 pF maximum per I2C specification (limits node count and cable length)
Slave CountLimited by GPIO count (1 CS per slave)Up to 127 (7-bit); 1023 (10-bit) on two wires
Error DetectionNone in hardware (CRC optional in software)ACK/NACK per byte — node confirms receipt
Clock StretchingNot applicableSlave can hold SCL low to insert wait states (slow EEPROM, MCU in ISR)
Typical PeripheralsSD card, NOR flash (W25Q128), TFT LCD (ILI9341), high-speed ADC (ADS8689)EEPROM (24LC256), RTC (DS3231), IMU (MPU-6050), temperature sensor (LM75)

Key differences

SPI is push-pull and has no bus capacitance limit — you can drive a W25Q128 flash at 80 MHz on a short PCB trace with no pull-up resistors. I2C is open-drain: every high level is pulled up through a resistor, and the combination of pull-up resistance and bus capacitance creates a low-pass filter that limits speed (R×C < 300 ns for Fast-mode+). At 400 pF total bus capacitance — the I2C spec maximum — a 2.2 kΩ pull-up gives 880 ns time constant, borderline for 400 kHz. SPI is the only option when streaming data above 1 MHz. I2C wins when pin count matters and data rates are modest, because 10 sensors share two wires while SPI would need 12 GPIO pins for the same 10 sensors.

When to use SPI

Use SPI for high-throughput peripherals: data-logging to SD cards, TFT display updates, high-speed ADC acquisition, or NOR flash programming. Example: an STM32F4 writes a 512-byte SD card sector via SPI at 25 MHz in 163 µs; the same transfer over I2C at 400 kHz would take over 10 ms.

When to use I2C

Use I2C for slow-to-medium-speed sensor networks where minimising wire count and GPIO usage is more important than raw bandwidth. Example: a wearable device reads heart rate (MAX30102, 0x57), accelerometer (LSM6DS3, 0x6A), and temperature (LM75, 0x48) on one I2C bus at 400 kHz using only two STM32L0 pins.

Recommendation

If throughput matters (memory, display, fast ADC), choose SPI — nothing else comes close at the same pin count per device. If you have many sensors and limited pins, choose I2C. The cross-over is roughly at three slaves: above three peripherals, I2C saves more pins than SPI adds speed; below three, SPI's simplicity and raw speed tip the balance.

Exam tip: Examiners ask students to calculate the maximum I2C clock frequency given pull-up resistance and bus capacitance — use f_max ≈ 0.3/(R_pull × C_bus) derived from the 300 ns rise time limit in the I2C specification.

Interview tip: An interviewer at a hardware startup will ask why you chose SPI over I2C for an SD card — answer: SD card block writes need sustained throughput of at least 1 MB/s which requires SPI at 8–25 MHz; I2C at 400 kHz maxes out at 50 kB/s — two orders of magnitude too slow.

More Embedded Systems comparisons