Interface selection for a small monochrome panel is often argued as if bandwidth were the constraint. It is not. A 64x48 display holds 3,072 pixels, which is under 400 bytes in the module's own frame format, and even a modest update rate leaves any of the common buses with most of its capacity unused. What actually separates SPI, I2C and parallel wiring in an industrial panel is noise immunity, pin count, whether other devices share the bus, and how the controller behaves when the display stops responding. Those are the questions worth answering before the schematic is drawn, because all three options change the board layout differently.
Key takeaways
- The panel's payload is small enough that bandwidth never decides the choice; wiring, noise and sharing decide it.
- SPI uses more pins but tolerates long traces and noisy environments better than an open-drain bus.
- I2C saves pins and allows several devices to share two wires, at the cost of pull-up sizing and address management.
- A parallel interface is only rational when the host already has a spare memory-style bus and the board has room for it.
- Whatever the bus, the reset and data-command lines deserve individual attention because they set the module's power-up behaviour.
Industrial HMI panels live next to contactors, motors and switching supplies. The display itself is a small part of the electrical environment, but it is frequently the part whose misbehaviour is most visible, because a corrupted frame is obvious while a corrupted sensor reading may not be.
That asymmetry pushes designs towards buses with clean edges and unambiguous framing. It also means the pull-up resistors, the series terminators and the ground return are worth more thought than the protocol driver, which for these interfaces is usually a library call.
The comparison below is written for a 0.66-inch 64x48 monochrome module, but the reasoning applies to most small status displays in the same class.
What a 0.66-inch 64x48 panel needs from its bus
The numbers are small. A full frame of 3,072 monochrome pixels is 384 bytes, and typical updates touch a handful of characters. Even at fifty full updates per second the payload is under twenty kilobytes per second, which every candidate bus can carry with margin. On a 0.66" OLED display with this pixel layout the whole frame fits in a few hundred bytes, so the interface should be chosen on electrical and mechanical grounds rather than on throughput. The bus choice therefore has almost nothing to do with the display's information rate.
What matters instead is how the bus behaves when the system is disturbed. A display transaction that is interrupted by a motor start can leave the panel showing a half-written frame, and recovering from that requires either error detection on the link or a periodic full refresh. Both are easier on a bus with explicit framing and a dedicated chip select than on a shared two-wire bus with no way to detect a lost byte.
Pin budget is the counter-argument. On a small controller every pin is contested, and a display that consumes four or five of them may displace an encoder or an extra relay output. That trade is a product decision, not a technical one, and it should be made explicitly rather than by defaulting to whatever the example code used.
Bus options for a 64x48 monochrome HMI panel
| Bus | Wiring cost | Where it fits |
|---|---|---|
| SPI | Four or five pins including chip select | Long traces, noisy panels, single display per bus, straightforward framing |
| I2C | Two pins shared with other devices | Pin-constrained boards with short traces and a quiet electrical environment |
| Parallel | Eight or more data lines plus control | Hosts that already have a spare memory-style bus and a large board |
| SPI with a shift register | Few pins on the host, more parts on the board | Legacy controllers that cannot spare a hardware peripheral |
SPI, I2C and the practical differences that matter
Both buses are decades old and both are documented in ways that make the electrical design the interesting part rather than the protocol.
Synchronous serial with an explicit select line
SPI is a full-duplex synchronous serial bus with a clock generated by the host and a separate select line per device, which means a transaction has a clear beginning and end and cannot be confused with traffic for something else [1]. That structure is why it survives in electrically hostile equipment: a glitch during a transaction is visible as a bad frame, not as a command delivered to the wrong device.
The cost is pins. A display that uses clock, data, select and a data-command line consumes four host pins before reset and power control are counted, and long traces need series termination to keep the edges clean. In return the timing is easy to reason about, the clock can be slowed down when the board is noisy, and nothing else on the board depends on the same two wires.
Two wires, shared addressing and pull-up arithmetic
I2C uses two open-drain lines with pull-up resistors and addresses each device, so several peripherals can share the same pair of pins [2]. On a board where the controller has run out of pins that is a decisive advantage, and for a display that is updated occasionally the throughput is entirely adequate.
The hidden work is in the pull-ups and the bus capacitance. Every added device and every centimetre of trace raises the capacitance that the pull-up must charge within the timing budget, and a value copied from an evaluation board with a short cable can be wrong on a panel with a long harness. Address conflicts are the other trap: displays, sensors and memory devices occasionally arrive with the same fixed address, which forces either a bus multiplexer or a change of part.
Choosing and validating the bus in five steps
- Count the pins before the protocolList every peripheral and work out how many spare pins the controller really has. This decides whether a shared bus is a convenience or a necessity.
- Decide how a corrupted frame is recoveredEither the link detects errors or the firmware refreshes the display periodically. Pick one deliberately, because relying on neither means an occasional frozen screen in the field.
- Fix the electrical details with the harness in placeSize pull-ups for the real cable capacitance, or add series termination for SPI, and confirm the edges with the harness connected rather than on a short bench lead.
- Test with the noisiest load switchingRun motors, relays and the switching supply while updating the display continuously. Interference problems appear as visible artefacts, which makes them easy to find if you look for them.
- Document the bus budgetRecord clock rate, pull-up values, trace lengths and the refresh policy in the schematic notes. The next revision will otherwise re-derive them by experiment.
A useful rule for small HMI panels is that the display should never be the only device whose failure is invisible. If the panel can be refreshed from a watchdog timer at a low rate, a corrupted frame recovers by itself, and the choice between buses becomes a much less risky decision.
Sources
Frequently asked questions
Is SPI or I2C better for a 0.66-inch OLED display in an industrial panel?
SPI is usually the safer choice where the electrical environment is noisy or the harness is long, because the explicit select line makes each transaction unambiguous and the clock can be slowed when needed. I2C is a better fit when pins are scarce and the display shares a short, quiet bus with a few other devices.
How much data does a 64x48 monochrome frame actually contain?
Just over 3,000 pixels, which is 384 bytes in a one-bit-per-pixel format. Even with overhead and frequent updates the payload is small, which is why bus bandwidth is not a useful selection criterion for this class of display.
What happens if a display transaction is interrupted by electrical noise?
The usual result is a partially written frame, a wrong character or a frozen update, depending on where the interruption occurred. Recovery is either link-level error detection or a periodic full refresh driven by a timer, and choosing one of those in advance is more reliable than hoping the environment is quiet.
Do the pull-up resistors on an I2C bus matter for a small display?
They do, because the value has to charge the total bus capacitance within the timing budget. A value that works on a short evaluation lead can be too weak for a long harness, producing rounded edges and intermittent failures that disappear whenever the cable is shortened.