4.2 嵌入式系统开发

4.2 嵌入式系统开发

本节摘要：嵌入式开发是把处理器驯化成产品全部行为的全过程。本节沿"点灯 → 中断与外设 → 实时操作系统 → 低功耗 → 调试"的进阶路线走，每一步都配真实工程细节：串口驱动排查实录、RTOS 任务划分案例、深睡唤醒的电流账单。读完本节，你能理解固件工程师日常 80% 的工作与 90% 的坑。

场景开场：一块全班最简单的板子

嵌入式工程师的成人礼往往是一块只接了发光二极管的开发板，任务是让它按一秒的节拍闪烁。这件事在桌面程序里不值一提，在裸机上却要你亲手回答一连串问题：时钟树怎么配、引脚复用选哪个功能、延时靠空转还是定时器、看门狗要不要喂。而当灯终于闪起来，你已经事实上完成了一次与硬件的"建交"：建立了时钟、寄存器、中断的最小心智模型。本节从这个最小系统出发，把产品级固件的所有部件逐个装回去。

从轮询到中断：CPU 的两种活法

轮询是 CPU 不停地问外设"好了没"，简单但浪费且不及时。中断是外设主动举手，CPU 暂停主线去处理。一次完整的中断生命周期：外设置位标志 → 中断控制器判优先级 → CPU 在指令边界保存现场、跳转到服务程序 → 处理 → 恢复现场返回。响应延迟由三段构成：最长指令的执行时间、现场保存时间、更高优先级服务的占用时间——实时性预算就是这三段的和的最坏值。

中断服务程序有三条军规：尽量短（把耗时工作留给主循环或任务）、不可阻塞（别在里面等外设）、共享变量要防护（主流程与中断同时访问的变量必须原子或加临界区）。违反第三条是嵌入式最隐蔽的一类偶发故障。

// 主循环与中断共享一个环形队列：不加防护的版本藏着定时炸弹
volatile uint16_t head = 0, tail = 0;
uint8_t buf[256];

void UART_IRQHandler(void) {            // 串口每来一字节被调用一次
    buf[head++ & 0xFF] = UART->DR;      // head 是共享变量，非原子读改写
}

int main(void) {
    for (;;) {
        if (tail != head) {             // 读到的 head 可能是半更新状态
            process(buf[tail++ & 0xFF]);
        }
    }
}
​

在 8 位机上"加一"是读改写三步，若主循环恰在中间被打断，读到的 head 可能是旧值——偶发丢字节，复现概率百万分之一。修复办法是关中断读 head 快照，或干脆声明宽度不超过总线宽度的变量（读一次即完成）。这类"概率型故障"消耗的调试时间常占项目后期的三分之一，本节末尾的排查实录就是一例。

实时操作系统：当任务多到一个循环装不下

产品功能渐多——采样、通信、显示、按键、日志——主循环开始顾此失彼，这时引入 RTOS：把每件事做成独立任务，各自带优先级，内核按"最高优先级就绪任务先跑"调度。核心概念三个：

• 任务与优先级：响应快的任务优先级高（如通信收包高于界面刷新）；
• 信号量与互斥锁：任务间握手与共享资源上锁，注意优先级反转（高优任务等低优任务手里的锁），成熟内核提供优先级继承缓解；
• 队列与事件：数据与通知的"邮箱"，生产者消费者解耦的标准件。

任务划分的实践准则：按"事件源"划分而不是按"功能模块"划分，让每个任务阻塞在自己的事件上，CPU 占用率自然下降——这与工厂按产线而非按车间排班是同一个道理。

低功耗：电流的账本

电池产品的固件一半代码在为功耗服务。功耗状态从浅到深：运行、睡眠（时钟停外设活）、深睡（只留唤醒源与实时时钟）、关机。深睡电流可以做到微安级，但唤醒要毫秒级——每次深睡都是在用"恢复时间"买"电费"。实践手法：事件驱动（无事件即睡）、批处理（攒够一批再开射频发送，因为射频启动本身耗电）、外设按需开关、以及把 3.2 节的滤波算法降频执行。BLE 设备的纽扣电池能撑数年，靠的不是某个单点黑科技，而是把这本账算到了每一个时钟周期。

排查实录：一个串口偶发乱码

背景：产品量产前，客户现场报告串口日志偶发乱码，概率约万分之一，实验室难复现。排查：先换线缆与波特率排查物理层，无效；用逻辑分析仪长时抓取，发现出错帧的第一个字节总是紧跟在一次射频发送之后。根因：射频发送时电源电压瞬跌，串口接收引脚采样点漂移，恰好在位中间附近时误判。发送期间电源纹波耦合进信号地，加重抖动。修复：固件层——射频发送前暂停串口接收并清缓冲，发送后等电压稳定再恢复；硬件层——发送支路加去耦电容与磁珠隔离，并在布线上让串口走线远离射频功率路径（呼应 2.3 节的地纪律）。解读：这类故障的教科书名字叫"同步开关噪声"，它提醒我们嵌入式故障常是软硬件合谋：单看代码无错、单看电路达标，合起来才出事。变式：若不能停接收，可改用带校验的帧协议让乱码帧被丢弃重传，把故障从"脏数据"降级为"偶发重试"——通信协议的鲁棒性设计（第七章）是固件工程师的最后保险。

💡 关键直觉：嵌入式调试的黄金顺序是"先复现、再隔离、后归因"。工具箱按精度递进：日志、示波器、逻辑分析仪、跟踪单元。日志告诉你"何时"，仪器告诉你"线上发生了什么"，跟踪单元告诉你"CPU 到底执行了哪条分支"。

常见疑问两则

问：任务划分有没有简单可操作的检查标准？答：看三条：每个任务的阻塞事件是否单一（一个任务等多个事件说明该拆）；最高优先级任务的最坏执行时间是否短小可控（长任务会饿死紧急任务）；任务间共享资源是否最少（共享越多锁越多，死锁与优先级反转风险越大）。三条都过关，划分基本健康。

问：裸机一定比 RTOS 简单吗？答：功能少时是；功能多时恰恰相反。裸机主循环里塞进十个功能后，任何一处长操作都会拖累全部，时序耦合藏在代码角落；RTOS 把每个功能隔离成任务，耦合显式化为队列与信号量，可测可换。简单是分阶段的：项目早期裸机简单，规模上来后 RTOS 才是真简单。

本节要点回顾

• 中断三军规：短、不阻塞、共享防护，概率型故障多源于违反第三条；
• RTOS 按事件源划分任务，让每个任务阻塞在自己的事件上；
• 优先级反转用优先级继承缓解，锁的顺序要全项目约定；
• 功耗是一本账：深睡买电费、批处理省启动开销，账算到每个时钟周期；
• 偶发故障常是软硬件合谋，电源完整性与协议鲁棒性是两道保险。

固件让处理器有了行为，但有些算法再怎么优化也追不上信号的速度。下一节看最后的手段：用硬件描述语言，直接铸造 dedicate 的电路。