Choosing a display interface for a touchscreen product

A team picks a good-looking display module, wires it to an ESP32 or STM32 on the bench, and the demo runs. Then the real interface goes on top, with animation, a second task and a firmware update path. The screen tears, flickers or shifts sideways. The panel was fine. The interface choice was made on the first day without a memory budget.

The display interface decides how many pins you spend, how much RAM the UI needs, and what else the chip can do while the screen updates. It is cheap to choose well early and painful to change after the board exists.

The three interfaces that matter on small MCUs

SPI. Few pins, easy routing, works on nearly every MCU. The panel’s controller chip normally holds its own frame memory, so the MCU only sends the parts of the image that changed. The cost is bus speed: every pixel crosses a serial link. Espressif’s SPI LCD documentation shows the usual pattern: DMA enabled on the bus, and the transfer size capped at a set number of lines per transaction so the CPU is not held up by one long write.

8080-style parallel (i80). An 8- or 16-bit data bus plus write strobe, data/command select and chip select. Same idea as SPI, since the panel still has its own memory and you push pixels into it, but with far more bandwidth per clock. The i80 LCD documentation notes the bus width is 8 or 16 bits, command formats are chip specific, and a faster pixel clock can cause flicker if DMA bandwidth is not sufficient.

RGB (parallel pixel stream). The MCU is the frame source. It must keep sending the whole picture, continuously, at the panel’s refresh rate. There is no controller memory to hide a late frame. That is the whole trade: RGB gives you the highest-resolution panels and smooth full-screen motion, and it makes the MCU’s memory system part of the display.

SPI and i80 hide a slow MCU. RGB exposes it.

Why RGB panels flicker, and why it is a memory problem

Espressif’s RGB LCD documentation is unusually direct about this. A full-resolution frame buffer usually lives in external PSRAM. With a single PSRAM buffer, the LCD peripheral can fetch data directly from PSRAM, but the bandwidth is shared with the CPU. The document says that a high pixel clock with PSRAM-backed buffers can starve the LCD peripheral and corrupt the display. If the image falls behind, it can end up permanently shifted until the driver restarts it.

The documented mitigations each have a cost:

• Lower the pixel clock. Simple, and it lowers the refresh rate.
• Bounce buffers. Two small buffers in internal RAM feed the panel while the CPU copies from PSRAM. This allows a higher pixel clock and tolerates short bandwidth spikes. It also raises CPU use, and the document warns the LCD cannot function while the external memory cache is disabled, such as during writes to main flash for OTA or NVS.
• Two full-screen buffers. The documented way to avoid tearing. It doubles the frame memory.

That flash-write warning matters for products. A display that holds steady on the bench but glitches during a firmware update or settings save is a failure of exactly this kind. Test the screen while the device is writing flash, not only while it is idle. If your update design is not settled, our note on firmware updates with recovery and rollback covers the flash side.

Other chips handle this differently. Some STM32 parts have a dedicated LCD controller and can scan out of internal or external RAM without CPU help. Check the reference manual for the exact part before assuming either behavior.

What LVGL needs from the interface

Most products with a touchscreen use LVGL, and its buffer model lines up directly with these interfaces. The LVGL display setup documentation describes three render modes:

Mode	Buffer size	What the flush callback does
Partial	Smaller than the screen	Copies each rendered area to the matching area of the display
Direct	Full screen	Typically just changes the frame buffer address
Full	Full screen	Updates the frame buffer address; whole screen redrawn every update

Partial mode suits SPI and i80. The panel keeps the image, LVGL redraws only what changed (a pressed button redraws its own area), and the docs recommend buffers of at least one tenth of the display size. That is a few tens of kilobytes of internal RAM on a small panel. Two buffers let rendering and transfer overlap when DMA does the transfer.

Direct and full modes suit RGB, because the scan-out hardware reads a complete frame. You pay for it in RAM. Full mode redraws the whole screen on every update even if one pixel changed, which loads the CPU and the memory bus.

So the interface and the render mode are one decision. Choose RGB with a UI that animates the whole screen, and you have chosen a PSRAM part, a bandwidth budget and a flash-write test. Choose SPI with a mostly static UI, and a small MCU with no external RAM may do the job.

The checks we run before committing to a panel

1. Write the UI first, in words. Static screens with small updates, or full-screen transitions and video? This alone often removes RGB from the list.
2. Work out the frame memory. Pixels times bytes per pixel, times the number of buffers. Compare it against internal RAM and PSRAM, and note which task owns the bus when both CPU and display want it.
3. Count pins and routing. RGB uses a wide parallel bus that wants length-matched, short routes and a connector to match. SPI uses a handful of lines.
4. Read the panel controller datasheet, not the module listing. The listing names a resolution. The datasheet says which interfaces the controller actually supports and what init sequence it needs. Modules often arrive with the interface selected by solder jumpers or resistor options.
5. Plan the touch controller separately. Touch usually arrives over I2C with an interrupt and reset line. It does not share the display’s bandwidth problem, but it does share the connector, the cable and the enclosure.
6. Test under load. Run the screen while flash is written, while Wi-Fi or BLE is active and while logging runs. Intermittent corruption shows up here, not on an idle bench.
7. Check supply continuity. Display modules change controllers or vendors without warning. Ask what happens if the module is replaced, and keep the interface and connector pinout flexible where you can. If the display is e-paper, the partial refresh and ghosting note covers a different set of limits.

What it costs in time and risk

A wrong interface choice usually surfaces after the first prototype build, when software meets the real panel. At that point the options are a lower refresh rate, a different MCU, or a board respin to change the connector and routing. None of those is quick. Spending a day on the memory budget first costs far less than finding a shifted image during an OTA test.

SPI is the lowest-risk path for most products, as long as the UI is modest. RGB is the right answer when the product needs it, and then it deserves a real bandwidth test on a dev kit with the same MCU and the same panel before the schematic is final.

How we approach it

We pick the interface from the UI and the memory budget, prove it on a development kit with your panel, then design the connector, routing and firmware around that choice. Send us the panel datasheet, the MCU you are considering and a description or sketch of the screens, and we will tell you which interface fits and what it needs from the board.