嵌入式调试里最容易被忽略的几件小事

嵌入式开发有一个很真实的特点：问题经常不是出现在你以为最复杂的地方，而是出现在某个很基础、很容易被略过的环节。

有时候代码看起来没问题，现象就是不对。这个时候如果只盯着逻辑，很容易越调越乱。

先确认供电和连接

很多问题第一步就应该回到物理层。

板子有没有正常供电？电压稳不稳定？GND 有没有共地？线有没有接反？接口有没有松？这些问题听起来很低级，但它们真的会浪费很多时间。

我现在越来越觉得，调试时先把“硬件是否可信”确认一遍，是一种节省时间的习惯。

串口不是只用来看输出

串口调试很常见，但如果只是随便 printf，信息很快就会变成噪声。

更好的方式是让串口输出有层次：

• 启动时打印版本、模式和关键配置。
• 关键状态变化时打印状态名。
• 异常时打印错误码或上下文。
• 数据量大时控制频率，不要把通信本身拖慢。

日志不是越多越好，而是要让人能顺着它找到问题发生的位置。

保留复现路径

调试时最怕的是“刚才坏过，但现在不知道怎么坏的”。

所以遇到问题时，我会尽量记录几个东西：

• 当前接线方式。
• 当前固件版本。
• 操作步骤。
• 预期现象和实际现象。
• 改动了什么之后现象发生变化。

这些记录不一定要很正式，但至少要能让自己回头看懂。

不要急着同时改很多地方

嵌入式问题经常牵涉硬件、驱动、通信协议和应用逻辑。如果一次改太多地方，即使问题消失了，也很难知道真正起作用的是哪一处。

更稳的做法是一次只改一个变量，然后观察现象。

这听起来慢，但比反复猜快得多。

调试也是工程能力

很多时候，调试能力不是记住多少寄存器，也不是会不会某个工具，而是能不能把混乱现象拆成几个可验证的问题。

先确认电，再确认线，再确认协议，再确认代码。

一步一步来，问题通常就不会那么吓人。