企业官网建设流程全解析

搞嵌入式开发这么多年，手上用过的MCU不算少，但STM32绝对是我项目中出场率最高的一个。从最初点亮一颗LED，到后来做伺服电机485控制、两轮差速小车、USB虚拟串口，再到给鱼缸加自动喂食和温控功能，可以说每一个项目都是从调试器的报错声里爬出来的。这篇东西不是官方手册的复读，而是这些年我在STM32开发调试过程中实打实踩过的坑，以及对应的排查思路和解决方案。无论你是刚装好Keil准备新建第一个工程，还是被莫名其妙的硬件错误卡了三天，这篇内容应该都能帮你省下一些时间。

1. 环境与工具链：还没写代码就卡住的那些事

很多新手以为写代码是最难的，实际上我从接触到的初学者反馈来看，光是把开发环境跑起来、让板子能下载程序，就已经劝退了一批人。工具链的问题看起来琐碎，但每一个都足够让你怀疑人生。

1.1 Keil5装芯片包这件事，看着简单坑不少

热词里老有人问“Keil5兼容C51和STM32安装”，大概率是只装了一个版本，然后发现另一个系列的芯片用不了。Keil5和Keil4最大的区别就在这：Keil5把芯片支持拆成了独立的Pack包，你不装对应芯片包，新建工程时Device列表里就是空的。想同时开发51和STM32，要么用同一个Keil5分别装C51和ARM的包，要么干脆装两个不同目录的版本，各用各的。

装芯片包还有一个常见问题：从Pack Installer里下载极慢，甚至直接失败。我第一次装STM32F1系列的DFP时，进度条半天不动，后来才知道可以到Keil官网手动下载离线Pack包，双击安装就行。具体来说，打开Pack Installer左上角的File菜单里的Import，选中离线包就能装上。如果你在公司内网或者网络环境不好，这个方案几乎是必杀技。

还有个细节，装完Pack之后如果芯片列表里还是找不到，先确认一下Pack安装器右下角的状态栏是不是显示安装成功。有时候你双击Pack时弹出了杀毒软件的拦截提示，实际组件没装上，Keil也不给你明确报错，就是找不到芯片。这个时候把杀毒软件放行、重新装一遍Pack就好。

关于ST-Link驱动，热词里单独列了“stm32 st-link utility”。我的建议是常备一个ST-Link Utility，它不仅能烧录，还能读回Flash内容、查看Option Bytes。有一次程序把SWD引脚禁用了，Keil死活连不上芯片，最后就是用ST-Link Utility在连接时按住复位、在芯片启动瞬间擦除Flash救回来的。这个工具集成在ST官方的工具包中，安装驱动后单独下载即可，遇到“No target connected”时它就是救命的。

1.2 下载报错：经典的Flash Download failed

这个报错大概是所有STM32开发者的第一道坎。热词里有人贴出完整的报错日志：load "d:\\stm32 prohect\\2-1 stm32工程模板\\objects\\project.axf" error: fla，后半句通常接的是Flash Download failed - "Cortex-M3"。

我第一次遇到这个报错时，把板子翻来覆去检查了半天，后来才理清头绪。这个报错的原因基本集中在三块：第一，Flash算法没选对或没选全。在Keil的魔术棒里打开Utilities设置，点击Settings进入Flash Download页面，必须确保Programming Algorithm里有对应你芯片型号的算法，并且勾选了Reset and Run。比如你是STM32F103C8T6，Flash容量是64KB，那就别选一个F103ZE的算法硬往上套，地址范围对不上必然失败。第二，芯片型号选错了，Device里选了F107的型号，但实际板子是F103，Flash地址映射有差异，同样会出这个错。第三，硬件问题，最常见的就是复位电路异常或者供电不稳，下载时芯片无法正常进入编程模式。

