SPI. A display needs to push a lot of pixel data quickly, and SPI is the only one of the three that reaches tens of MHz, with full-duplex shifting that streams data efficiently and almost no per-transfer protocol overhead (no addressing, no ACK between bytes). I2C tops out around 400 kHz-1 MHz for most parts and adds per-byte ACK overhead, so a display over I2C would be visibly slow to refresh, a classic mismatch. UART isn't designed for this kind of one-master-to-one-peripheral high-rate block transfer and lacks a clock for tight synchronization. With SPI you'd also typically pair it with DMA so the CPU isn't feeding bytes one at a time, and you accept the cost, a chip-select pin and the lack of built-in error checking, which is fine for a short on-board trace to a display. So: throughput requirement → SPI, ideally DMA-driven.
Communication Protocols · Interview question
You need to drive a fast color display. Which bus and why?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Choosing UART, SPI, or I2C
A side-by-side comparison and a decision framework: pick by speed, device count, pin budget, and distance, and know when none of the three fits and you need CAN or RS-485.
More Choosing UART, SPI, or I2C questions
You have a board with eight sensors, an EEPROM, and an RTC, and very few free pins. Which bus?How does pin count scale differently across the three buses as you add devices?Why are UART, SPI, and I2C all poor choices for sending data across a machine or vehicle?In practice, how do you decide between two buses when either could work?
Browse all 472 interview questions