2. MCU与Linux UI协同开发概述
在嵌入式产品中，MCU（微控制器）与 Linux 主控常常同时存在：MCU 负责实时控制、电源管理、按键扫描、传感器采样与安全看护，Linux 负责图形界面、网络通信、多媒体与复杂业务逻辑。所谓“MCU 与 Linux UI 协同开发”，并不是让两者各自独立运行，而是让 Linux 上的 UI 能够可靠地读取 MCU 的状态、下发控制命令，并在异常时保持可控。理解这一协同关系，是后续通信协议设计、界面刷新策略与故障处理的基础。
一、核心原理：双核分工与消息闭环
协同开发的核心可以概括为“分工 + 通道 + 状态同步”。MCU 侧通常运行裸机或 RTOS，强调确定性：例如在 1 ms 内完成按键去抖、在 5 ms 内响应急停信号。Linux 侧运行完整操作系统，强调交互与扩展：Qt、LVGL、Flutter 等 UI 框架负责渲染，网络服务负责云端连接。两者通过物理通道（UART、SPI、I2C、CAN、USB、共享内存或网络）交换数据。
一个典型的闭环是：用户在 Linux UI 上点击“启动电机”，UI 通过通信层发送命令帧；MCU 解析后驱动 GPIO/PWM，并把电机状态、电流、温度回传；Linux 收到后更新界面。若通信中断，UI 必须进入“失联”状态而不是继续显示旧数据。这个闭环中，命令方向、状态方向和心跳机制缺一不可。
二、常见术语：沟通协同开发的共同语言
协同开发涉及硬件、驱动、协议与 UI 多个层面，术语不统一会导致联调效率低下。以下术语在需求评审和接口定义阶段必须明确：
| 术语 | 含义 | 协同中的关注点 |
|---|---|---|
| 命令帧 / 状态帧 | Linux 下发的控制报文与 MCU 上报的数据报文 | 帧头、长度、序号、校验、超时 |
| 心跳（Heartbeat） | 周期性保活报文，用于判断对端是否在线 | 周期、丢失阈值、失联后 UI 状态 |
| 寄存器映射 | MCU 内部变量与协议地址的对应关系 | 地址表版本、读写权限、字节序 |
| 事件 / 通知 | MCU 主动上报的异步变化，如按键、告警 | 去抖、优先级、UI 弹窗策略 |
| 看门狗 | MCU 或 Linux 侧用于检测程序卡死的机制 | 喂狗周期、复位后 UI 恢复 |
| OTA / 固件升级 | 通过 Linux 向 MCU 传输新固件 | 分包、校验、回滚、升级中 UI 提示 |
三、方法流程：从接口定义到联调验证
协同开发建议按以下流程推进，避免“先写 UI 再补协议”造成的返工：
- 定义功能边界：明确哪些状态由 MCU 采集、哪些由 Linux 计算，避免同一数据两处维护。
- 设计协议表：确定帧格式、地址映射、读写权限、默认值与异常值。例如：
帧格式示例：
[0xAA][0x55][CMD][LEN][SEQ][DATA...][CRC16]
命令示例：
CMD=0x01 启动电机 DATA: 速度(2B) + 方向(1B)
CMD=0x02 停止电机 DATA: 无
状态示例：
CMD=0x81 电机状态 DATA: 电流(2B) + 温度(2B) + 故障码(1B)
心跳：
CMD=0x7F 心跳 DATA: 无，周期 500 ms- 实现通信层：Linux 侧封装串口/SPI 读写与解析线程，MCU 侧实现中断接收与状态机解析。
- UI 状态绑定：将协议字段映射为 UI 控件属性，并设置“未知/失联/故障”三种显示状态。
- 联调与压测：使用模拟器或脚本注入异常帧、丢包、延迟，验证 UI 是否卡死或误显示。
四、应用场景与典型案例
MCU 与 Linux UI 协同广泛存在于以下场景：
- 工业 HMI：Linux 显示工艺流程与报警，MCU 控制气缸、变频器与安全门。UI 必须实时反映急停状态。
- 智能家居中控：Linux 运行触屏界面与语音服务，MCU 管理灯控、窗帘电机与温湿度采样。
- 医疗设备：Linux 负责报告与网络，MCU 负责泵速、压力采集与硬件联锁，协同中安全优先级最高。
- 车载座舱：Linux 负责娱乐与导航，MCU 负责车身信号、电源管理与看门狗，通信常采用 CAN。
- 充电桩：Linux 显示计费与支付，MCU 控制继电器、计量与急停，需处理断网与掉电场景。
以工业 HMI 为例，一个常见误区是：UI 只根据“最后一次收到的状态”刷新，而不判断数据是否过期。若 MCU 因干扰复位，Linux 仍显示“运行中”，操作员可能误判。正确做法是引入时间戳与心跳计数，超过阈值即切换为“通信异常”并禁止下发危险命令。