从零开始的嵌入式之旅 Day 6 & Day 7
前五天我基本都是在跟一块板子死磕：点灯、GPIO翻转、看时钟树、用手册翻寄存器。说实话，做到Day 5结束的时候，我最大的困惑不是"寄存器记不住"，而是——我怎么知道我的MCU到底在干什么？点灯亮了说明输出没问题，但程序内部跑到哪一行、变量是不是符合预期、外设状态对不对，全靠猜。所以在Day 6和Day 7，我做了两件让学习曲线陡变的事情：把串口调试通道打通，以及把按键中断这门"基本功中的基本功"彻底搞明白。这篇文章就把这两天的完整过程和踩坑记录写下来，给同样从零开始学嵌入式的人做个参照。你会遇到什么、该注意什么、为什么很多教程里一句带过的东西才是真正卡人的点，这里都讲清楚。
1. Day 6 主线：打通串口，让MCU开口说话
1.1 为什么第一个认真学的外设必须是串口
很多入门教程会把串口放在LED之后、I2C之前来讲，但我自己体会下来，串口根本不是"一个外设"这么简单，它是我这一整天所有调试手段的基础。有了串口，代码里随便print几行变量值、寄存器状态，比对着调试器一步步断点快太多。尤其嵌入式开发里"现象和原因隔得很远"的问题，比如某个模块不工作，你最先要确认的往往是"程序到底有没有走到这里"。串口就是最便宜、最直观的那根探针。
而且串口的应用场景覆盖极广：设备日志输出、AT指令交互、与PC端上位机通信、板间通信，几乎每个嵌入式项目都会用。花一整天把它吃透，后面全都是回报。
1.2 硬件接线：三根线搞定
串口通信在MCU和PC之间需要一根USB转TTL工具，这是最常见的调试配件。接线只有三根：TXD、RXD、GND。
- MCU的TX -> 工具的RX
- MCU的RX -> 工具的TX
- MCU的GND -> 工具的GND
这里有个新手最容易犯的认知误区：这两根数据线是交叉接的，不是同名直连。原因很简单，A设备的发送脚必须接到B设备的接收脚，数据才能流过去。如果同名接同名，那就变成了互相往自己的接收脚送数据，永远收不到。
交叉这件事我第一次接的时候反复确认了三遍才动手，因为接错不会烧东西，但会让你怀疑人生——程序明明没问题，终端就是一丝反应都没有。
1.3 串口参数怎么设：8-N-1和波特率从哪里来
一串"115200 8-N-1"到底是什么意思？
- 115200：波特率，每秒传输的二进制位数量
- 8：数据位，一个字节8位有效数据
- N：无校验位
- 1：1位停止位
刚开始我照着"115200 8-N-1"配置，以为这就完事了。真正深入了解之后才发现，最关键的其实是波特率是怎么算出来的。MCU内部有一个波特率寄存器（USARTDIV），它把外设时钟分频得到每个bit的时间。公式是：
波特率 = 外设时钟 /（16 × USARTDIV）
比如我的板子APB2外设时钟是72MHz，目标波特率115200，那USARTDIV算出来是39.06左右，取整到带小数位的寄存器值后，实际波特率和理论值会有零点几个百分比的偏差。这个偏差在短帧传输下毫无影响，但如果你以后做长帧或对时序敏感的应用，就必须回头认真算这个分频。
我建议至少在理论层面走一遍这个计算过程，不要只是点个自动配置就完事。嵌入式开发里"知道配置工具帮你做了什么"和"只会点按钮"的差距，会在你遇到诡异bug时直接决定能不能解决。
1.4 回环测试：验证链路的最快方法
参数配好之后，别急着烧复杂的发送代码。先做一个回环测试：
uint8_t rx_buf; while (1) { if (HAL_UART_Receive(&huart, &rx_buf, 1, 100) == HAL_OK) { HAL_UART_Transmit(&huart, &rx_buf, 1, 100); } }这段代码的意思很简单：从串口接收一个字节，再把同一个字节发回去。实际测试时，用一根杜邦线把MCU板上的TX和RX直接短接，然后在PC的串口终端里手动发送任意字符。如果终端里能回显出你刚敲进去的那个字符，就说明MCU的串口模块本身收发正常；如果没反应，问题一定出在接线、参数、或者代码配置上，跟电脑上的软件关系不大。
回环测试是我整个Day 6里做得最值的一件事。它把所有变量拆出来了：我不用考虑USB转TTL工具的收发方向，不需要猜电脑串口软件有没有配错，只需要验证MCU自己能不能在一个环里搞定收发。能搞定，硬件链路就是通的。
2. Day 6 踩坑实录：从"没反应"到"乱码"的完整排查链路
2.1 现象一：串口终端完全没反应，像在跟空气说话
回环测试都没通过的时候，我的排查顺序是：
- 检查GND共地。USB转TTL工具和MCU板子要插同一个GND，这是最常见也最容易被忽略的问题。很多独立供电的模块，如果不共地，电平参考点都不一样，数据信号根本没法被正确解析。
- 检查TX/RX有没有接反。这一步建议灯板上的丝印和工具上的丝印，逐字确认。我当时一度以为板子丝印标反了，后来发现是我自己把工具侧的TXD误认为也要接板子的TXD。
- 检查代码里串口初始化有没有真的执行。比如初始化函数被放在某个条件判断里，或者时钟开关没使能，外设根本没上电。
一个很实用的技巧是：用万用表量TXD引脚的静态电平。空闲状态下，UART引脚应该维持在3.3V或5V的高电平。如果量出来是0V或者跳变，基本可以确定配置有问题。
这一步排查，我花掉了整个上午。当时最大的教训是：不要凭感觉跳过最基本的三条线检查，直接怀疑代码。第一次做的时候，我检查代码至少花了四十分钟，最后发现只是工具上一根杜邦线松了。
2.2 现象二：有数据进来，但全是乱码
回环测试过了，可是一接上电脑串口终端，收到的内容就是一团乱码。这种情况十有八九是波特率对不上。
嵌入式里波特率不匹配，最常见的原因是：外设时钟变了，但分频值没跟着变。比如很多代码生成工具默认把APB1和APB2的分频配成某组值，串口挂在哪个总线上，就决定它的时钟源是多少。我之前只记了波特率寄存器里填的值，却没注意到时钟树已经被初始化代码改过。后来每次初始化外设，我都强迫自己先确认这个外设挂在哪条总线、当前总线时钟到底是多少，再去看波特率分频。
另外几个乱码原因也要排查：
- 连了错误的串口号，比如工具枚举出了两个COM口，其中一个是蓝牙或调试口
- 串口助手的参数跟代码不一致，比如代码里没有校验位，助手却选了奇校验
- 发送方和接收方的参考电平不匹配，比如5V逻辑的信号接到3.3V的RX脚，虽然多数时候能读，但波形边沿质量差，传输距离长了就会错
2.3 现象三：printf输出重定向到串口，结果程序跑飞
打通串口之后，所有人都会干同一件事：让printf输出到串口。这个操作的本质是重定向C标准库的printf函数到底层串口发送接口。
我的做法是重写fputc函数，把输出字符送到串口寄存器：
int fputc(int ch, FILE *f) { huart.Instance->TDR = (uint8_t)ch; while ((huart.Instance->ISR & USART_ISR_TXE) == 0); return ch; }这里踩过一个特别典型的坑：默认的C标准库会依赖一个叫"半主机模式"的机制来实现printf，而半主机模式要求调试器在线连接。裸机开发时调试器没连着，程序一执行到printf相关代码就卡死，看起来就像是程序跑飞了。
解决方式是在工程配置里关闭半主机模式，同时确保自己重写的底层发送函数足够轻量、不依赖任何操作系统调用。这一步做完，printf输出才真正稳定下来。
提示：如果程序里同时存在调试器断点调试和串口printf，尽量让printf只在调试阶段使用。正式版固件里保留大量轮询式串口输出，会拖慢主循环时，这一点到了做实时控制的阶段你就会深有体会。
2.4 Day 6 的收尾：给调试建立"可视化"意识
Day 6结束时，我做了个小总结：真正让这次串口调试变得容易的，不是多高的代码水平，而是把"我看不见的东西变成能看见的东西"。
串口就是一个起点。后来又延伸出两个小工具体验，非常值得推荐：
- 逻辑分析仪。国产的十几块钱的8通道玩具级设备就够用，抓串口波形、I2C时序、PWM占空比，属于低价高回报。
- 波特率自动识别功能。很多串口助手有自动识别波特率，虽然不能作为正式手段，但拿来排除波特率配置问题非常方便。
嵌入式这行，一半时间在写代码，另一半时间在做"刑侦"。建立起"先看到现象、再推断原因"的工作习惯，比多看十篇教程都管用。
3. Day 7 主线：从轮询到中断，按键交互的进阶
3.1 为什么Day 7一定要学中断
继续灯和串口之后，下一个顺理成章的目标是按键输入。很多人会想：按键不就是读一个GPIO引脚电平吗？循环里轮询一下不就行了？
确实，轮询可以解决"检测到按键按下"这个表层需求。但一旦你开始思考真实场景，轮询的缺点立刻暴露：
- 按下按键的时间可能只有几毫秒到几十毫秒，主循环如果忙于执行其他耗时任务，就会错过检测窗口
- 多个按键同时需要响应时，轮询逻辑会越来越复杂
- CPU在轮询期间啥也干不了，纯浪费
中断的意义在于让MCU在事件发生的瞬间自动打断当前流程，跳到专门的处理函数里执行对应逻辑，执行完再回到之前被打断的地方。这就好比你在写报告，电话铃响了就放下笔去接，接完再接着写，而不是每秒钟都扭头看一眼手机有没有来电话。
按键虽然只是个廉价外设，但它背后连接的是一整套中断机制的核心理念。核心理念通了，后面移植到定时器中断、串口接收中断、DMA中断就只剩细节问题。
3.2 按键硬件怎么接：上拉下拉和有效电平
绝大多数开发板上的按键设计都很简单：一端接GND，另一端接某个GPIO引脚，GPIO内部使能上拉电阻。这样按键默认状态是高电平，按下时被拉低，程序检测到引脚从高变低，就认为有按键按下。
这种"平时高、按下低"的连接方式叫低电平有效。为什么普遍用低电平有效？因为主控的GPIO驱动灌电流的能力通常比输出电流能力更好，按键直接接地实现起来最简单，也不容易受干扰。
另外按键一脚悬空的时候，引脚电平是不确定的，必须依靠内部上拉或下拉电阻把电平钳住。没有这个电阻，你会看到引脚电平在高低之间随机跳变，程序检测到一堆"幽灵按键"。
3.3 用代码生成工具配置EXTI中断的完整流程
Day 7的重头戏是配置外部中断。我用的芯片主流开发板上，外部中断缩写是EXTI，全称外部中断/事件控制器。配置步骤可以拆成这样：
- 在代码生成工具里把按键对应的GPIO引脚设置为输入模式，使能内部上拉
- 把该引脚映射到EXTI中断线，并设置触发方式为下降沿触发（高电平变成低电平时触发）
- 使能NVIC（嵌套向量中断控制器）中该中断线的全局中断通道
- 在启动代码自动生成的HAL库中断回调函数里写自己的处理逻辑
第2步的"下降沿触发"值得多说两句。什么情况下你会需要上升沿触发？按键释放的瞬间要识别的话就选上升沿。但实际项目中，大多数是按下动作触发一次处理，所以下降沿就够了。而边沿触发和电平触发的区别是：边沿是在跳变的瞬间进一次中断，电平触发是只要保持低电平就一直进中断。按键处理用边沿触发，避免重复响应。
配置完成之后，中断初始化部分会自动生成，我只需要补上回调函数：
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin == KEY_Pin) { key_flag = 1; } }这个回调函数会在按键引脚检测到下降沿时被调用。我在这里只做一件事：置一个标志位。至于这个标志位后续怎么用，那是主循环的事。
3.4 中断处理函数里绝对不能做的事
关于中断服务函数，技术社区里流传着一句话：中断里别做任何耗时的事。这句话我用Day 7的亲身经历验证了浓度。
一开始我没忍住，想在中断回调里直接翻转一个LED、做延时、甚至往串口打印调试信息。结果发现：
- 中断里做延时，会让中断处理时间拉长，其他中断无法及时响应
- 中断里调用串口发送的轮询等待，如果波特率低，一次发送就要消耗几百微秒
- 中断里执行复杂运算，会让主循环卡顿，整个系统观感就是"卡卡的"
正确的做法是：中断回调只标记事件、保存数据、设置标志位，真正具体的业务逻辑放到主循环去处理。这本质上是"生产者和消费者"模型：中断是生产者，只负责产生事件；主循环是消费者，负责消化事件。
4. Day 7 实测：中断不触发、按键抖动、共享变量的三个坑
4.1 坑一：中断回调写好了，但代码就是跳不进去
第一次写EXTI中断，烧完程序按了好几下按键，回调函数里的标志位一点变化都没有。我用调试器断在回调里，根本进不来。
检查了一圈，根因有两个：
第一个是NVIC对应的全局中断没使能。代码生成工具里有一个独立的开关，如果只在GPIO层面配了EXTI线，却忘了打开NVIC的中断通道，事件信号根本进不了CPU。这个点很容易被忽略，因为普通的GPIO读写根本不需要NVIC参与。
第二个是触发方式选择错误。我一开始想当然地看着"按键默认高电平"选了上升沿触发，逻辑上自洽，但把"按下之后变化的方向"和"引脚的绝对电平"搞混了。从高到低的跳变是下降沿，不是上升沿。这点看手册看了半天才反应过来。
提示：调用回调函数的时候，最好在回调入口先判断GPIO_Pin是不是你关心的那根引脚。一颗芯片可能有多路EXTI共用一个回调函数，不判断引脚来源，就会发生"按了A键结果B键的逻辑被触发"这种错乱。
4.2 坑二：机械按键抖动带来的"按一下等于按十下"
好不容易把中断跑通了，我又发现一个新现象：每次按下按键，调试器里变量的值都跳了好几下。这就是经典的按键抖动问题。
机械按键内部是金属片接触，按下和释放的瞬间，金属片并不是瞬间稳定的，会有几毫秒到十几毫秒的反复弹跳。这个弹跳反映到电平波形上，就是一段密集的高低横跳。如果每个下降沿都触发中断，MCU自然会把"一次按压"识别成多次。
解决抖动的思路有三种，我按从低到高的层次记录一下：
- 硬件消抖：在按键两端并联一个小电容，吸收高频跳变。最省事，但如果按键接的是长线，电容选不好会影响边沿速度
- 延时消抖：检测到按下之后，等10-20ms再确认电平。简单，但前面说过，中断里不能延时，这个方案更适合放在主循环里做
- 定时扫描消抖：每隔5-10ms读一次引脚，连续多次读到同一状态，才确认按键状态变化。这个方案不阻塞主循环，也是行业里最常见的做法
我最终采用的是第三种思路，把消抖和按键状态检测都挪到主循环里做。中断只负责产生"按下事件"的提醒，主循环在收到提醒后，用定时扫描确认按键状态是否真的稳定。
4.3 坑三：主循环读取按键标志位，变量莫名奇妙"不更新"
消抖处理完，我以为这一天可以顺利收工了。结果遇到一个诡异的C语言诡异问题：主循环里读key_flag这个全局变量，有时候读出来的值不是模拟量，仿佛中断里写进去的值被"吞"掉了。
这个问题的根源是编译器的优化。在默认优化等级下，编译器可能把这个变量的值先加载到CPU寄存器里反复使用，而不重新从内存读取。对于普通变量，这种行为没问题；可一旦变量的值由中断改变，编译器并不知情，主循环读到的自然就是过期的缓存。
解决办法是在变量声明时加上volatile关键字：
volatile uint8_t key_flag = 0;volatile的含义是告诉编译器："这个变量的值可能在程序流程之外被改变，每次使用都要老老实实从内存里重新读。" 这在所有中断与主循环共享数据的场景里都是必要的。
但要把话也说清楚：volatile能保证读取的即时性，却不能保证操作的原子性。在Cortex-M这类32位MCU上，读写一个8位或32位变量一般是单条指令，天然原子。但如果你在中断里对变量做复合操作，比如自增又判断，就需要临时关中断或者用更好的同步方式。这一块到了Day 10往后学实时操作系统时还会再遇到。
4.4 两个嵌入式新手最容易忽略的细节
Day 7下午，我把这两个细节写进了自己的学习笔记，觉得它们比按键本身更值得记：
第一个是"中断和主循环谁先跑"的问题。上电之后，NVIC和EXTI的初始化顺序必须保证：GPIO时钟先开，EXTI线先配好，NVIC使能在最后。顺序搞反，中断可能在初始化到一半的时候触发，导致处理函数面对一堆半配置的外设。
第二个是"中断优先级分组"的问题。现代MCU的中断控制器支持多级抢占优先级，但如果配置不当，低优先级的中断可能永远抢不了高优先级的中断，或者反过来，高优先级中断把低优先级中断卡死。当时我把按键中断的抢占优先级配置得和系统滴答定时器中断一样，结果按键长时间按住时，系统时钟的节拍被频繁打断。后来把不同中断的优先级区分开，整个系统才稳定下来。
5. 从Day 6到Day 7，我对嵌入式学习的几个新认识
5.1 学习主线要从"按章节学"改成"按需求学"
这两天的经历让我彻底改变了一个观念：嵌入式学习不是把手册从头翻到尾，而是带着一个明确的目标，把沿途需要的东西一个一个捞上来。
串口是我为了"看见程序内部状态"才学的；中断是我为了"让按键响应不再阻塞"才学的。每一个知识点都有清晰的需求背景，学起来完全不觉得枯燥，记起来也比死记硬背寄存器靠谱得多。如果你也在入门，我的建议是给自己找一条像"按键控制LED并用串口上报状态"这样的完整小链路，然后顺着链路把每个环节吃透。
5.2 养成"问题先怪自己"的调试心态
Day 6和Day 7集中踩了一整天的坑，我的情绪经历了从烦躁到平静的转变。后来发现，嵌入式系统里大多数问题不是你有多笨，而是有某个环节被想当然地跳过了。
现在我排查问题，默认按这个顺序来：
- 硬件链路：线接对了吗？共地了吗？
- 时钟和初始化顺序：外设真的被使能了吗？
- 代码逻辑：条件分支真的会执行到我怀疑的那行吗？
- 工具链问题：编译优化、半主机、调试器配置，这些"环境问题"永远是最后背锅的
这个排查顺序已经帮我在后面Day 8、Day 9的ADC和PWM调试里省了大量时间。
5.3 给同样从零开始的人几点实操建议
最后说几个我从这两天里沉淀下来、直接就能用的小建议，希望能帮你少走弯路：
- 日志输出要克制。调试阶段printf随便写，但正式跑起来前，把所有调试输出关掉或统一走一个日志开关，否则后面排查问题的时候，日志本身就是噪音
- 按键状态要多画时序图。实测抖动波形会让你直观理解硬件行为，别只靠眼睛看代码逻辑来推断
- 中断服务函数越短越好。哪怕只是设置标志位，也要保证设置操作本身不会被打断
- 每次只改一个变量。我在这两天最惨烈的几次debug，都是因为同时调整了多处代码，出问题时根本无法定位来源。把改动拆小，每个改动测一轮，反而更快
这两天的内容量看起来不大，但串口和中断这两块是几乎所有嵌入式项目的基石：串口是调试的窗口，中断是实时响应的底座。把这两样基础打牢，后面无论是接传感器、跑屏幕、做电机控制，都会顺得多。
