I2C or SPI? Interface Choice for a Small Appliance Display
The interface question on a small appliance panel is usually settled by what the microcontroller has left, not by a comparison of standards. That is the right instinct, but it is worth understanding what is being traded. A two-wire bus saves pins and shares easily, at the cost of update speed and more careful firmware. A clocked interface is faster and simpler to drive, at the cost of pins that a cost-optimised appliance board may not have. A 0.96-inch 128x64 module with several interface options lets the board designer decide late, which is often the most valuable property of all.
Key takeaways
- A two-wire bus carries addressing on the same two lines as data, so several devices share it with no extra pins [1]
- A clocked interface transfers a whole frame faster and does not require the host to manage bus arbitration
- Pin count is the scarcest resource on a small appliance board, where the microcontroller is chosen for cost rather than for peripherals
- Bus sharing turns timing into a system property: display updates, sensor reads and any memory device all compete for the same lines
- The firmware cost differs too, since a shared bus needs error handling and a clocked interface needs careful chip-select management
Appliance control boards are designed around a single microcontroller and a list of functions that must be supported at the lowest possible cost. The display is one of those functions, and it competes for the same pins as a temperature sensor, a user interface and often a small memory device.
That competition is why a two-wire bus is so common in this market. Two lines, shared by everything, with each device selected by an address rather than by a dedicated pin. The trade is speed and, to a degree, predictability, because a long display transfer blocks everything else on the bus.
A clocked interface has the opposite profile. It uses more pins but transfers a frame in a fraction of the time and does not require the host to arbitrate. On an appliance, the practical question is whether the microcontroller has the pins and whether the display update is on any timing-critical path.
What each interface costs in pins, time and attention
The pin cost is the visible difference. A two-wire bus uses two lines plus pull-up resistors, and devices are distinguished by address, which is why the standard was designed for exactly this situation [1]. A clocked interface uses at least three or four lines depending on whether a data/command signal is needed, and each device needs its own chip select.
The time cost favours the clocked interface. A 128x64 monochrome frame is a small payload, but it still takes noticeably longer on a two-wire bus at a comparable clock rate, and a full refresh can occupy the bus for milliseconds that other devices may need.
The attention cost is less obvious and often decisive. A shared bus requires the firmware to handle arbitration and to recover from a device that holds a line low. A clocked interface requires the firmware to manage chip select correctly, which is simpler but less forgiving of a mistake, since a mis-driven chip select can corrupt another device's transfer.
Practical differences on an appliance control board
| Aspect | Two-wire bus | Clocked interface |
|---|---|---|
| Pins required | Two, shared by all devices on the bus | Three or four per device, including chip select |
| Update time for a full frame | Longer, and it occupies the bus for the whole transfer | Short, with the bus free again immediately afterwards |
| Adding a second device | No extra pins, subject to address availability | Another chip-select pin and another routing decision |
| Error handling | Needs arbitration, timeout and recovery logic | Simpler protocol, but chip-select discipline is essential |
| Typical fit | Small boards with many slow peripherals | Boards that need fast, isolated display updates |
Sharing a bus without disturbing the measurement
On an appliance, the bus is shared with sensors whose readings are the actual purpose of the product. A display transfer that delays a sensor read by a few milliseconds is rarely a problem, but a display refresh that blocks a bus for tens of milliseconds during a control loop is.
The mitigation is to bound the transfer. Write only the region that changed, keep a full refresh for occasions when the screen genuinely changes entirely, and avoid a driver that redraws the screen on a timer. A 0.96" PMOLED display with a two-wire interface can keep its bus occupancy small if the firmware treats updates as events rather than as a background task.
It also helps to schedule. If the control loop runs on a fixed period, place the display update in the idle part of that period rather than at an arbitrary moment. Deterministic scheduling is easier to reason about than priority tuning, and it removes the need for most of the error handling.
Firmware consequences of the choice
The choice shapes the driver. A shared-bus driver needs a transaction wrapper that takes the bus, performs the transfer and releases it, and every access must go through that wrapper. Where the code bypasses it, a rare and difficult intermittent fault appears under load.
A clocked interface driver is simpler in structure but has its own discipline: chip select must be asserted before the command byte and released afterwards, and any interrupt that touches the bus must not disturb that window. The failure mode is usually a corrupted frame rather than a hung bus.
Both cases benefit from keeping the display driver isolated behind a small set of functions. On an appliance that is updated for years, that isolation is what makes a panel substitution a firmware change of a few lines rather than a project.
It is also worth writing down the maximum time the display is allowed to hold the bus, and testing that limit with the worst-case screen. A limit that exists only in the designer's head will be exceeded by the first feature that adds a progress indicator.
Choose the interface that the board can support, then constrain the driver to suit it, rather than choosing the interface that appears in the example code. The interface is one of the few display decisions that can be deferred until the schematic review, and taking that time usually saves a board revision.
Sources
Frequently asked questions
Is a two-wire interface fast enough for a 128x64 display?
For status content that changes occasionally, yes. A full refresh takes longer than on a clocked interface, so the driver should update only the region that changed. If the screen changes completely and often, the bus occupancy becomes a system issue rather than a display issue.
What happens if the display shares a bus with sensors?
Nothing, as long as each transfer is bounded and the driver always releases the bus. The risk is a long display refresh that delays a sensor read, which is why updates should be events scheduled in idle time rather than a background task.
Does a clocked interface require more firmware?
It is simpler in protocol but requires chip-select discipline, since another device on the bus can be corrupted by a mis-timed select. A two-wire bus needs arbitration and recovery logic instead. Both are manageable if the driver is isolated behind a small interface.
Can the interface choice be changed later?
It is far easier to change than the mechanical envelope, because it affects the schematic, the driver and the connector rather than the tooling. For that reason a module offering several interface options is worth selecting even if only one is used in the first product revision.