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?
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.