1. 课程导入
在嵌入式产品开发中，一个常见的现象是：MCU 负责实时控制、电机驱动、传感器采样和低功耗管理，而 Linux 主控负责图形界面、网络通信、数据存储和复杂业务逻辑。两者各自擅长不同领域，却必须协同工作，才能构成一台完整的智能设备。本课程围绕“MCU 与 Linux UI 协同开发”这一主题，帮助学习者建立从系统架构到通信协议、从界面联动到工程落地的完整知识体系。
一、为什么需要 MCU 与 Linux UI 协同
纯 MCU 方案成本低、实时性强，但难以支撑复杂的图形界面、多任务网络服务和海量数据存储；纯 Linux 方案界面丰富、生态完善，却在高精度 PWM、硬实时中断和微秒级响应上存在天然短板。因此，工业 HMI、智能家居中控、医疗设备、车载终端等产品普遍采用“MCU + Linux”双核或双芯片架构：MCU 贴近物理世界，Linux 贴近用户与云端。
协同开发的核心难点不在于单独写好 MCU 或 Linux 程序，而在于定义清晰的职责边界与通信契约。谁负责采集、谁负责显示、谁负责决策、异常时如何降级，这些问题必须在架构阶段明确，否则后期会出现数据不一致、界面卡顿、控制延迟甚至系统死锁。
二、核心概念地图
本课程涉及的核心概念可以归纳为五组：
- 系统架构：双芯片架构、双核异构架构、主从关系、职责划分。
- 通信通道：UART、SPI、I2C、CAN、USB、以太网、共享内存、RPMSG 等。
- 协议设计：帧头、长度、命令字、载荷、校验、超时重传、心跳保活。
- UI 联动：Qt/LVGL 界面刷新、状态同步、事件上报、异步更新。
- 工程保障：日志、调试、版本管理、异常恢复、性能与实时性评估。
这些概念不是孤立知识点，而是围绕“数据如何从传感器到界面、从用户操作到执行器”这条主线展开。理解这条主线，就能把零散技术串成系统能力。
三、整体学习框架与章节主线
课程按照“先建认知、再通协议、后做联动、终成系统”的顺序推进，共 30 章，可划分为五个阶段：
| 阶段 | 主要内容 | 学习产出 |
|---|---|---|
| 认知与架构 | 协同模式、职责划分、硬件拓扑、开发环境 | 能画出系统框图并说明边界 |
| 通信与协议 | UART/SPI/CAN、帧格式、校验、心跳、重传 | 能设计并实现一套通信协议 |
| UI 联动 | Qt/LVGL 刷新、状态同步、事件上报、异步更新 | 能实现界面与 MCU 数据联动 |
| 工程与调试 | 日志、抓包、性能分析、异常恢复、OTA | 能定位协同问题并优化 |
| 综合实战 | 完整项目：采集—通信—显示—控制闭环 | 能独立交付协同系统 |
四、典型场景：从传感器到界面的闭环
以一台工业温控 HMI 为例：MCU 每 10ms 采集一次热电偶，运行 PID 控制加热丝，同时通过 UART 每 100ms 向 Linux 上报温度、设定值、输出占空比和故障码；Linux 上的 Qt 界面以 10Hz 刷新曲线和数值，用户修改设定值后，通过同一通道下发命令帧。若通信超时，MCU 进入本地安全控制，Linux 界面显示“通信异常”并禁止远程设定。
MCU 上报帧示例：
AA 55 0C 01 01 00 64 00 32 00 00 7B
| | | | | | | | |
帧头 长度 命令 状态 温度 设定 占空 校验
Linux 下发帧示例：
AA 55 08 02 01 00 50 6E
| | | | | |
帧头 长度 命令 设定值 校验这个场景说明：协同开发不是“把两个程序放在一起”，而是围绕数据流、控制流和异常流建立一套可验证的契约。
五、常见误区与复盘
误区二：只定义正常流程，不定义超时、丢包、重启后的状态恢复。
误区三：MCU 与 Linux 各自维护一份“状态”，导致界面显示与实际控制不一致。
误区四：用调试串口打印大量日志，干扰实时任务和通信带宽。
复盘建议：在项目启动阶段先输出三份文档——系统框图、通信协议表、异常处理清单。协议表至少包含字段、长度、取值范围、默认值和错误码；异常清单至少覆盖通信中断、数据越界、MCU 重启、Linux 界面崩溃四类情况。只有契约先行，后续开发才能并行推进而不失控。