搞嵌入式开发这么多年手上用过的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。比如你是STM32F103C8T6Flash容量是64KB那就别选一个F103ZE的算法硬往上套地址范围对不上必然失败。第二芯片型号选错了Device里选了F107的型号但实际板子是F103Flash地址映射有差异同样会出这个错。第三硬件问题最常见的就是复位电路异常或者供电不稳下载时芯片无法正常进入编程模式。排查顺序建议这样先看芯片选型对不对再看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内部RC8MHz时修改时钟配置就麻烦了。比如某些最小系统板没有焊晶振你还按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 31是ERROR2是WARN3是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开发这些年踩过的坑大概比我写过的代码文件还多但每一个坑最后都变成了经验值。调试本身不是单纯的“找错误”而是在不断加深你对芯片和系统的理解。这些东西在学校和课本里没人会系统讲给你听都是一遍一遍调板子调出来的。希望这篇总结能帮你少走一些弯路哪怕只是省下一个通宵也算实现了它最大的价值。