Question 1

中断服务程序里该做什么、不该做什么？

Accepted Answer

我的原则是 ISR 越短越好，只做三件事：把硬件数据搬走、置一个待处理标志或往环形缓冲写一笔、清中断标志。不能做的很明确：阻塞等待、长循环、malloc、printf、拿可能被其他任务持有的锁——这些会拉长中断延迟，影响更高优先级中断，printf 还常常直接串成死锁。真正的处理放到主循环或 RTOS 任务里做，交接方式我优先用单生产者单消费者的无锁环形缓冲，只在缓冲区满时按需求选丢新、丢旧或计数上报。共享变量必须加 volatile，多字节共享结构要保证原子性或用双缓冲交换指针。我还会关注嵌套与优先级配置，避免低优先级中断长时间屏蔽高优先级。调试上我习惯给关键 ISR 加执行时间统计（进出翻转一个 GPIO 用示波器看），因为「ISR 很短」这句话在没测量前不可信。

Question 2

volatile 解决什么问题？它够不够？

Accepted Answer

volatile 解决的是编译器层面的问题：告诉编译器这个变量可能被中断、DMA 或另一个执行流改变，每次访问都必须真的读写内存，不能缓存到寄存器、不能优化掉循环里的重复读。典型场景是等待硬件状态位和 ISR 与主循环共享的标志。但它有三个不解决的问题。第一是原子性：32 位平台上对 64 位变量或多字节结构的读写可能被中断打断，读到半旧半新，需要临界区（短暂关中断）、原子类型或双缓冲。第二是复合操作：flag++ 是读-改-写三步，volatile 不会让它变原子。第三是内存序与硬件可见性：多核或带写缓冲、cache 的平台上需要内存屏障，DMA 场景还要处理 cache 一致性——发送前 clean、接收后 invalidate，否则数据看起来「没更新」。我的实践是：硬件寄存器和单字节标志用 volatile；跨执行流的复合状态用原子操作或临界区；DMA 缓冲区严格做 cache 维护并按对齐要求分配。

Question 3

RTOS 里任务怎么划分？优先级反转怎么处理？

Accepted Answer

我按时间约束划分任务，而不是按代码模块。先列出所有周期性和事件性工作及其截止期：控制环 1ms、通信协议解析 10ms、界面刷新 50ms、日志与上云可延迟，然后合并同周期同性质的工作，尽量少开任务——每个任务都要付栈空间和上下文切换代价。优先级严格按截止期紧迫程度排，硬实时最高，能延迟的最低；任务之间只通过队列和信号量通信，不共享可变全局状态。优先级反转的处理是标准的：共享资源用支持优先级继承的互斥量，而不是二值信号量；同时缩短临界区，尽量把共享资源改造成由单一任务拥有、其他任务通过消息请求，从结构上消除竞争。防饥饿我会避免高优先级任务纯轮询忙等，都改成阻塞在队列或事件上。上线前必测两件事：各任务栈高水位（跑压力场景后看剩余余量）和最坏情况下的响应延迟。

Question 4

内存只有几十 KB，你怎么设计内存使用？栈溢出怎么发现？

Accepted Answer

我的策略是让内存占用在编译期可预测。运行期不用 malloc——需要变长的场景用固定大小的内存池或环形缓冲，容量按最坏并发算清楚，满了走明确的降级策略而不是分配失败崩溃。大缓冲区静态分配并放到合适的段，DMA 缓冲注意对齐和 cache 行边界。栈的估算我按最坏调用路径来：最深的调用链加上中断嵌套的开销，不用大数组做局部变量，递归一律禁止或改成显式循环加显式栈。发现溢出靠三层手段：一是 RTOS 的栈高水位统计，跑完全场景压力测试后看每个任务剩多少余量，余量太小就调；二是栈末尾放金丝雀值定期校验，被改写立即上报；三是有 MPU 的平台把栈底设成不可写区域，溢出立刻硬件异常，配合把异常现场（PC、LR、任务名）写入非易失区，重启后能读出来定位。另外编译期我会看 map 文件核对 RAM 占用趋势，把它纳入版本对比，避免内存悄悄涨到临界。

Question 5

电池设备要跑一年，你怎么做低功耗设计？

Accepted Answer