排查顺序建议这样：先看芯片选型对不对，再看Flash算法有没有选对，都排除了之后再怀疑硬件。我自己有一次折腾了半下午，最后发现是杜邦线虚接，ST-Link的SWDIO线松了。以后凡是下载报错，我先拿万用表量一遍ST-Link的四根线（3.3V、GND、SWDIO、SWCLK），再谈其他。

还有一个容易被忽略的点，Keil版本和Pack版本不匹配。如果你用Keil 5.23这种老版本去加载很新的Pack包，虽然能装上，但下载时可能出现各种诡异报错。建议保持Keil版本在5.30以上，虽然界面不太变化，但背后对CMSIS和DAP的支持完善很多。

1.3 芯片被锁死：不小心禁用了调试引脚

热词里有个“stm32禁用jtag”，这可是个经典的坑。STM32的PA13、PA14、PA15和PB3、PB4在默认情况下是SWD/JTAG调试引脚，但很多人用的是小封装芯片，引脚资源紧张，就会想着把这几个引脚当普通IO用。在用标准库或者HAL库配置GPIO时，只要把AFIO的调试功能关掉，比如做完GPIO_PinRemapConfig(GPIO_Remap_SWJ_Disable, ENABLE)，程序一烧进去，下次Debugger就再也连不上芯片了。不是芯片坏了，是它的调试接口被你亲手关了。

解决方式我在前面也提过，最有效的是用ST-Link Utility，在芯片上电复位的瞬间点Connect，趁程序还没跑起来（或者跑起来还没来得及禁引脚之前）先把Flash擦了。原理是连接时芯片的调试接口被ROM里的bootloader短暂启用，只要抢在这个窗口期内发出擦除命令就行。实际操作中，按住板子复位键，然后点Connect，松开复位键，多试几次总能成功。还有一种物理方法，把BOOT0引脚拉高，让芯片从系统存储器启动，跳过用户程序，这样调试接口就不会被用户代码禁用，可以正常连接擦除。两种情况都适用这个办法，但BOOT0需要焊锡操作，不如抢复位来得快。

避坑建议：除非万不得已，不要把SWD引脚全部禁用，至少保留SWDIO和SWCLK。留两个引脚总比掉进变砖的坑里强。如果你真的需要那四个引脚做IO，在产品量产固件里可以关闭，但在开发调试阶段千万别这么干，老老实实等最后一版再改。

2. 工程模板与基础配置：新建工程每一步都是坑

环境搞定之后，接下来是工程模板。很多新手在“新建工程”这一步就心态爆炸，库文件路径不对、头文件找不到、启动文件选错，随便一个都够喝一壶。这一部分我把常见的问题梳理一遍。

2.1 标准库还是HAL库，怎么选

热词里专门有一问“stm32库函数和标准库有什么区别”，这几乎是每个入门者必问的。简单讲，标准库（Standard Peripheral Library）是把寄存器操作封装成函数，比如GPIO_SetBits、TIM_Cmd。它更贴近底层，执行效率高，代码透明，但外设多的时候写起来很啰嗦，而且ST早就停止维护了。HAL库是ST力推的新一代库，抽象层次更高，很多外设只需要两三句初始化调用，配合CubeMX图形化配置特别省事。

从学习角度，我建议新手先摸一遍标准库，至少要知道寄存器的大致工作原理，然后再切HAL库。为什么？因为标准库的代码里你能直接看到寄存器位的操作逻辑，比如配置一个定时器PWM输出，你能清楚看到ARR、PSC、CCR这些寄存器怎么赋值。这个基本功打扎实了，后面遇到任何诡异问题都能往寄存器层面去想。HAL库封得太严，出问题的时候你连它帮你做了什么都不知道，排查起来会很吃力。

但做实际项目，尤其是牵扯到USB、以太网、SD卡这类复杂外设时，HAL库的优势非常明显，CubeMX生成的初始化代码开箱即用，省去大量翻阅参考手册的时间。我自己现在的习惯是：学习用标准库，项目原型用HAL库，如果性能瓶颈明显再回到底层去优化关键路径。

