第一讲：课程导论与调试思维建立
各位同学，欢迎来到这门实战课。在正式开始之前，我想先聊聊三个最根本的问题：为什么我们要搞分层架构？调试接口到底是个什么东西？故障定位有没有可循的法则？
这三个问题想通了，后面三十章你学起来会轻松很多。我自己带团队时发现，很多人写代码很快，但一出问题就抓瞎——说白了，就是没建立起正确的调试思维。
1.1 为什么需要分层架构？
先看一个场景。你写了一个STM32的I2C驱动，读写传感器。功能调通了，挺好。过了两周，产品经理说要加一个新传感器，也是I2C。你复制粘贴改一改，也能跑。但这时候Bug来了——两个传感器共用一条总线，时序冲突了。
你开始查代码。驱动层、应用层、中断处理全混在一个文件里。改一处，崩三处。我当年第一次做这种项目时，整整熬了两个通宵才把问题定位到——嗯，从那以后我再也不敢写“大泥球”代码了。
分层架构的核心价值就三点：
- 隔离变化：硬件换了，只改驱动层；业务逻辑变了，只改应用层。
- 可测试性：每一层都可以单独调试，不用等硬件就绪。
- 可复用：写好的UART驱动，换个项目直接拿过来用。
我建议的裸机分层模型是这样的：
应用层 → 业务逻辑、状态机、协议解析
服务层 → 任务调度、超时管理、数据缓存
驱动层 → 寄存器操作、外设初始化、中断处理
硬件层 → STM32芯片、外设寄存器映射
你想想看，如果每一层都有清晰的接口，调试时你只需要怀疑某一层出了问题。而不是像无头苍蝇一样到处翻代码。
1.2 调试接口的本质是什么？
很多人觉得调试接口就是SWD、JTAG这些硬件连接。其实不然。调试接口的本质是“观察点”和“控制点”。
- 观察点：你能看到什么？寄存器值、变量内容、执行轨迹。
- 控制点：你能干预什么？暂停执行、修改变量、强制跳转。
我见过一个同事，调试时只会用printf。串口打印一堆信息，然后盯着看。不是说printf不好，但它的观察粒度太粗了。你想想看，一个中断服务函数里，printf本身就会影响时序——这叫“观察者效应”。
在裸机环境下，我常用的调试接口手段有这些：
| 调试手段 | 观察能力 | 控制能力 | 对时序影响 |
|---|---|---|---|
| SWD/JTAG + IDE | 强（全寄存器、变量） | 强（断点、单步） | 极小（硬件级） |
| 串口printf | 中（只能看打印内容） | 无 | 大（阻塞） |
| GPIO翻转 | 弱（只有电平） | 无 | 极小 |
| ITM/SWO | 强（实时数据流） | 弱 | 小 |
| DMA+环形缓冲区 | 中（历史数据） | 无 | 极小 |
我的建议：调试接口不要只用一种。SWD用于断点调试，GPIO翻转用于时序测量，DMA缓冲区用于事后分析。三种手段配合使用，效果最好。
1.3 故障定位的黄金法则
做嵌入式这么多年，我总结了一套故障定位的方法论。不是什么高深理论，就是实战中摔出来的经验。
法则一：复现是第一步
不能复现的Bug，基本等于不存在。我遇到过最头疼的问题，是客户现场一周才出现一次。后来我加了触发条件记录，把复现率从5%提到了80%。
法则二：二分法缩小范围
别从头到尾读代码。先判断是硬件问题还是软件问题。如果是软件问题，再判断是驱动层还是应用层。一层层二分，定位速度是指数级的。
法则三：一次只改一个变量
这个我吃过亏。有一次同时改了三个地方，结果问题消失了。但不知道是哪个改动起的作用。后来问题复发，我完全不知道从何下手。嗯，从那以后我严格遵守“一次只改一个变量”。
法则四：用日志构建时间线
故障发生前发生了什么？中断顺序是什么？变量在哪个时刻被改写了？把这些信息串起来，故障原因往往就浮出水面了。
避坑指南：我曾经在调试一个DMA传输问题时，怀疑是缓冲区溢出。结果查了两天，最后发现是DMA配置的地址对齐有问题——STM32的DMA对某些外设有对齐要求。如果当时我先把DMA配置表打印出来看一眼，能省两天时间。
1.4 本章小结
这一讲我们建立了三个核心认知：
- 分层架构不是花架子，它是调试效率的基石。每一层职责清晰，问题范围自然缩小。
- 调试接口的本质是观察+控制。选对工具，事半功倍。
- 故障定位有法可循。复现、二分、单变量、时间线——这四个法则能解决90%的问题。