SPI vs I2C for Small Displays: Bandwidth and Real-World Limits
Small displays sit on two very different serial buses. SPI moves pixel data at high speed over four wires; I2C moves modest amounts of data over two wires at far lower rates. The practical…
Bus Basics: SPI and I2C Wiring and Speed
The two buses differ in wires and clocking:
- SPI — a master clock (SCLK), master-out line (MOSI), and usually a chip-select per device; data moves in one direction per clock edge. It has no official speed ceiling; practical display links run from a few MHz to tens of MHz depending on wiring and the controller.
- I2C — two wires (SDA and SCL) with addressing and arbitration built in. Standard modes run at 100 kHz and 400 kHz, with faster modes available; it trades speed for a minimal pin count and multi-device bus support.
Those clock rates frame everything that follows. I2C’s 400 kHz carries roughly 50 kilobytes per second at best; an SPI link at 20 MHz carries roughly 2.5 megabytes per second. That three orders of magnitude difference decides which bus can stream pixels.
Bandwidth Math: Why Color Frames Fit SPI but Not I2C
To estimate a display’s pixel-stream needs, multiply pixels by bytes per pixel by frame rate:
Required rate ≈ active pixels × bytes per pixel × frame rate
Worked example. A 320×240 panel in RGB565 (2 bytes per pixel) at 15 frames per second:
320 × 240 × 2 × 15 ≈ 2.3 MB/s ≈ 18.4 Mbps
An I2C bus at 400 kHz moves only a small fraction of that, so streaming color frames over I2C is not viable. An SPI link in the 20–40 MHz range can approach or exceed the need, with overhead for commands and protocol. At higher resolutions or frame rates, even SPI runs out of headroom—which is why larger displays move to RGB parallel, LVDS, or MIPI (covered in the interface guides).
The formula and example above are general engineering calculations with assumed values. Confirm the actual speed modes, overhead, and timing for your controller and panel before finalizing a design.
What I2C Handles: Commands, Touch, and Monochrome
I2C is well suited to low-data-rate traffic on a shared bus:
- Controller commands — configuration and control messages are small and infrequent.
- Touch controllers — a touch report is a few bytes per event; I2C carries it easily. Note that touch interface choice has its own guide, because touch and display buses are separate decisions.
- Monochrome or low-update displays — a small monochrome screen updated occasionally needs very little bandwidth.
The two-wire advantage matters when pins are scarce or several devices share one bus. The cost is speed and the complexity of bus arbitration.
What SPI Handles: Pixel Streams and Partial Updates
SPI becomes the display bus when the panel sends pixel data continuously:
- Color TFTs with moderate resolution and frame rate — SPI can stream full frames when the clock is high enough.
- Partial updates — for content that changes in regions (text, gauges), SPI can refresh only the dirty area, cutting effective bandwidth dramatically.
- Write-heavy control — fast initialization and register writes benefit from SPI’s speed and simple framing.
SPI needs dedicated lines per bus and careful routing at higher clocks, but for a small display it is the standard way to move color pixels from a microcontroller.
Power and Pins: Two-Wire vs Four-Wire Trade-Offs
| Factor | I2C | SPI |
|---|---|---|
| Pins | 2 (SDA, SCL) plus shared bus | 3–4 per device (SCLK, MOSI, CS; MISO optional) |
| Speed | 100–400 kHz typical; faster modes exist | MHz to tens of MHz typical |
| Multi-device | Addressing built in | Chip-select per device |
| Best for | Commands, touch, small updates | Pixel streams and faster writes |
Power differences are usually secondary to speed and pin count. Faster clocks consume more dynamic power, but a display that finishes its update sooner can sleep longer; measure the real duty cycle rather than comparing clock rates.
SPI or I2C: Choosing the Bus for Your Small Display
Choose in this order:
- Calculate the pixel load — pixels × bytes × frame rate; include partial-update savings if the UI redraws regions.
- Compare against bus capacity — if the load fits I2C’s effective rate with margin, I2C saves pins; otherwise SPI is required.
- Check the host — which bus and clock does your microcontroller support, and are the pins available?
- Check the panel — does the display controller accept SPI, I2C, or both?
For a concrete wiring and initialization walkthrough on a bar display, see the implementation guide for driving a small bar TFT from an MCU; the landscape of bar display interfaces is covered separately. For touch devices, remember the host interface decision is independent and lives in the touch interface guide.
Frequently Asked Questions
Is SPI faster than I2C for displays?
Yes, by a wide margin in practice: SPI clocks in the megahertz range while I2C standard modes run at 100–400 kHz. Full color frames need SPI-class bandwidth; I2C suits commands and small updates.
Can I2C drive a color TFT?
Not for streaming full color frames at useful rates. I2C can handle commands and very small, low-frame-rate content, but pixel streams need SPI or a higher-bandwidth interface.
What speed does SPI need for a small display?
Compute pixels × bytes per pixel × frame rate, add protocol overhead, then choose an SPI clock above that with margin. Small panels often run comfortably at 10–40 MHz.
Why do small displays use SPI?
Because SPI provides the bandwidth to move color pixel data from a microcontroller with only a few wires, which is the practical sweet spot for small to mid-size TFTs.
If you are choosing a bus for a small display, start with the pixel-load calculation and the host’s available pins and clocks. CDTech reviews display and interface specifications for custom modules—contact us with your resolution, frame rate, and host to discuss the right bus.