不管用哪个库，新建工程的核心步骤都差不多。用标准库建工程时，必须把以下文件放对位置：启动文件startup_stm32f10x_hd.s、系统文件system_stm32f10x.c、内核头文件core_cm3.h、外设库的stm32f10x_conf.h和stm32f10x_it.c。新手最容易犯的错是把启动文件选错，F103系列根据容量密度不同，有ld、md、hd、xl几种启动文件，选错了芯片可能跑不起来或者中断进不去。热词里有人问“keil5 stm32标准工程模板”，网上确实搜得到各种模板，但我的建议是别下载来路不明的模板，自己建一次工程，踩一遍坑，比用十个模板都强。自己建的工程至少你知道每个文件是干什么的，出了问题知道往哪儿找。

2.2 时钟树：不搞清楚它，外设全是乱的

热词里“stm32时钟树”被单独拎出来，不是没有原因的。STM32的每一类外设都挂在不同的时钟总线上，APB1、APB2、AHB，每一条总线的时钟频率上限不同，定时器的时钟还有内部倍频关系，F1系列里APB1预分频不为1时，定时器时钟是APB1的2倍。多少个项目出奇怪问题，就是因为时钟配置不对，定时器算出来的时间完全对不上。

新手的话建议直接套用标准库里的SystemInit()，默认外部晶振8MHz时会把系统时钟配到72MHz。但没用外部晶振、板子上只有HSI（内部RC，8MHz）时，修改时钟配置就麻烦了。比如某些最小系统板没有焊晶振，你还按8MHz外部晶振去跑，HSE起振超时后系统会自动退回HSI，整个工程实际只跑在8MHz，但你以为的是72MHz，串口波特率全是乱的。怎么看实际频率？在Debug窗口里看RCC->CFGR寄存器，里面SWS位就表示当前使用的时钟源。这算是个很实用的排查技巧。

另外，外设的GPIO时钟一定要记得使能。忘了开GPIOA的时钟，程序运行到端口操作时该引脚就没反应，但程序不会报错，因为寄存器写进去也不生效。遇到“明明配置了却没输出”的问题，第一步永远先检查对应的RCC使能位，这个步骤能过滤掉一半的假故障。

2.3 引脚复用与重映射

热词里有人问“stm32 com事件示意图”，这大概指USART的事件标志位，但更值得说的是引脚复用。STM32的很多外设引脚不是固定的，比如USART1的TX/RX可以映射到PB6/PB7，也可以重映射到PD5/PD6。标准库里要开AFIO时钟然后用GPIO_PinRemapConfig来切换。如果你的串口没有任何输出，先看看有没有做重映射，或者重映射写错成了别的外设的映射。

我还有一次因为复用功能没开，花了一晚上排查I2C通信。STM32的I2C引脚默认是开漏模式，如果配置成推挽输出，总线直接拉死，设备地址扫描永远是失败。后来把引脚改成开漏加上拉电阻，再配合4.7k上拉到VCC，通信立马就正常了。这种细节在手册里都会写，但你实际调试时会发现，真正难点在于你要记得先去查手册，而不是盯着示波器看波形。

3. 外设实战中的那些“坑王”

外设配置是STM32开发的重头戏，也是踩坑最密集的地方。这里我挑几个频率最高的坑来拆解，这些全部来自实操中被反复问到的痛点，包括串口、定时器、延时、USB虚拟串口、编码器测速等。

3.1 串口通信：为什么收不到数据

串口这个东西，看起来简单，配置就几个寄存器，但实际调试时翻车率奇高。我常说，串口收不到数据时，先分三步自查：第一，确认引脚用的对不对，有没有被其他外设占用或者重映射错；第二，确认波特率设置和实际时钟匹配不匹配，系统时钟不是默认72MHz的时候，波特率会偏；第三，确认中断有没有开、优先级有没有设置对。

