How to build an embedded HMI: choosing between SPI, parallel RGB, LVDS and MIPI DSI, the bandwidth maths behind each, touch bring-up, and the LVGL, Linux or Android decision that follows.
An embedded HMI (Human-Machine Interface) — the screen, touch and controls through which a product presents itself to the person using it — is usually discussed as a software problem. In practice it starts as a hardware one. On most products with a screen, the display is chosen late — after the processor, after the enclosure concept, sometimes after the industrial design is signed off. That order is backwards. The panel's interface determines which processors are even candidates, how many pins and layers the board needs, how long the flex cable can be, what the power budget looks like with the backlight on, and whether the software stack can be a few hundred kilobytes of LVGL or has to be a full Linux or Android system.
We have built interfaces across the whole span — from 2.4 inch SPI panels on battery-powered instruments to 32 inch LVDS panels on equipment that runs continuously — and the pattern is consistent: the projects that go smoothly are the ones where the panel, the interface and the software stack were decided together, early, from the product's actual requirements. This article is how we make that decision.
SPI panels need few pins, tolerate longer and cheaper flex cables, and work with almost any microcontroller. They dominate below about 3.5 inches and remain viable up to around 4.3 inches for interfaces that are not animation-heavy.
The constraint is bandwidth, and the arithmetic is unforgiving. A full-screen update needs width × height × bytes-per-pixel bits pushed through the bus; at typical SPI clock rates, a 320×240 16-bit panel refreshes in the low tens of milliseconds, while a 480×800 panel at the same clock cannot sustain smooth full-screen animation at all. The practical answer is to stop doing full-screen updates: partial rendering, dirty-rectangle refresh and small animated elements are what make SPI feel responsive. That is a design discipline as much as a software setting.
We use SPI panels where the product's interface is informational rather than cinematic — instrument front panels, handheld detectors, status displays on battery products. Our OLED-based handheld detection instruments and the display on our sleep sound box fall in this class.
Parallel RGB — sometimes called DPI — sends pixel data on 16, 18 or 24 data lines plus clock and sync signals. Bandwidth is far higher than SPI, panels are cheap and widely available in the 4.3 to 10.1 inch range, and most application-class SoCs expose an RGB controller.
The costs are pins and layout. Twenty-plus signals that all switch together at the pixel clock need length matching, careful return paths and attention to EMI, and they consume GPIO that the product may want for other things. The flex cable has to be short. In an enclosure where the board and the panel are far apart, RGB gets difficult quickly.
This is the interface we see most often on white goods, industrial panels and equipment front ends in the 5 to 10 inch range, where the panel sits directly above the board and the mechanical distance is short.
LVDS serialises the pixel data onto a few differential pairs. That buys two things RGB cannot: longer cable runs and larger, higher-resolution panels. From roughly 10 inches upward — and in any product where the display is mechanically separated from the main board, such as a hinged lid or a separate panel assembly — LVDS is usually the answer.
The design work shifts to differential routing: impedance control, intra-pair matching, connector selection and shielding. Single-channel versus dual-channel LVDS is decided by resolution and refresh rate, and getting that wrong is discovered at bring-up when the panel displays nothing or shows artefacts at the top of the frame.
Our delivered LVDS work includes display boards built around Allwinner platforms with multi-screen support, and the RK3128 platform where LVDS and MIPI were both brought up on the same Linux board.
MIPI DSI is what modern mobile-derived panels use. It delivers high resolution over a handful of differential lanes with excellent power efficiency, which is why it dominates in phones, tablets and anything that borrows their supply chain.
It is also the least forgiving interface of the four. Lane lengths must match, the flex connector choice matters, the panel's power-up sequence and initialisation command set must be exactly right before anything appears, and many panels are driven through a bridge chip rather than directly — which adds its own configuration and timing.
We have taken this path repeatedly. Our Raspberry Pi DSI display project brought up 4.3, 5, 7 and 10 inch panels on a Raspberry Pi 5 using an ICN6211 bridge for MIPI DSI conversion, with the display configured through DTS and DTBO device tree overlays and I2C debug logging used to diagnose the touch path. We have also designed custom MIPI mainboards on Allwinner T113. The transferable lesson: swap the panel on the same electrical interface and the timing parameters, power-up sequence and touch configuration all change with it. Keeping that configuration in device tree overlays rather than hard-coded in drivers is what makes a product line with several screen options maintainable.
Once the panel and interface are fixed, the realistic software options narrow sharply. We ship all four of the following and choose per product.
Bare metal with LVGL. For small SPI panels on cost-driven products where the interface is a handful of screens and the rest of the firmware is simple. Minimal footprint, no scheduler overhead, complete control over timing.
FreeRTOS with LVGL. The default for MCU products where the screen coexists with communication stacks, sensor sampling or control loops. The GUI gets its own task with a bounded refresh budget, and time-critical work is not starved by a redraw. In our 433MHz security linkage system an STC32G128K runs FreeRTOS driving sub-GHz terminals, a camera SDK and an LCD/OLED status display at the same time — the discipline there is that the display never blocks the radio.
Embedded Linux. Once the product needs a filesystem, networking services, video, or a panel beyond what an MCU can drive, Linux is the practical floor. The display becomes a device tree and framebuffer problem, and the UI layer can be LVGL, Qt or a browser-based front end. We have built this on Allwinner T113 and V3S, Rockchip RK3128, and Raspberry Pi hardware.
Android. Chosen when the product wants the Android application ecosystem, app-style UI expectations, or a customer-facing interface that will be developed by app developers rather than firmware engineers. Our ultrasound touch control system uses Android for the touch interface on medical equipment, communicating with the instrument over a dedicated protocol — a case where the interface layer needed app-grade UI work while the device side stayed deterministic.
There is also TouchGFX on STM32, which we used on an electric vehicle dashboard with a dark theme, frame-sequence animation and a systematic icon set. It is the right call when the chip is fixed STM32 and a designer-led workflow matters; we compared it with LVGL in detail in our LVGL GUI development article.
One more combination worth naming: ESP32-S3 with PSRAM and LVGL has become a common answer for colour touch interfaces that cannot justify an application processor. We cover the memory budget and bandwidth maths for that case in the ESP32-S3 development guide.
Teams routinely budget for the display and forget that touch is its own bring-up. Capacitive controllers need their own I2C or SPI wiring, interrupt handling, firmware configuration and calibration. The controller's configuration often has to be tuned for the specific cover glass thickness and the panel stack-up, and a configuration that works on a bare panel can behave badly once the glass is bonded.
Industrial and white goods environments add noise. A touch panel next to a motor, a heater or a switching power supply sees interference that a bench setup never shows. Shielding, ground strategy and controller threshold tuning are part of the design, not an afterthought.
On our Raspberry Pi DSI project, touch calibration across four panel sizes consumed a meaningful share of bring-up time, and I2C debug logs were what made the path diagnosable. Budget for it explicitly.
Medical. Interface stability and response determinism matter more than visual flourish, documentation requirements are heavier, and the device protocol between the interface and the instrument is a deliverable in its own right. Our ultrasound touch control system is in this class, as is the RK3128-based ultrasound platform and the control system for a nucleic acid detector where we also did the mainboard hardware and LCD driver work.
White goods. Cost per unit dominates, the interface is used by people who never read a manual, and the environment is hot, humid and electrically noisy. Our oven control board work is a good example of the constraints: touch that must work through a panel, in heat, next to switching loads, at a price that survives a competitive BOM review.
Industrial. Wide temperature range, long product lifecycle, panel availability over years, resistance to vibration and EMI, and sometimes glove or wet-finger operation. Here panel selection is as much a supply-chain decision as a technical one — a panel that goes end-of-life in two years is a problem even if it is perfect today.
Our depth here has an origin: the team's early work included full television product development, which forces familiarity with panel interfaces, timing, image processing and the whole display signal chain at a level that most embedded projects never reach. That background is why interface selection, timing debugging and panel bring-up are routine for us rather than exploratory.
Since then we have delivered display work across the range — a 240×240 colour touch screen on a low-power smart watch, LVGL interfaces on Jieli parts in a handheld console and a smart scale motherboard, an Apollo2 low-power display terminal, LCD and OLED status displays on security and detection products, DSI panels from 4.3 to 10 inches on Raspberry Pi hardware, LVDS display boards with multi-screen support, custom MIPI mainboards on Allwinner T113, Android interfaces on medical equipment, and advertising-player style Android and Linux systems. The interfaces, sizes and software stacks differ; the method does not.
If you are specifying a display for a product and want the panel selection, the board, the bring-up and the interface software handled by one team, our embedded software service and hardware design service cover that path end to end.
Contact us for customized solutions and quotes