When would you choose SPI over I2C, and when would I2C be the better choice?

Choose SPI when: (1) High data throughput is the priority — SPI clocks at 10-50 MHz vs I2C's typical 400 kHz (fast mode) or 1 MHz (fast mode plus). For applications like reading a high-speed ADC, streaming audio data, accessing SPI NOR flash, or driving a TFT display, I2C is simply too slow. (2) Full-duplex communication is needed — I2C is inherently half-duplex on a single data line. (3) Low latency matters — SPI has no addressing phase, no ACK overhead, and no arbitration delay. The first clock edge transfers data. (4) Only a small number of peripherals are present — two or three SPI slaves are manageable; a dozen would consume too many CS pins.

Choose I2C when: (1) Pin count is constrained — I2C uses exactly two wires (SDA, SCL) regardless of how many devices are connected, vs SPI's 3 + N wires (MOSI, MISO, SCK, plus one CS per slave). (2) Many low-speed peripherals share the bus — temperature sensors, EEPROMs, real-time clocks, port expanders, and fuel gauges are all I2C devices that communicate infrequently and at low data rates. (3) Multi-master support is required — I2C has built-in arbitration; SPI does not. (4) Hot-plugging or dynamic device discovery is needed — I2C devices can be enumerated by scanning addresses.

A practical rule of thumb: use SPI for anything that needs bandwidth (flash, displays, high-speed sensors) and I2C for everything that needs convenience (configuration, status monitoring, low-speed peripherals). Many embedded designs use both on the same board.