热词里有“stm32串口通信”“stm32串口调试pid”，说明不少人在串口通信基础上做PID调参。这个场景下串口往往不只是收发，还牵扯到中断优先级。有一次我做串口PID调试，发送频率稍微一高，单片机就卡死。排查半天，发现是USART中断优先级和SysTick定时器优先级冲突，串口中断一直打断延时函数的时钟节拍，导致delay_ms内部的计时变量一直没机会更新，程序就死在等待循环里。

解决方案很简单，在NVIC_SetPriority里把SysTick优先级调低，或者把USART中断优先级调低（取决于你的场景需求）。PID调试时数据流比较大的话，尽量用DMA配合空闲中断接收数据，不要在中断里做大量数据处理。串口调试PID时，上位机一般每50ms到100ms请求一次数据就够了，没必要10ms一次把带宽塞满，调得太频繁反而会因为中断抢占导致控制时序抖动。

还有一个细节和热词里的情况高度相关，“esp8266wifi模块教程stm32”和“k210与stm32通讯”。ESP8266和K210这类外部模块和STM32通信时，第一件事就是确认协议电平。ESP8266好歹是3.3V电平，能和STM32直连，但如果你换了个5V的模块，就得做电平转换。其次就是串口初始化顺序，先初始化模块再初始化STM32外设，或者反过来，不同模块不一样，但我习惯先让STM32初始化完串口，然后延时50ms再给模块发AT指令，这样模块上电稳定了，应答才可靠。K210那类算力强的AI芯片和STM32通信时，常常是3.3V UART，关键要统一波特率，我一般用115200，根据帧长和负载决定是否提高。

3.2 定时器捕获测频率：数据总是不对

热词里“stm32定时器捕获测频率”也是个高频需求。很多人拿定时器捕获测PWM频率或者脉冲宽度，结果数据忽大忽小，甚至差个数量级。这里有两个坑最常见。

第一个坑是分频系数没搞清楚。捕获输入的信号，内部要先经过一个滤波器和分频器，分频设置到1的时候还好，如果设置成8，那捕获到的边沿间隔就变成了8倍，你算出来的频率自然差8倍。所以定时器输入捕获初始化时，TIM_ICInit里的TIM_ICPrescaler这个字段，一般设成TIM_ICPSC_DIV1，除非输入信号频率太高或者太密集，否则别轻易改。

第二个坑是溢出处理。如果用定时器捕获两个上升沿之间经过的计数值，当信号频率很低，间隔时间超过了一个定时器溢出周期，捕获到的值就是溢出了几次的残余结果，频率算出来完全不对。解决办法是开启定时器更新中断，在中断里记录溢出次数，计算时累加上去。这个逻辑说起来简单，但我在实际做测速时经常忘，导致低速时数据乱跳。

还有一个容易忽略的，测量霍尔传感器或者编码器AB相时，用捕获模式远不如直接上编码器模式。热词里有“stm32 编码器程序”，STM32的定时器编码器模式能直接用AB相的边沿生成计数脉冲，四倍频计数，不用自己写中断处理，性价比极高。用编码器模式时，有一个细节特别容易踩：AB相接反了没关系，计数方向反了而已，改一下TIM_EncoderInterfaceConfig里的极性就行；但PSC分频如果设了，低速时可能会丢步，编码器模式里PSC最好保持为0。

3.3 延时函数delay卡死

热词里有“stm32延时函数delay卡死”，这个真太常见了。绝大多数情况是因为你在一个中断优先级比SysTick还高的中断服务函数里调用了delay_ms。SysTick的优先级如果被设置成了最低，而你的某个外设中断优先级比它高，并且中断频繁触发，SysTick中断就一直得不到响应，delay_ms里的计数循环就永远等不到超时。所以用HAL库的HAL_Delay或者标准库的systick_delay时，先确认SysTick_Handler的中断优先级是当前系统里最低的，这一步能规避百分之八十的卡死问题。

