The first architecture decision in an HMI project is often described as MCU versus MPU versus SoC. In practice, product labels overlap. A display-focused SoC may run RTOS, an MCU may integrate substantial graphics capability, and an MPU-based module may hide much of the hardware complexity. The useful question is simpler: how much system complexity does the HMI need to own?
Quick answer
For a focused, cost-sensitive HMI with fast boot and modest graphics, start with an MCU or RTOS-oriented platform. For larger displays, richer graphics, networking, video or complex applications, an MPU or Linux-capable SoC is usually more appropriate. Select the architecture from UI workload, display, OS, connectivity and lifecycle—not the processor label alone.
| Requirement | Usually start with |
|---|---|
| Simple UI, low cost and fast boot | MCU |
| Richer graphics without a full Linux stack | Performance RTOS SoC |
| Full Qt Quick/QML, networking and multimedia | Linux MPU / SoC |
| Video, camera and complex connectivity | Multimedia SoC |
These are workload classes, not strict chip categories. LVGL can also run on Linux, and Qt for MCUs uses a different framework from full Qt Quick. Verify the platform's drivers, memory and graphics path with the intended application.
Think in architecture classes, not labels
Control-first
Best when the UI is tightly coupled to real-time control, boot time and cost matter, and memory requirements are modest.
UI-first RTOS
Useful when richer graphics, larger displays or connectivity are needed without moving the whole product to Linux.
System-first
Best when the HMI needs complex applications, rich networking, multimedia, browser-like software stacks or multi-process services.
Six questions usually decide the class
Basic controls and status screens are very different from multi-page workflows, charts, animation, video or camera processing.
Resolution, frame rate, interface and number of screens strongly affect memory bandwidth and graphics requirements.
An LVGL application on RTOS and a Qt/QML application on Linux imply different memory, toolchain and maintenance models.
Simple UART/RS485 is one problem; Ethernet, Wi-Fi, Bluetooth, cellular, cloud services and remote updates are another.
Some equipment wants an interface in a fraction of the time a full Linux stack may require, while other products value application richness more.
The cheapest prototype architecture is not always the lowest-risk production platform. Consider updates, security, product variants and developer availability.
A useful rule of thumb
- UI is focused and predictable;
- fast boot and low system overhead matter;
- cost and power are tightly constrained;
- the application can live comfortably inside an embedded framework.
- graphics and display requirements are growing;
- you need richer animation or larger frame buffers;
- you want more capability without a full Linux software stack.
- Qt/QML or similar application frameworks are important;
- video, camera, advanced networking or local services are central;
- the HMI is becoming a general application platform.
Do not over-specify too early
It is easy to start with a powerful processor “for headroom.” That can add memory, PCB, boot, thermal and software complexity that the product never uses. The opposite mistake is equally common: choosing a very small MCU and then spending months working around memory and graphics limits.
Start from the display, UI, OS, connectivity and lifecycle. Then map those requirements to a platform class. Exact silicon should come later.
Architecture questions
MCU vs MPU for industrial HMI?
Start with the functions the HMI must own. A focused status-and-control interface with modest graphics can fit an MCU or RTOS platform. More complex applications, services, networking or multimedia may justify an MPU and Linux. Verify the display, memory, BSP and interface workload before choosing a specific processor.
Is Linux necessary for a 7-inch HMI?
No. Physical size alone does not decide the OS. Resolution, refresh rate, animation, video, connectivity and application complexity matter more. A performance RTOS platform may support a focused 7-inch LVGL interface; a richer workload may call for Linux. Test a representative screen and data flow on candidate hardware.
When is LVGL + RTOS enough?
It is a useful starting point when the UI and product services can fit the platform's resource budget, the required drivers and interfaces are supported, and the important workflows meet their response and reliability targets. A need for substantial multimedia or a broader application ecosystem is a reason to evaluate another architecture.
How much memory does a high-resolution HMI need?
There is no fixed RAM value that follows from display size. Budget resolution, color depth, framebuffer and draw-buffer strategy, GUI framework, asset caching, animation and video, then add application, driver and OS memory. A basic full-frame pixel buffer is width × height × bytes per pixel; the number of buffers, stride and additional surfaces change the allocation. Partial rendering can use smaller draw buffers where the display and port support it. Measure peak usage with the real workflow.
Use the LVGL Memory Estimator for initial budgeting and LVGL's display documentation for buffer strategy. Connect the architecture decision to the Figma handoff workflow and the hardware prototype workflow.