1. 为什么是STM32：从系统架构看懂这颗芯片的定位
经常有人问我，做嵌入式到底该从哪款芯片入门？我的回答基本没变过：STM32。哪怕这两年出现了不少新架构、新工具链，STM32依然是学习嵌入式绕不开的一个标杆。原因很简单——它不是最强的芯片，但它把"微控制器该有的样子"做得很完整：从简单的裸机点灯，到带操作系统的复杂项目，再到电机控制、人机界面、工业通信，STM32几乎都有对应的产品线能接住。
我翻了下最近半年关于STM32的搜索记录，有搜"STM32系统架构"的，有搜"STM32定时器捕获测频率"的，也有搜"STM32串口通信""STM32 USB虚拟串口发送数据"的，还有相当一批人在问"标准库怎么新建工程""Keil5怎么兼容C51"。这些问题的分布很有意思：越往后学，大家卡住的地方往往不是"怎么写代码"，而是"我写的代码为什么没按预期跑"——换句话说，是底层机制没吃透。这篇文章我就从理论层面把这些卡点逐个拆开聊，凡是涉及实操的部分，我会把排查思路一并给出来，方便你直接对照排查。
1.1 MCU和MPU的分界线在哪里
很多人把单片机理解成"一颗能跑程序的芯片"，这个说法没错，但不够精确。STM32属于MCU（微控制器），和MPU（微处理器）最大的区别在于：MCU把处理器核心、内存（Flash和SRAM)、各种外设控制器集成在同一颗芯片里，强调"单芯片就能干活"；而MPU通常只有CPU和内存控制器，外围要靠外部芯片扩展，强调"算力可以堆得很高"。
STM32的定位恰好卡在两者交界处：它的算力比传统8位单片机强不少，但它的核心价值不在于"快"，而在于"确定性强"。Cortex-M内核是中断响应非常确定的架构，再加上丰富且独立的外设控制器，让它在实时控制场景（电机、电源、传感器采集）里非常可靠。你搜到的"STM32控制伺服电机485""STM32 FOC代码"这类需求，本质上都是冲着这个"确定性"去的。
1.2 总线矩阵与时钟树：写配置代码前先看这两张图
我刚接触STM32时犯过一个错误：直接复制别人的初始化代码，改了引脚就去跑，结果外设不工作。后来我把参考手册里的两张图认真看了一遍，搞懂了"总线"和"时钟"的关系，才算真正入了门。
第一张图是总线矩阵。STM32内部不是一条总线走到底的，它强调并行：Cortex-M核心有I-bus（取指令）、D-bus（读写数据）、S-bus（访问外设），这些总线通过一个交叉矩阵连接到Flash、SRAM、AHB总线、APB总线。DMA能"不占CPU"搬运数据，靠的就是这个矩阵——DMA控制器本身就是总线矩阵里的一个主设备，它可以绕过CPU直接读写外设和内存。
第二张图是时钟树。STM32的时钟不是"上电就全都通了"，而是分层的：外部晶振经过PLL倍频得到系统时钟SYSCLK，再经过AHB预分频给到各外设总线，APB1和APB2总线上的外设各自有不同的最高频率上限。我见过不少"UART波特率乱码""定时器时间算不准"的问题，追根溯源都是系统时钟没配置对——你以为芯片跑了72MHz，实际外设总线可能只有36MHz甚至更低。
所以我会建议所有初学者：拿到一款STM32芯片，第一件事不是写代码，而是打开参考手册的时钟树和总线矩阵图，拿一支笔把"系统时钟从哪来、倍频到多少、分频到哪条总线"画一遍。这个动作只需要半个小时，但能省掉后面几百个小时的调试时间。
1.3 外设的"通用化"抽象：从引脚复用说起
还有一个被问到爆的问题："STM32芯片第一脚怎么确认？"这个问题看起来基础，但它背后其实牵扯到一个关键概念——引脚复用。STM32的物理引脚是固定的，但每个引脚能映射到哪个外设功能是可配置的。以常见的LQFP48封装为例，那颗小圆点标记的就是1号脚，然后逆时针数。可真正决定"这个脚能不能当UART的TX用"的，是你有没有把该引脚切换到复用功能模式。
很多新手配置串口时只初始化了GPIO的推挽输出，结果数据发不出去，就是因为没有理解：引脚功能选择的前提是"先选功能再配引脚"。这里有个搜索热度挺高的相关话题——"STM32禁用JTAG"。JTAG和SWD调试接口默认占用了一部分引脚，如果你想把这些引脚解放出来做普通IO，需要在初始化时把对应的调试接口功能关掉，换成复用或普通IO模式。很多人卡在这里，以为引脚烧了，其实只是功能映射没配置对。
理解了这三个层次——芯片怎么分工、时钟怎么流动、引脚怎么映射，接下来看任何外设代码都会有"原来如此"的通透感。
2. 环境搭建与工程模板的坑：Keil5、芯片包和ST-LINK的连锁反应
"STM32开发环境搭建"这个话题热度一直很高，搜索记录里能同时看到"Keil5兼容C51和STM32安装""STM32芯片包安装""STM32 ST-LINK Utility""STM32标准库新建工程"这些词。它们其实是同一条链路上的几个环节：IDE负责编辑和编译，芯片包（DFP）让IDE认识具体型号，烧录工具把程序写进芯片，工程模板决定代码怎么组织。任何一环没对上，后面全白搭。
2.1 芯片包、Keil5和ST-LINK的三角关系
先说Keil5和C51的兼容问题。很多人在学校学过51单片机，电脑上已经装了Keil C51版本，再装Keil MDK（就是用来开发STM32的版本）时发现打开哪个版本都感觉不对。实际上C51和MDK是两套独立的IDE，只是安装界面长得像。我建议的做法是分开安装目录，不要覆盖安装，然后在桌面上分别建快捷方式，按项目需要选择打开哪个。这样最省心，也避免打包库冲突。
芯片包安装是第二步。MDK装好之后如果新建工程找不到你手头那块芯片型号，问题基本就是DFP（Device Family Pack）没装。打开Pack Installer，在搜索框输入芯片型号前缀（比如STM32F103、STM32H743），把对应系列的DFP下载装上就行。这一步理论上要求在线操作，但很多人的开发电脑并不方便直接联网下载，建议提前把Pack文件下载好，离线也能安装。
ST-LINK这块也有一个高频坑。工具本身分两种角色：一是调试下载器（在MDK里配合烧录），二是固件升级工具ST-LINK Utility。有人插上ST-LINK后电脑提示"设备无法识别"，或者MDK里报"ST-LINK Upgrade"的错，基本都是ST-LINK内部固件太旧，需要用STSW-LINK007这个官方工具重新升一下固件。升级失败的情况我也遇到过几次，经验是：升级过程中绝对不要拔USB线，换一个直连的USB接口（不要经过前置面板或延长线），成功率会高很多。
2.2 标准库、HAL库和LL库：新建工程前先想清楚的三条路
"STM32标准库新建工程"是搜索量常年居高不下的关键词。这个问题之所以反复被问，是因为市面上教程分了至少三个流派，新手一搜发现答案不统一，直接懵掉。
标准化地讲，现在STM32的开发方式主要有三种：标准外设库（Standard Peripheral Library）、HAL库、LL库。我个人的建议是：如果你是初学者，或者项目追求快速出活、可读性优先，直接学HAL库；如果你追求代码执行效率、寄存器级控制，同时不想写得像天书，LL库是好选择；而标准库现在官方已经不太推新了，但它仍然是大量老教程和毕业设计参考代码的主角，你可以学，不过要有"读完代码之后自己重写一遍"的自觉。
我一般会推荐新手直接入手HAL库，配合STM32CubeMX这个图形配置工具——它能把时钟树、引脚复用、外设参数自动生成好，省掉大量手写初始化代码的时间。调研市面上的具体用法后，我的习惯做法是：CubeMX生成初始化框架，然后在生成的用户代码区里填自己的逻辑，这样既保留了图形化配置的便利，又不会因为反复重新生成代码覆盖掉手写部分。
2.3 一个容易忽略的环节：芯片第一脚与PCB封装的对应
回到"STM32芯片第一脚怎么确认"这个问题，因为问的人实在太多。绝大多数芯片封装上都会有一个小圆点或者斜角切边，那就是第一脚的标记。以最常用的LQFP封装为例：把芯片放正，缺口朝左，左下角就是1号脚，然后逆时针数。如果你用的是QFN封装，标记方式可能是某一角有个圆点，需要对照具体型号的封装图确认。
这里要特别提醒一点：PCB封装上1号脚的丝印位置，和芯片实物1号脚必须严格对应。我见过不止一次"芯片焊反了导致芯片发热烧毁"的案例，原因就是焊接时没确认1号脚方向。其他引脚功能可以再配置，但电源脚的接反是无法挽回的。焊接之前花10秒钟用万用表蜂鸣档确认一下PCB上1脚和电源脚的位置，能避免很多返工。
3. 定时器的底层逻辑：从Delay卡死到输入捕获测频率
定时器是STM32所有外设里最值得吃透的一个模块。搜索记录里的"STM32定时器模式""STM32定时器捕获测频率""STM32延时函数delay卡死"这些问题，本质上都在围绕同一个框架：预分频器、自动重装寄存器、计数器、捕获比较通道。这个框架搞懂了，PWM输出、输入捕获、编码器模式、方波输出这些花哨功能就都不难理解了。
3.1 定时器远比你想象的复杂：从PWM到输入捕获的统一框架
STM32的定时器分几档：基本定时器（比如TIM6、TIM7）只能做定时和时基；通用定时器（比如TIM2、TIM3、TIM4）在上面的基础上加了输入捕获和输出比较，可以测信号频率、生成PWM；高级定时器（比如TIM1、TIM8）又额外加了互补输出、刹车输入、死区控制，这是专门给电机驱动准备的。
不管你用哪一档，核心公式就一个：
定时器计数频率 = 定时器输入时钟 / (预分频器PSC + 1)这个算出来的值决定了计数器的"走一步"要多久。然后再配合自动重装寄存器ARR，就能设定计数周期。举个例子，STM32F103的APB1定时器时钟走72MHz（在系统时钟配置正确的前提下），如果PSC设为71，计数器频率就是72MHz/72=1MHz，也就是每1微秒走一格；如果ARR设为999，那溢出周期就是1ms。
"定时器捕获测频率"就是站在这个框架的对面：外部信号来了一个上升沿，CNT的当前值被锁进捕获寄存器CCR，同时触发中断；下一个上升沿再来一次，两次CCR的差值就是信号的周期。用定时器时钟频率除以这个周期，就是被测信号的频率。这里有个容易踩的坑：如果信号频率很高，两次捕获之间要防止CNT溢出，否则算出来的周期会诡异偏大。工程上通常的做法是同时打开定时器的溢出中断，在溢出中断里用一个变量累加溢出次数，捕获的时候把溢出次数也折算进来。
3.2 Delay卡死的常见原因与完整排查链路
"STM32延时函数delay卡死"是我特别想详细说的一个搜索词，因为它几乎每个做实时控制的人都遇到过，而且原因千奇百怪。我先给一个我实际排查过的案例，你照着这条思路走，大概率能自己找出问题。
我当时用HAL库写一个温湿度传感器驱动，程序跑起来之后发现HAL_Delay()一旦被调用就再也返回不了，整个系统卡死。排查过程大概是这样的：
第一步，确认代码有没有进到Delay内部。在HAL_Delay调用前后各加一个LED翻转，发现调用后LED灯不再变化，说明确实卡死在Delay里。
第二步，确认SysTick中断有没有被关闭。HAL库的HAL_Delay是基于SysTick的1ms中断来实现的，如果中断被关掉，Tick值永远不会增加，Delay就永远不会返回。我用调试器查看了SysTick控制寄存器，发现中断使能位是正常的。
第三步，检查SysTick的优先级。这一步才是真正的坑——我为了验证一个外部中断的实时性，把它优先级设成了最高，而SysTick优先级被设成了最低，结果外部中断持续触发，SysTick中断始终被抢占，Tick值几乎不增长，HAL_Delay实际耗时变成了几百分之一秒的正常速度。把SysTick优先级提上去之后，问题立刻消失。
这个案例说明了一个通用规律：Delay"卡死"的真正原因往往不在Delay本身，而在于中断体系。排查顺序应当是：中断是否使能、优先级是否合理、SysTick时钟源是否被改过。再延伸一步，"STM32禁用JTAG"之所以会导致部分代码无法下载，也是类似逻辑——你以为关的是一个引脚功能，实际上某个外设的中断映射、调试通道也就一起没了。
3.3 测频率之外的定时器实战：PWM和编码器模式
除了测频率，定时器还有两个高频应用值得提一下。第一个是PWM输出，这是调速、调灯光、控制舵机的基础。PWM的关键参数是频率和占空比，频率由PSC和ARR决定，占空比则通过捕获比较寄存器CCR设置：CCR的值决定了"高电平持续多少个计数格"，占空比就等于CCR/(ARR+1)。很多做智能小车的人问"两轮差速小车STM32控制"，核心就是用两路PWM分别控制左右轮速度，再通过差速实现转向，这个实现路径里定时器就是绝对主角。
第二个是编码器模式，用于读取电机转速反馈。通用定时器的两个输入通道可以接正交编码器的A/B相，硬件会自动根据两相信号的相位关系判断正反转并累加计数。这样CPU完全不需要参与脉冲计数，只需要定时把计数值读出来算速度就行。这也是STM32做闭环控制比普通8位单片机舒服的原因——硬件已经把最麻烦的计数逻辑吃掉了。
4. 串口之外：USB虚拟串口、485、LIN，几种通信方案的实战对比
STM32的通信接口可能是所有外设里用得最多的。从"STM32串口通信"到"STM32 USB虚拟串口发送数据"，再到"STM32控制伺服电机485""STM32+LIN收发器""基于STM32 EtherCAT"，搜索热度分布得非常均匀——这说明大家的需求是分层的：有人只是想把数据打印到电脑上看，有人要对接工业设备，有人要做现场总线。
4.1 串口是下限，USB是上限
UART串口是STM32通信的基石，也是大多数人第一个点通的通信接口。它只有TX、RX两根线（加上共地），波特率对上了就能收发数据。串口最大的问题在于：PC端已经很少原生支持RS232电平，所以要用USB转TTL模块来做电平转换。这也是"STM32 USB虚拟串口发送数据"这个热搜词的背景——既然串口连接电脑这么麻烦，为什么不直接让STM32自带USB接口，在电脑上虚拟出一个串口设备来？
USB虚拟串口的实现方式很取巧：USB本身不是串口，它是复杂的枚举、端点、描述符体系，但USB CDC类定义了一种ACM（抽象控制模型）——你可以理解为"USB协议里专门划了一块区域来仿真传统串口行为"。STM32实现USB虚拟串口后，电脑上会出现一个COM口，上位机软件把这个COM口当成普通串口来操作，实际上数据走的是USB总线。
我用过的做法是：用CubeMX把USB配置成Device模式、选择Communication Device Class（也就是CDC），然后在生成的框架里重写收发回调。电脑端不需要额外安装驱动（多数系统自带CDC驱动），插上就能识别。虚拟串口的速度上限远高于物理串口，适合大数据量日志、固件升级、上位机高速交互场景。代价是：调试USB枚举问题比串口复杂得多，拔插一个端点描述符配错了，设备就在电脑上毫无反应。所以新人如果只是要打印调试日志，老老实实用UART更合适。
4.2 485、LIN、EtherCAT：工业场景的选型逻辑
再往上一层，是RS485。485和普通串口共用同一套UART硬件，区别在于物理层：485用差分信号传输，抗干扰能力强，传输距离远，而且支持总线挂多台设备。搜"STM32控制伺服电机485"的小伙伴应该就是要用485协议和伺服驱动器通信——一般是通过MODBUS或者伺服厂商的私有协议，用UART发送指令帧，驱动器返回状态。这里的关键动作是方向控制：RS485是半双工的，发送数据时需要把DE引脚拉高，发送完再拉低恢复接收。这个切换时机要把握好，否则会丢最后一个字节或者收到自己发出去的回声。
LIN总线又是另一种思路，常用于汽车车身控制——车窗、雨刮、座椅这种低速控制场景。它基于串口，但加了调度表、帧头、校验规则，是一种低成本的单线总线。STM32串口硬件本身不支持完整的LIN协议，实际方案是外部加一个LIN收发器（把UART电平转成LIN物理层的12V单线电平），协议部分用软件模拟或用串口的同步断开检测功能辅助实现。
至于EtherCAT，它和前几个完全不在一个量级。EtherCAT是实时工业以太网，主站用普通网口发数据，从站则必须有一颗专用的EtherCAT从站控制器（ESC）芯片，或者用集成ESC的MCU。你在STM32上做EtherCAT，通常不是直接把UART改成EtherCAT，而是用一颗带ESC接口的芯片做主控，外部挂ESC芯片，再接PHY。分布式时钟（DC）同步是EtherCAT最核心的机制——所有从站通过读取主站广播的参考时钟来校正自己的本地时间，从而保证多轴运动同步精度在纳秒级。这是很硬核的课题，如果你做的是"STM32 EtherCAT"搜索，我猜你大概率是在评估主站方案或从站方案可行性，建议先确认清楚自己的项目需要的是哪一种。
4.3 调试经验：串口打印PID参数的正确打开方式
最后说一个搜索量不大但非常实用的点："STM32串口调试PID"。很多人在调PID的时候，期望能实时看到目标值、反馈值、误差、输出量，以便把整定过程可视化。串口打印的核心不在于波特率设置，而在于格式化输出的组织方式。我的习惯是：把发送数据拼成一个结构体，统一用一个发送函数，每条数据以固定帧头+长度+内容+校验的形式发出去；上位机端写一个简单的Python脚本用pyserial读取，解析后实时绘图。
这里有个经验：不要在主控制循环里直接调printf之类的重定向函数，因为它可能会因为等待发送完成而阻塞控制周期。更好的做法是：控制循环先把待调试数据写入一个环形缓冲区，后台低优先级任务或者DMA空闲中断来负责真正把缓冲区发给上位机。这样PID整定不会被打乱，数据还能稳定外送。这也是"定时器模式""DMA传输"这些概念在通信场景里的经典组合应用。
5. 进阶场景的共性思路：FOC、LVGL、EtherCAT背后的抽象层次
再往深处走，搜索记录里出现了一批看起来很高端的词：FOC代码、LVGL移植、Biss-C解码、超声波测距、GC032A摄像头，甚至还有"STM32鱼缸""报站程序完整代码"这种小而美的完整项目。这些话题看似风马牛不相及，但如果你把"理论"两个字吃透了，会发现它们全都在同一个思维框架里。
5.1 从外设到算法：FOC代码为什么难
FOC（磁场定向控制）是电机控制领域的大热门，搜"STM32 FOC代码"的人基本是想自己实现一个无刷电机驱动器。FOC为什么难？因为它不是单一外设问题，而是"定时器+ADC+三角函数+状态机"的完整组合：
- 电流采样：需要ADC同时采集两相或三相电流，采样点必须精确放在PWM周期的中心——这要求高级定时器的触发输出和ADC触发同步；
- 坐标变换：Clarke变换把三相电流变成两相静止坐标系的值，Park变换把静止坐标系旋转到转子磁场坐标系，每步都要算sin/cos，这对MCU算力有要求（所以FOC通常用带FPU的M4/M7核）；
- SVPWM：把电压矢量分解成相邻两个基本矢量的时间组合，最终输出到三个互补PWM通道——这又用到了定时器的PWM输出和互补通道。
你去看任何一份STM32 FOC代码，抽丝剥茧后看到的都是基础外设的组合运用。所以说，FOC不是"一个功能"，而是一个"外设组合的上层建筑"。理论扎实的人写FOC，是从底层逐层搭起来的；理论不扎实的人抄FOC，只会改PID系数。
5.2 LVGL和图形界面：内存是第一约束
"STM32移植LVGL"的搜索量也很大。LVGL是嵌入式领域最流行的图形库之一，但它直接暴露了MCU和MPU的差距：图形界面需要帧缓冲，一块480x272分辨率的RGB显示屏，如果颜色格式是RGB565，帧缓冲就需要480x272x2=261120字节，约255KB。而很多入门级STM32的SRAM只有20KB、64KB，根本放不下整个帧缓冲。
所以在STM32上做LVGL的第一件事不是写界面代码，而是算内存账。我见过几种可行方案：一是降低分辨率或色深，用240x240甚至更小的屏；二是用SPI接口的屏幕，让LCD控制器自带显存（这类屏通常内建GRAM，MCU只需要把像素数据推给它），MCU侧就不用再留帧缓冲；三是在有几MB外部SRAM或SDRAM的板子（比如H743系列配合外部存储）上跑全尺寸界面。做完内存规划后再去移植，很大程度上能避免"LVGL跑起来卡死"这种常见问题。
5.3 USB设备的实现思路与小项目的通用套路
USB类的问题在热搜里出现了好几次，除了虚拟串口，还有人问"STM32如何做USB设备"。从理论上看，实现思路其实有一个固定的套路：第一步想清楚设备属于哪种类别（HID键盘/鼠标、CDC串口、MSC存储、自定义HID），第二步用CubeMX生成USB Device框架，第三步根据类别的协议要求实现回调接口，第四步处理端点接收和发送。不管哪种类别，枚举过程的本质都是：设备用端点0响应主机的各种标准请求，把设备描述符、配置描述符、接口描述符、端点描述符依次返回给操作系统。理解了这个链路，以后遇到任何USB问题都不会再害怕。
至于"STM32鱼缸""基于STM32的智能台灯""报站程序完整代码"这些整项目搜索，看着像需求各异的小项目，实际共性极强：传感器采集（温度、水位、光照）→ 数据处理（阈值判断、简单状态机）→ 执行输出（继电器、LED、声音、显示屏显示）。你只要把定时器、ADC、GPIO、串口这四个基本功练扎实，再做任何这类项目都只是换了一下传感器和执行器的型号而已。
6. 选型与毕业设计避坑指南：从H743到鱼缸，理论如何落地
最后说说选型和毕设选题，因为这直接决定你学STM32理论时"用在哪"。搜索记录里能同时看到"STM32 H743系列微控制器中文技术手册"和"基于STM32的毕业设计"这类词，说明提问者既有想拿高端芯片做高性能项目的，也有正在为毕设题目头秃的。
6.1 怎么选芯片：从H743看产品分级
STM32家族我非常简单地给你划个分区：
- F1系列（比如F103）：经典入门款，72MHz，资源丰富，教程最多，价格也便宜，适合学习和小型项目。
- F4系列（比如F407）：带FPU和DSP指令，主频168MHz起步，适合需要浮点运算的场景（音频、图像处理、部分电机控制）。
- H7系列（比如H743）：主频480MHz，双核或者带大量RAM和高级外设，能跑小型Linux或复杂的图形界面、EtherCAT从站等高端场景。
关于H7系列，我多说一句：很多人以为"越高端的芯片越好学"，实际恰恰相反。H7的系统架构比F1复杂得多——引入了双核、L1缓存、带ECC的RAM，很多标准库/老代码无法直接跑在H7上。如果你是新手，第一块板子选F4甚至F1都行；如果你已经有明确的高性能需求（大屏、复杂算法、工业总线），选H7才合理。
还有一个小提醒：关于"STM32 H743系列微控制器中文技术手册"的搜索，H7系列参考手册英文版都有一千多页，中文翻译版可能滞后于芯片版本，阅读时务必确认手册对应的芯片勘误版本和你的芯片Revd版本一致，否则个别寄存器描述会存在差异。
6.2 毕业设计题目的方法论：把"能跑通的完整系统"放在第一位
每年毕设季都有大量"基于STM32的XXX"选题。作为一个看过很多人从选题到答辩全过程的人，我在这方面的建议就三条：
第一，选题不要贪大。一个能用且能演示的完整小系统，比一个半途而废的大系统好太多。比如"STM32鱼缸"就比"基于STM32的智能水产养殖物联网云平台"稳妥得多——前者是传感器+水泵+显示，后者还要你搞定移动端、云服务、数据库，任何一个环节都能拖垮进度。
第二，优先选择你能稳定复现的模块。超声波测距、OLED显示、DS3231时钟、按键控制LED，这些单个模块的技术点非常成熟，资料多、例程多，组合起来的成就感也不低。
第三，答辩质量取决于你对"为什么这样做"的回答。你是不是真的理解了I2C时序、理解定时器中断、理解通信协议握手？这些理论层面的东西，比代码本身更能体现你的工作量。所以哪怕毕设题目再小，也值得在每个模块上花一点时间把原理搞清楚——这既是为了答辩，也是为后续工作铺路。
另外，"STM32项目""STM32智能小车""STM32报站程序完整代码"这类搜索词下能找到很多开源项目，但我要提醒一句：直接抄代码是最容易挂掉的方式，因为你答不上"为什么"。比较好的做法是：下载一份看起来结构清晰的项目，先读懂它的系统框图，再看每个文件职责，然后自己从零写一遍核心模块。这个过程虽然慢，但收获最大。
老实说，在这个行业呆得越久，我越发现STM32的"理论"不是一本手册能装完的，它更像一张网——系统架构、时钟、中断、通信协议、外设组合，每一个节点都连着具体应用。前期花时间把这张网织密一点，后面做任何项目都能省下无数个"为什么跑不通"的深夜。