还有一种情况是在定时器中断回调里调用延时函数。不管是什么库，中断回调里千万不要放延时，尤其是那种阻塞型延时。真想延时，可以用状态机方式记录时间戳，然后轮询判断，或者干脆把逻辑放回主循环。我在做两轮差速小车时，控制周期很紧，PID计算在一个定时器中断里完成，里面如果加了延时或打印，轮子转速马上不稳，整车跑偏。

另外提醒一点，delay_ms不要用基于软件循环空转的方式写，那种延时在优化等级不同的时候会变异，Keil的O0和O3跑出来的延时时间能差一倍。用SysTick硬件定时器做延时才是可靠方案。

3.4 USB虚拟串口：原理不复杂，坑却不少

“stm32 usb虚拟串口发送数据”和“stm32 如何做usb设备”这两个热词说明很多人开始折腾USB CDC了。USB虚拟串口的本质是把你STM32的USB外设枚举成一个串口设备，PC端看不到任何硬件串口，但设备管理器里多出一个COM口。它的好处很明显，不用外接USB转TTL芯片，一根USB线就能通信。

我第一次做USB CDC时，卡在PC不认识设备上。后来排查发现，经典的坑是USB描述符里的VID/PID和别人冲突，或者字符串描述符格式不对，导致驱动安装失败。如果你用CubeMX生成的项目，默认VID/PID是STM32的，一般能装上ST的驱动或者系统自带的CDC驱动，但如果你改了描述符里的厂商字符串和产品字符串，长度和编码格式错了，系统直接判定设备故障。

还有一个问题是数据发送不出去。USB CDC发送要轮询USBD_CDC_TransmitPacket的状态，而且要等上一次发送完成才能发下一次。如果在主循环里疯狂调用发送，USB硬件会来不及响应，导致数据丢失甚至卡住。正确的做法是加一个发送信号量或者标志位，上一次没发完就不发下一次数据。我一般在发送函数里先判断CDC->TxState是否等于USBD_CDC_BOTH_FREE，再发，实测稳得很。

另外一个硬件细节，最小系统板上如果D+引脚上没接1.5k上拉电阻，USB设备是枚举不出来的。有些国产开发板把这个电阻做在板子里了，但自己做板子时经常漏。USB的信号线要等长、尽量短，线太长了高速模式下容易通信失败。

3.5 传感器与模块通信：I2C、SPI的隐藏陷阱

热词里“stm32 bh1750 oled i2c proteus完整原理图”“ds3231 stm32”“stm32 gc032a”都指向了I2C/SPI传感器通信。I2C算是STM32外设里最让人头疼之一，硬件I2C经常出问题也是老生常谈了，所以我刚开始用的是GPIO模拟I2C，反而更稳定。但硬件I2C用得好，速度更快、占用CPU更少。关键在于两点：一是I2C时钟频率不要配太高，标准模式100kHz，快速模式400kHz，有些传感器在3.3V下对400kHz很敏感，降到100kHz反而稳；二是I2C总线需要有正确的上拉电阻，阻值一般选2.2k到4.7k，阻值太大会导致边沿太缓通信失败，太小会让功耗增加甚至信号振铃。

OLED用I2C驱动时，注意地址是0x3C还是0x3D要写对，很多OLED模块背后有电阻可以改地址。之前在Proteus里仿真时地址改成0x3C正好，如果实物模块正好相反，你就发现屏幕怎么都不亮。SPI通信坑会少一些，但要注意主从模式设置和极性/相位匹配，GC032A这种摄像头模组的SPI时序要求比较严格，有时候要单独调整时钟极性和相位，数据不全是经常因为时序不对。

3.6 电机控制与运动控制：PID，脉冲，还有编码器

热词里“stm32控制伺服电机485”“两轮差速小车stm32控制”都是电机控制相关。伺服电机485通信的坑主要是协议格式，比如Modbus RTU里的CRC计算错误或者寄存器地址不对，导致电机不响应。如果板子和伺服驱动器之间电平不一样，必须加RS485收发器，我用过SP3485，接法很简单，但有时候忘记拉方向控制引脚，就一直收不到伺服的回码。