我从功耗预算开始，而不是从改代码开始。先按电池容量和目标寿命倒推允许的平均电流，然后列各状态电流和时间占比：深睡几微安、唤醒处理几毫安、无线发送可能几十毫安但只占毫秒级。算完通常发现瓶颈不在 MCU 主频，而在唤醒频率、通信次数和某个忘记关的外设。优化路径按贡献排序：拉长采样与上报周期、多笔数据聚合后一次发送、事件触发替代轮询（用外设中断或比较器唤醒而不是定时器频繁醒）、休眠时把不用的外设时钟和电源域关掉、GPIO 配置成不产生漏电流的状态、传感器用自身的中断门限而不是 MCU 定时读。软件上保证唤醒后的处理路径尽可能短，避免醒着做日志和浮点运算。最关键的是实测：用电流表或功率分析仪抓完整周期的电流曲线，逐段对上预算，我遇到过多次「代码看着没问题但某个引脚上拉一直在耗几十微安」的情况，只有实测能发现。最后按真实曲线重算寿命，并做温度与电池老化的余量。

Question 6

I2C/SPI/UART 通信调不通，你的排查顺序是什么？

Accepted Answer

我从物理层往上查，因为改代码最容易但命中率最低。第一步接逻辑分析仪看总线上到底有没有波形：完全没有就是引脚复用、时钟未使能或供电问题；有波形但电平不对就是上拉电阻或电平不匹配。第二步核对协议参数：I2C 看从机地址是否含读写位搞错、上拉阻值与总线电容匹配不上导致上升沿太慢、有没有 ACK；SPI 看时钟极性相位模式、片选时序、位序和分频是否超出从机上限；UART 看波特率误差、停止位与校验、以及双方地线是否共地。第三步才是软件：初始化顺序、等待标志是否死等、DMA 与中断配置、有没有在 ISR 里做长操作导致丢帧。我的经验是最常见的三个原因是从机地址或模式配错、上拉/共地问题、以及初始化顺序不对（比如时钟没使能就配寄存器）。定位后我会保留一份抓包截图作为「已知正确波形」基线，后续同类问题直接对照。

Question 7

固件 OTA 升级怎么设计，才能保证升级失败不变砖？

Accepted Answer

核心是永远不要原地覆盖正在运行的固件。我用双分区方案：新固件写入备用分区，写完先校验哈希和签名，通过后原子性地更新一个带校验的启动标记，bootloader 启动时按标记选分区，并再次校验镜像完整性，不通过就回退到旧分区。断电安全靠两点：写入过程中的任何断电只影响备用分区，启动标记的更新必须是单次原子写（或用双份标记加序号与 CRC 互为备份）。签名校验防止非法固件，版本号做防回滚检查避免被降级到有漏洞的老版本。最关键的是首次启动确认：新固件跑起来后要在限定时间内自检通过并主动写入「确认成功」，否则 bootloader 在下次启动或看门狗复位后判定失败并自动回滚——这一步能挡住「能启动但功能坏了」这类最危险的情况。传输上支持断点续传和分片校验，避免弱网反复从头下。上线策略我按灰度批次推进，先小比例设备升级，观察确认率与回滚率再放量，同时保留有线恢复通道作为最后兜底。

Question 8

有个几天才复现一次的死机问题，你怎么定位？

Accepted Answer

低频问题的第一要务是把现场留下来，否则每次复现都白费。我先补可观测性：HardFault 与看门狗复位时把 PC、LR、栈回溯、当前任务名、复位原因寄存器写入非易失区（Flash 末页或 RTC 备份寄存器），重启后上报；同时记录一圈环形日志（任务切换、关键状态、外设错误计数），保证死机前的几百条事件能读回来。然后按嫌疑分类排查：内存类看栈高水位与金丝雀、开 MPU 抓越界；并发类看有没有中断与任务共享未保护状态、临界区是否漏了、队列满时的处理；外设类看是否死等某个标志（所有等待都要加超时并计数上报）；电源与硬件类看复位原因分布、电压跌落、温度相关性。同时用压力放大提高复现率：加大通信速率与并发、极端温度与掉电测试、把定时任务频率提高数倍跑长稳，并让多台设备并行跑（十台跑一周等于一台跑两个多月）。定位到之后我一定补一条机制：把这类等待改成带超时、把共享状态改成消息传递，或者把断言与异常上报常态化，避免同类问题再次只能靠等。

嵌入式工程师高频面试题：8 道必考题与作答要点