3. 嵌入式HMI软件架构
智能家居HMI设备形态差异极大：墙面板可能只有一颗Cortex-M4加128KB RAM，中控屏却可能是四核A55跑Linux。软件架构选型的第一步，不是挑GUI库，而是先确定操作系统底座，再决定GUI框架、驱动层与中间件的分层方式。架构选错，后期换屏、加协议、做OTA都会付出成倍代价。
一、RTOS与Linux：两条底座路线的本质差异
RTOS（FreeRTOS、RT-Thread、Zephyr）与Linux的核心差异不在"能不能跑GUI"，而在实时性、内存模型与启动时间。RTOS是单地址空间、静态内存为主、中断延迟通常在微秒级；Linux有MMU、进程隔离、虚拟内存，中断到用户态响应通常在毫秒级，且启动需数秒。
对HMI而言，关键判断点是：屏幕刷新是否与硬实时控制耦合。若设备同时要驱动继电器、采样传感器并保证10ms级响应，RTOS更稳；若设备只做显示、联网、语音交互，Linux的生态优势更明显。
| 对比维度 | RTOS（FreeRTOS/RT-Thread） | 嵌入式Linux |
|---|---|---|
| 典型硬件 | Cortex-M0+/M4/M7，无MMU | Cortex-A7/A53，带MMU |
| 内存占用 | 几十KB~几百KB | 64MB RAM起步 |
| 启动时间 | 100ms~1s | 3s~15s |
| 实时性 | 微秒级中断延迟 | 毫秒级，需PREEMPT_RT |
| GUI生态 | LVGL、emWin、TouchGFX | Qt、LVGL(Linux后端)、Web |
| 适用场景 | 开关面板、温控器、门锁屏 | 中控屏、可视对讲、网关屏 |
二、GUI框架选型：按资源与交互复杂度匹配
四大主流框架的定位差异清晰：LVGL轻量、开源、C语言、控件丰富，MCU与Linux通吃，适合中小屏；emWin与TouchGFX偏MCU，前者商业授权成熟稳定，后者与STM32深度绑定、动画性能强；Qt面向Linux/Android，QML做复杂动效与多页面导航效率高，但资源门槛高。
选型可按三步走：先看RAM/Flash余量，再看交互复杂度（静态页面 vs 动画/多语言/网络数据绑定），最后看团队技能与授权成本。切忌"用Qt跑MCU"或"用LVGL硬撑4K大屏"。
选型速查（经验值）
MCU + RAM < 256KB → LVGL / emWin
MCU + RAM 256KB~2MB → LVGL / TouchGFX
Linux + 屏 ≤ 7寸 → LVGL(Linux) / Qt Widgets
Linux + 复杂动效/多页 → Qt Quick(QML)
需商业支持与认证 → emWin / Qt Commercial三、四层架构：驱动层、中间件、GUI层与应用层
无论底座是RTOS还是Linux，HMI软件都应划分为四层，层间只允许上层调用下层、下层通过回调/消息上报，禁止跨层直接访问寄存器或全局变量。
- 驱动层：LCD控制器、触摸IC、背光PWM、按键/编码器、传感器I2C/SPI。对上提供统一设备接口，如
disp_flush()、touch_read()。 - 中间件层：GUI框架本身、文件系统、网络协议栈（MQTT/Modbus/BLE）、OTA、日志、事件总线。它是"能力供给层"，不包含业务语义。
- GUI层：页面、控件、样式、动画、多语言资源。只负责"呈现与交互"，不直接操作硬件。
- 应用层：设备状态机、场景联动、配网逻辑、告警策略。它通过中间件的事件总线与驱动层解耦。
四、场景案例：智能温控面板的架构落地
以一款带2.4寸触摸屏、支持Wi-Fi与本地继电器的温控面板为例，采用RT-Thread + LVGL：
app_temp_ctrl.c 应用层：温度PID、场景模式、告警
gui_pages/ GUI层：主页、设置页、配网页
middleware/ 中间件：LVGL、MQTT、KV存储、事件总线
drivers/ 驱动层：ST7789、GT911、继电器GPIO、NTC ADC
数据流：
NTC ADC → 驱动层 → 事件总线 → 应用层PID → 状态更新
状态更新 → 事件总线 → GUI层刷新标签 → LVGL → disp_flush → ST7789关键设计是事件总线：驱动层采样后只发事件，不直接改UI；应用层计算后也只发状态事件。这样GUI刷新与业务逻辑互不阻塞，RTOS下可用消息队列保证线程安全。
五、常见误区与复盘
复盘建议：架构评审时画一张依赖方向图，确认没有反向依赖与跨层调用；再用一次"换屏演练"验证驱动层是否真正可替换。架构的价值不在图好看，而在变更成本可控。