两轮差速小车的问题集中在PID调试上。小车跑不直的原因，除了PID参数没调好，还有两个电机硬件差异不同步。我建议在PID之前先做一次开环标定，给两个电机同样的PWM占空比，记录各自的转速，然后把差异作为前馈补偿写进程序里，再调PID才有效。

做电机控制还有一个坑就是PWM频率。控制直流电机的PWM频率一般选10kHz左右比较合适，太低了电机会啸叫，太高了驱动芯片可能响应不过来。而舵机则不一样，要50Hz左右的PWM，很多人拿控制电机的PWM频率去控舵机，航模舵机全都没反应，也是被反复问到的点。

4. 调试方法论与排查技巧

前面讲了大量具体坑点，但说到底，调试STM32的方法论更重要。只要思路清晰，大部分问题都能在半小时内定位，这次我把自己的套路完整梳理一遍。

4.1 一个系统性的排查思路

遇到项目异常，我习惯按“下载-初始化-外设-数据流”四层去排查。第一步，确认程序能正常下载和运行，LED闪烁是否正常，延时是否准确。第二步，确认系统时钟和基础外设初始化没有报错，比如调试打印是否乱码。第三步，确认具体外设寄存器的值是否符合预期，比如读某个标志位寄存器，看有没有置位。第四步，数据流层面，从数据源一步一步追踪到最终输出，看到底哪一级丢了数据。这四个步骤看着简单，但很多朋友一上来就怀疑代码逻辑，忘了检查是基础配置问题。

调试工具方面，我强烈建议学会看寄存器窗口。Keil的调试器里有一个System Viewer，可以展开查看每个外设的寄存器值。曾经有人问我模拟I2C读传感器老是读到0xFF，我让他打开GPIOx->IDR看引脚电平变化，立刻发现SDA引脚上电平一直不拉低，问题定位在传感器供电没接上。寄存器窗口是一个比你用逻辑分析仪更快定位问题的工具，关键是不需要额外硬件。

断点也是老生常谈，但你真的会用吗。对付中断类问题，断点打在中断入口，看能不能触发；对付时序问题，断点不如用变量窗口观察某个计数器变化。Keil的Data Watch窗口可以实时查看全局变量，配合逻辑分析仪窗口，能看到变量随时间变化，比干等程序跑完后再看结果高效得多。

4.2 日志与打印：串口是最便宜的逻辑分析仪

串口打印调试信息，是我在所有STM32项目里都会做的事。就算产品量产不需要打印，开发阶段也一定会保留一个调试串口。核心技巧是，建立一个分层日志模块，用宏控制日志输出等级，比如#define LOG_LEVEL 3（1是ERROR，2是WARN，3是INFO）。这样把所有模块的调试信息都打出来，然后通过宏开关控制区分。项目做大了你就会发现，日志格式化决定了你排查问题是否还有退路。

打印还有个技巧，在状态切换的地方打标记。比如做按键消抖，按下和释放各打印一条带时间戳的信息，配合串口助手的显示，你能直接看到按键状态机的状态迁移是否正确。这种时间戳信息比写注释管用一百倍。串口助手建议用支持时间戳和文件保存的，比如“串口调试助手”类的软件都行，关键是能把大量数据存下来分析。PID调试时，我习惯把目标值、反馈值、输出值以CSV格式从串口输出，然后在电脑端导入Excel画曲线。这比看波形还直观，能直接看到超调量和响应时间。

热词里提到“stm32 http库”和“stm32 ota”，网络这块在调试时更能体现日志的重要性。做OTA时不打日志基本等于盲人摸象，HTTP下载进度、Flash写入校验结果、重启原因，每一个环节都要有明确的打印输出。做HTTP接口时，结构体对齐和大小端是常见的坑，尤其是通信协议和PC端不匹配时，日志能很快对比出是哪一端出了问题。

4.3 用VSCode和替代工具提高效率

热词里“stm32 vscode配置”“保姆级教程：用vscode面c语言开发环境，从零到能调试”是最近热度很高的方向。Keil虽然好用，但代码编辑体验确实一般。我自己日常用VSCode配合EIDE插件（Embedded IDE）来写代码、做语法检查，调试仍然回到Keil做。EIDE这个插件能帮你在VSCode里新建工程、管理编译、生成下载脚本，用起来非常顺手，支持STM32标准库和HAL库，也不影响Keil工程文件。

VSCode的调试能力也可以独立于Keil。如果你用OpenOCD加Cortex-Debug插件，就可以完全脱离Keil实现断点调试、变量查看、寄存器观察。这个配置一次之后，后面开发效率提升非常明显。不过对新手来说，不建议一上来就搭VSCode调试环境，因为有PACK安装、编译、烧录等一堆没理顺，先学会一套工具链再切换到另一套会轻松得多。等哪天你双击Keil要等五秒才能接受项目，或者代码量大到Keil的编辑器开始卡顿，再用这招也不迟。

另外现代调试还可以用STM32CubeMonitor这类图形化工具，实时读取变量并绘图，适合调PID曲线。我不常用，但遇到复杂控制逻辑、需要多人协作观察数据时，还是比串口Excel导出专业不少。给一个建议：工具不是越多越好，但串口加寄存器窗口加断点，这三个是必须练好的基本功。

4.4 一些通用的代码建议

这个部分本来放在最后，但我认为它比很多具体的操作都重要。我在很多项目里发现，同样的功能，两个人写出来的代码，排查难度完全不一样。写STM32代码，我建议坚持几条原则。

第一个原则，不要写大杂烩。一个main.c动辄上千行的项目，谁都难维护。做模块化，每个外设一个.c/.h文件，每个模块对外只暴露两三个初始化函数和业务接口。这个习惯帮过我好多次。有一次做一个智能台灯项目，光线传感器、PWM调光、按键、OLED各占一个文件，某个环节出了问题，直接定位那个文件就好。

第二个原则，每个模块要有状态变量和标志位的定义规范。命名要统一，不要一会儿用flag一会儿用count，让人看不明白。用枚举值描述状态，比如LED_STATE_ON、LED_STATE_OFF，比裸的0/1好排查得多。

第三个原则，尽量少用全局变量，进程间的数据传递尽量通过函数参数和返回值。全局变量在嵌入式里不可避免，但每一个全局变量都应该有明确的注释说明它属于哪个模块、由谁写入、谁读取。我在K210和STM32通信的项目里吃过亏，全局缓冲区被串口中断、主循环和AI识别线程同时访问，数据互相覆盖，最后用互斥标志解决了，但这个排查过程相当痛苦。

第四个原则，学会使用状态机。按键、通信帧解析、菜单显示，都可以用状态机来写。状态机的优势在于每一次状态跳转都是显式的，逻辑清晰，出现bug时可以逐状态排查。比如按键模块的消抖状态机，按下、确认、释放、去抖四个状态一画出来，写代码就是填表，很少会错。

最后一个建议，也是我自己最深刻的体会——不要在深夜死磕一个bug。我以前为了解决一个I2C的问题熬夜到两点，结果第二天早上十分钟就查到是总线上的上拉电阻焊虚了。调试是需要清醒头脑的，你把问题记录下来放一放，睡一觉，往往醒来第一眼就能看出问题在哪。做技术要有韧性，但也要懂得用什么方式去保持效率。

做STM32开发这些年，踩过的坑大概比我写过的代码文件还多，但每一个坑最后都变成了经验值。调试本身不是单纯的“找错误”，而是在不断加深你对芯片和系统的理解。这些东西在学校和课本里没人会系统讲给你听，都是一遍一遍调板子调出来的。希望这篇总结能帮你少走一些弯路，哪怕只是省下一个通宵，也算实现了它最大的价值。