STM32开发从入门到项目复现：资源平台与调试心得全梳理

我见过太多人开始学 STM32 时，第一件事不是翻手册、搭环境，而是到处找“别人编译好的工程模板”。模板下载了七八个，打开后全是报错：路径不对、芯片型号不对、库版本不对、下载器连不上。标题写着“寻找 STM32 开发参考方案”，但大家真正缺的，不是“没有资料”，而是没有一条能把资料串起来的主线：该信官方文档还是开发板教程？Keil、CubeMX、VSCode 到底怎么取舍？标准库和 HAL 库学了哪一个才算没白学？看到“STM32 超声波测距”“基于 STM32 的毕业设计”这类题目时，芯片第一脚从哪确认、Delay 卡死怎么查、CAN 突然连不上该先动哪根线？这些问题不梳理清楚，收藏再多的帖子、加再多网盘链接，还是在原地打转。

这篇把国内真正值得反复用的资源路径、判断标准和调试心得完整整理一遍。目标读者有两类：一类是刚拿到最小系统板、连 STM32 芯片第一脚都要确认的新手；另一类是手里已经有具体项目（USB 设备、CAN 通信、超声波测距、两轮差速小车、智能台灯、鱼缸）急需快速复现的开发者。文章不打算堆一百个网址，重点说清“哪个平台解决哪类问题”，以及“怎么判断一份资料到底值不值得跟”。

1. 先别急着开干：STM32 开发方案的整体思路

1.1 为什么 STM32 资料给人的感觉是越来越乱

三年前搜“STM32 标准库新建工程”，第一眼是 MDK 的工程配置；今天搜“STM32 如何做 USB 设备”，你会看到两个完全不同的流派：一边是 CubeMX 直接生成 CDC 骨架，另一边是拿着标准外设库手写 USB 寄存器代码。前者的教程大多只让你“一路 Next”，后者的文章经常断更在某个初始化函数里。之所以这么乱，因为 STM32 生态被严重分层：老资料使用标准外设库（SPL），官方已经停止更新；新资料几乎全部基于 HAL/LL 库。而工具链又分 Keil MDK、STM32CubeIDE、GCC+OpenOCD 三条路线；芯片从 F1 到 H7，外设寄存器差异非常大。所以不是资料变少了，而是“旧资料不能直接把新工程跑起来”，反过来新库的函数封装太深，出问题后又不好查真正的硬件寄存器。所有人都被夹在中间踩坑。

理解了这种分层，再去找资料就知道不能盲目：先确定自己在哪一层。我给大多数人的建议是三步走：第一步，用 STM32CubeMX 生成工程骨架；第二步，把 HAL 库生成的初始化代码当成“默认正确”的底子；第三步，出错的时候老老实实去翻对应芯片的参考手册（Reference Manual），而不是一上来就怀疑库函数写错了。这套思路在下面所有资源平台里都适用。

1.2 选型三连：系列、固件库、开发环境

• 芯片系列：F1 系列资料最多、价格便宜，教学资源泛滥，适合入门和大部分 DIY 项目；F4/F7 支持硬件浮点、摄像头 DCMI、SDRAM，适合跑屏幕和 LVGL；H7 性能强但上手成本高，光 H743 中文技术手册那厚度就能劝退不少人。第一块板子建议选 STM32F103C8T6 或 F103ZET6，外设够用，遇到问题有大量现成答案。

• 固件库：标准外设库函数直观、寄存器控制感强，但早已停止维护，不适合新芯片；HAL 库是当前主流，CubeMX 生成的工程可以直接干活；LL 库介于两者之间，初始化代码精简，适合深度定制。新手我建议直接入 HAL，但要清楚 HAL 函数内部做了什么，比如 HAL_UART_Transmit 最终就是往 USART->DR 寄存器写数据，理解到这一层，调试才不会心虚。

• 开发环境：Keil MDK 最普及，学校课件、毕业设计、老工程师的文档几乎都是它；STM32CubeIDE 是 ST 官方免费 IDE，调试体验好，只是很多人不习惯 Eclipse 界面；VSCode+EIDE/OpenOCD 更接近软件工程师的工作流，配置略麻烦。我的结论是主线用 MDK 或 CubeIDE，副线再玩 VSCode，别把第一天的时间全烧在环境配置上。

2. 国内优质 STM32 资源平台汇总：我反复在用的七个渠道

2.1 开发板厂商资料库：正点原子、野火、安富莱

正点原子（ALIENTEK）的资料，特点是体系化程度高。从 PDF 教程、视频、源码、原理图到手册，一个资料包全部覆盖，目录按“第几章、实验几”排得清清楚楚。我自己的习惯是：要查某个外设的“标准用法”，先翻正点原子的例程，它的例程大部分是基于 HAL 库重新整理的，中文注释比官方例程多得多，对新手非常友好。不过要记住：教程里写的引脚是针对自家开发板的，换到自己的最小系统板时必须重新核对引脚，不然就会像论坛里那些“照原子例程点灯灯不亮”的帖子一样卡几天。

野火（Fire）的文档风格是我个人最推荐的，尤其在底层原理讲解上。《STM32 库开发实战指南》先讲外设硬件原理，再讲寄存器，最后才给代码，把定时器输入捕获、串口 DMA、FSMC 这些机制讲得比较透。想把某个外设真正搞懂，野火文档比大多数博客值得静下心读。安富莱（硬汉嵌入式）论坛的氛围偏老工程师，话题集中在 FOC、ThreadX、LVGL、CANopen、Modbus、国产化替代这类工业级问题，讨论深度高。想要进阶，安富莱的例程和文档远超市面普通教程，但对纯新手的劝退指数也高，适合手上项目能跑通之后再去泡。

2.2 官方文档与中文资料中心：ST 官网和 ST 社区

ST 官方文档这几年“中文化”程度逐年提高。芯片数据手册（Datasheet）、用户手册（Reference Manual）、应用笔记（Application Note）都能在 ST 官网对应产品页下载，部分文档有中文版。搜索“STM32H743 中文技术手册”时，会看到 RM0433 中文版这类文件，建议直接收藏官方文件页，不要只存网盘链接。STM32CubeMX 和 CubeIDE 自带的固件例程包，在 Help 菜单的 Example Finder 里就能浏览，很多网上收费资料其实就是把官方例程翻了个中文。

另一个容易被忽略的入口是 ST 中文社区，上面有官方工程师回答的帖子、常见问题集锦。很多“CAN 通信突然连不上”“USB 枚举失败”这类问题，在这里能找到官方口径的答案，而不是二手甚至三手的推测。用 CubeMX 配置工程时遇到外设冲突、时钟树报错，官方回答基本都会给出“检查时钟树、检查引脚复用功能”这类方向性建议，比 CSDN 上复制粘贴的报错截图有用得多。

2.3 中文工程师社区与问答平台：21ic、电子发烧友、CSDN

21ic 电子论坛是国内老牌嵌入式社区，很多工程师喜欢在帖子里写完整的“问题—解决—原因”过程。搜索“STM32 定时器输入捕获 测频率 site:21ic.com”，命中的帖子往往比直接搜“STM32 测频率”更靠谱。电子发烧友（Elecfans）偏资源下载，很多 PCB 工程、源码、毕设资料会共享在上面，但下载后先看芯片型号，再核对作者有没有放出完整原理图。CSDN 是双刃剑，好文章不少，但搬运文更多：同一个功能能有人写八篇文章每篇内容相同。我的经验是，先看发布日期和阅读量，再看代码里用的库版本；凡是只有代码没有原理、没有报错分析的文章，多半是从某个开源项目拆了一半再拼出来的，跟着走容易跑偏。想要精准搜索，多用 site 命令，比如“site:21ic.com stm32 can 丢失”，效果比直接搜平台名称好很多。

2.4 开源代码仓库与硬件开源广场：Gitee、GitHub、立创开源平台

代码类资料，GitHub 和 Gitee 上有大量可直接编译的 STM32 工程。ST 官方在 GitHub 和 Gitee 上都有账号，持续发布 STM32Cube 固件包、扩展包、传感器例程等。国内访问 Gitee 更稳定，从这两个平台下载工程之前，先看 README 里的分支和版本说明，HAL 库的版本（比如 F1、F4 版本号不一样）和 CubeMX 版本不匹配，编译大概率不过。另一个隐藏坑是：工程里的 .ioc 文件需要用对应版本 CubeMX 打开，低版本打不开高版本生成的工程，这时先把 CubeMX 软件升级，再重新生成外设初始化代码。

立创开源硬件平台（oshwhub）是我最近两年用得越来越多的宝藏渠道。很多作者会上传“智能鱼缸”“两轮差速小车”“基于 STM32 的智能台灯”“报站程序”这类完整工程，包含原理图、PCB、BOM、源码，甚至还有演示视频。“完整原理图 + PCB + 源码”这一整套，比 CSDN 上散落的 PDF 手册值钱得多。判断这类工程能不能复现，先看 BOM 里的具体器件型号，再看作者近期有没有更新或回复评论，最后对照 MCU 引脚定义和代码里的 GPIO 配置是否一致，不一致就自己用 CubeMX 重新生成引脚。

2.5 视频教程与轻松入门：B 站和微信公众号

视频教程适合入门阶段。江协科技（江科大）的 STM32 系列视频，是现在公认新手友好范本，从 GPIO、串口、定时器到超声波、PID，一集一个外设，评论区还有配套资料链接。正点原子和野火官方也在 B 站更新视频，虽然视频内容和自家板子绑得比较紧，但原理部分适用于任何开发板。公众号方面，“嵌入式Linux”“玩转嵌入式”“strongerHuang”这类账号会持续发布基于 CubeMX 的 HAL 库实操笔记，适合碎片时间刷。公众号文章的真实性通常比聚合类网站高，因为很多是从论坛精选的实战记录改造而来，缺点是历史文章不好检索，看到好文建议立刻分类收藏。

2.6 资源平台速查表

你在搜“STM32 超声波测距”时，别只看一篇就动手。找三篇不同来源的对比一下，寄存器版本和 HAL 版本的区别马上就能看清，谁在胡说、谁真跑过板子也一目了然。

3. 搭建环境时最常翻车的环节：Keil、下载器、命令行

3.1 芯片引脚识别与工程重建：第一脚、Keil 双平台、芯片包安装

芯片第一脚怎么确认？看三个地方。第一看丝印缺口：LQFP/TSSOP 封装表面有一个圆点或凹口，紧挨着它的是 1 脚；第二看文字方向：芯片表面的丝印文字正着读时，左下角通常是 1 脚；第三看封装图：每种封装的 1 脚位置最终要以数据手册里的“机械封装图”为准。F103C8T6 最常见的 LQFP48 封装上，丝印缺口在左上角，1 脚就在它旁边。有人把第一脚搞错，上电直接冒烟的情况我见过不止一次，所以这一步真别省。

“Keil5 兼容 C51 和 STM32”是另一个高频问题。正确做法是：先装 MDK-ARM 的 Keil uVision5，再装 C51 版本，两个安装包共用同一个 uVision 外壳。装完之后在 Pack Installer 里分别下载 ARM 和 C51 的器件包。新建工程时，Device 窗口左侧会同时出现 STMicroelectronics 和 8051 相关厂商，说明双平台共存成功。注意，ARM 和 C51 的 License 是分开的，个人学习用官网评估版足够，别去找什么“一个 License 通吃两套”的旁门左道。芯片包安装则在 Keil 的 Pack Installer 中展开 STMicroelectronics，勾选 STM32F1xx_DFP、STM32F4xx_DFP 等待下载，或者在 ST 官网下载 DFP 包手动安装。很多“找不到芯片”的报错，说白了就是 Pack 没装上。

3.2 下载器与调试：JTAG 禁用、Flash Download Failed、VSCode 配置

加载报错长这样：load "d:\stm32 prohect\...\project.axf" error: Flash Download failed。遇到这类问题，我屡试不爽的排查顺序有三步。第一步查接线：SWDIO、SWCLK、GND 必须连好，如果需要目标板供电，3.3V 也要接；第二步查软件配置：Keil 里 Options-Debug 右侧选 ST-Link 或 CMSIS-DAP，然后点 Settings，如果检测不到 IDCODE，把 SWCLK 频率从 4MHz 降到 1MHz 再试；第三步查 Flash 下载页：Programming Algorithm 列表里有没有对应 Flash 容量，比如 F103C8 是 64K，虽然选 STM32F1 Flash 128K 也能擦写，但选 64K 更稳。另外工程路径别放太深，尽量用纯英文路径，避免中文和空格带来的工具链兼容问题。

“STM32 禁用 JTAG”是典型实战需求。F103 的 PA13/PA14/PA15、PB3/PB4 默认复用为 JTAG/SWD 引脚，如果想把 PB3 当普通 IO 用，就需要调用 GPIO_Remap_SWJ_Disable 或 HAL 库里的 AFIO 重映射函数，把 JTAG 关掉、只保留 SWD；如果想全关所有调试口，用 GPIO_Remap_SWJ_Disable；想保留 SWD 只释放 JTAG 引脚，则用 GPIO_Remap_SWJ_NOJTAG。关掉 JTAG 之后还能正常下载，前提是保留 SWD 模式。但要是你把 SWD 引脚也复用成其他功能，程序跑飞后下载器会彻底找不到芯片。抢救办法是把 BOOT0 拉高重新上电，用 STM32CubeProgrammer 通过串口连接并全擦除 Flash，再把 BOOT0 拉回低电平复位，芯片就能恢复正常。

VSCode 配置 STM32 开发环境，推荐路径是“CubeMX 生成基础工程 + VSCode + EIDE 或 Cortex-Debug”。EIDE 负责编译管理，编译器用 arm-none-eabi-gcc，烧录用 OpenOCD。调试配置在 launch.json 里写：

{ "version": "0.2.0", "configurations": [ { "name": "STM32 Debug", "cwd": "${workspaceFolder}", "executable": "./build/output.elf", "request": "launch", "type": "cortex-debug", "servertype": "openocd", "configFiles": ["interface/stlink.cfg", "target/stm32f1x.cfg"], "svdFile": "./STM32F103.svd" } ] }

如果你的下载器是 CMSIS-DAP，把 servertype 换成 cmsis-dap，configFiles 换成 interface/cmsis-dap.cfg。网上有些帖子会在 launch.json 里配置 powerlink、以太网这类参数，那多半是工业协议项目的特殊调试链路，跟普通 STM32 开发没关系，别被带偏。先保证 OpenOCD 命令行能连上目标芯片，再谈调试器好不好用。

4. 核心外设实操与排查：定时器、传感器、通讯一个都不能少

4.1 定时器：模式、捕获测频率、Delay 卡死

定时器有四种常见玩法：定时更新中断、PWM 输出、输入捕获、编码器模式。F103 系列里，TIM1/8 是高级定时器，支持互补 PWM 和刹车输入；TIM2-5 是通用定时器；TIM6/7 是基本定时器。输入捕获测频率的原理很简单：每次上升沿到来时，硬件把计数器当前值锁存到 CCR1 寄存器，连续两次上升沿的差值就是信号周期，再配合预分频 PSC 就能算出频率。举例，F103 的 TIM2_CH1 映射到 PA0，PSC 设为 71，计数器时钟为 1MHz（72MHz 除以 72），捕获值差 1000 就是 1ms 周期，对应 1kHz 频率。注意被测信号电压不要超过 3.3V，否则要加电阻分压或比较器整形。

“STM32 延时函数 delay 卡死”是被问得最多的问题之一。HAL_Delay 依赖 SysTick 滴答中断，SysTick 的优先级默认是最低的，如果其他外设中断里也调用 HAL_Delay，或者程序里关过全局中断，SysTick 就永远等不到触发，Delay 直接死循环。解决思路有三个：中断回调里不要用 HAL_Delay；需要精密延时就专门用 TIM6 做一个 us 级延时函数；如果工程已经跑了 FreeRTOS，SysTick 要改为空闲任务作时基，否则任务调度和 HAL_Delay 会互相干扰。还有一类假“Delay 卡死”是 CubeMX 时钟树配置错误，HSE 晶振值填错后 RCC_ClockConfig 一直超时，界面看起来像卡在 HAL_Init 里，本质是两个问题，排查时先分清。

4.2 常用传感器：DS3231、BH1750、OLED 与 I2C 的坑

DS3231 实时时钟和 BH1750 光照传感器都是 I2C 设备，可以挂同一条总线。I2C 调试三板斧：第一，确认 SCL/SDA 引脚有没有外接上拉电阻，一般 4.7k 左右，没有上拉时通信时好时坏；第二，确认器件地址，BH1750 是 0x23 或 0x5C 取决于 ADDR 引脚电平，DS3231 是 0x68，地址写错全部白搭；第三，如果用的是软件模拟 I2C，延时不能太短，F103 跑 72MHz 时延时循环次数太少会导致时序不满足。OLED（SSD1306）也常走 I2C，但高帧率刷新时 I2C 速度不够，要换 SPI 接口版本或加 DMA。搜“BH1750 OLED I2C Proteus 完整原理图”时会发现很多仿真工程，但 Proteus 仿真的 I2C 时序比真机慢，仿真能调通不等于真板能调通，真机不通信时先拿万用表量 SCL/SDA 的电平和波形，再回头查代码。

4.3 串口接收、USB 设备和 HTTP 请求：三类“带网络感”的应用

串口接收不定长数据是项目标配。最少要学会三种方式：轮询查询标志位、中断接收固定长度、DMA+空闲中断接收不定长。在没有学好 DMA 之前，先用串口中断配合环形缓冲区把数据收下来，重点处理一帧数据被拆成两次中断的情况。串口乱码，十有八九是时钟配错或波特率偏差，检查外部晶振是 8MHz 还是 16MHz，CubeMX 里的 HSE 值填得跟实际晶振不一致，波特率就偏了。搜“STM32 串口调试 PID”，会看到很多用串口把设定值、反馈值、输出值曲线发给上位机的教程，配合 VOFA+ 或 SerialPlot 看曲线，调 PID 效率比 printf 一个个数高得多。

USB 设备开发，从 CDC 虚拟串口入门最划算。在 CubeMX 里把 USB_DEVICE 配置成 Communication Device Class（CDC），配好时钟树，F1 必须让 PLL 输出 48MHz 给 USB，然后生成工程，插上板子会被电脑识别成虚拟串口。这就完成了一个“用 STM32 做 USB 设备”的最小闭环。常见问题：插上没反应，先查 DM/DP 线上的 22 欧串联电阻和 48MHz 时钟是否准确；枚举成功但发数据丢包，检查端点缓冲描述符和 CDC 轮询间隔。想做 HTTP 请求，最省事的方案是外挂一颗 ESP32C6 或 ESP8266，用 AT 指令跑 TCP/HTTP，STM32 端只写一个简单的 AT 命令解析；要在纯 MCU 内跑 HTTP 服务端，就得用 lwIP 协议栈，学习曲线明显陡很多，不建议第一个项目就上。

4.4 CAN、485 与伺服电机：工业通信怎么排查

CAN 是 STM32 里最容易被“调通一次但说丢就丢”的外设。“STM32 CAN 通信突然连不上”的排查步骤按这个顺序来。第一步，用回环模式自测，把 CAN 句柄的 Mode 改成 LoopBack，自己发自己收，能收发说明 MCU 外设正常。第二步，检查硬件链路，CAN 收发器有没有供电，CANH/CANL 是否正确接到总线，两端节点各有一个 120 欧终端电阻，中间节点不要接。第三步，检查波特率，F1 的 CAN 外设挂在 APB1 上，时钟如 36MHz，需要分频、BS1、BS2 组合，推荐直接用 CubeMX 的 CAN 波特率计算器生成，多节点时采样点最好在 87.5% 附近。第四步，检查过滤器，先用最宽松的掩码模式接收所有 ID，排除“帧被过滤器吞掉”的可能。第五步，读 CAN 错误状态寄存器 ESR/ECR，错误计数持续增加，大多是波特率不一致或物理层电平异常。

RS485 控制伺服电机，本质是 Modbus RTU over RS485。发送方向切换引脚要在发送完最后一字节后保持几十微秒再拉低，推荐用 DE/RE 合一的引脚控制，比如 MAX3485 的 DE 接 PA8，发送前拉高，发送完延时再拉低。485 总线要共地，几十米以上的线缆还要加终端电阻。搜“STM32 控制伺服电机 485”时，大概率会看到这样的配置：UART2 发 Modbus 帧，485 芯片是 MAX3485 或 SP3485，伺服驱动器地址比如 01，功能码 06 写单个寄存器。Gitee 上有一个 agile_modbus 工程，轻量级 Modbus 主机/从机协议栈，自带 STM32 例程，比从零写帧解析省事很多。另外顺带一提，LIN 总线和 CAN 一样属于车用网络，STM32 上通常用 UART 外接 LIN 收发器即可，网上搜索“STM32 LIN 收发器”也有现成参考，但它不是自学首选。

4.5 其他高频外设：超声波、步进电机、FOC、LVGL、K210

超声波测距 HC-SR04 的用法是：Trig 拉高 10us 以上触发，Echo 返回高电平，高电平时间乘以声速 340m/s 再除以 2 就是距离。最大的坑是 Echo 引脚输出 5V 电平，直接接 STM32 的 PA0 会进 IO 保护，建议用两个电阻分压或电平转换芯片。测高电平时不要用 while 轮询，对实时性要求高的项目用定时器输入捕获：上升沿触发开始计时，下降沿捕获结束，两次捕获差值就是高电平时间。

步进电机“五线四相”通常指的是 28BYJ-48，驱动芯片用 ULN2003，相序是 A-AB-B-BC-C-CD-D-DA（八拍）。控制代码本质就是按相序表刷新四个 IO 口，每步之间加延时，延时越短转速越快。如果电机只抖不转，多半是相序反了或某一相断线。FOC 无刷电机控制不是新手外设，想入门建议买带电流采样和驱动一体的 SimpleFOC Shield，软件用 SimpleFOC 库或参考安富莱的 FOC 教程，调试人员至少要有示波器看相电流。LVGL 移植适合 F4 以上芯片，F103 硬跑会卡，用 SPI 接口的 320x240 屏、关闭阴影和抗锯齿，勉强能做个小仪表。K210 与 STM32 通讯常用于 AI 识别，K210 做视觉识别，通过串口把目标类别坐标发给 STM32，协议帧建议自定义为“帧头+数据长度+类别+坐标+校验和”，比 SPI 简单稳定。GC032A 这类摄像头芯片更适合 K210 这类带 ISP 的芯片，STM32 直驱要开 DCMI 接口，不建议拿它入门。

5. 从热词看典型项目：毕业设计级完整方案怎么找、怎么复现

5.1 常见项目形态与资源检索公式

从高频搜索词看，STM32 项目集中在四类：环境控制类（智能鱼缸、智能台灯）、运动控制类（两轮差速小车、步进电机、伺服电机）、数据采集类（超声波测距、DS3231、BH1750）、通信类（USB、CAN、485）。这四类项目找参考方案的公式是完全一样的：“芯片系列 + 外设关键词 + 传感器型号 + 最终目标”。搜“STM32 HAL 库 智能台灯 BH1750 OLED PWM”，比搜“基于 STM32 的智能台灯”更容易命中现代资料，原因很简单：加了型号和库版本，搜索引擎能帮你过滤掉十年老帖。

这套公式不只适用于这些项目。你手上哪怕换一个传感器，也能用同样的组合套出几十份可参考的工程。

5.2 判断一个开源工程能不能复现，只看四点

第一个看 MCU 型号。哪怕 F103C8T6 和 F103CBT6 看起来差别不大，Flash 和 RAM 容量也不一样，代码里 Flash 容量设置错误，下载时会直接报 Flash Download failed。第二个看库版本。HAL 库 1.8 和 1.11 的 API 存在不少差异，例程用到旧 API，编译报错时请先升级 CubeMX 版本，再用新版重新生成外设初始化代码，而不是硬改库文件。第三个看引脚映射。开源工程如果基于野火或正点原子开发板，引脚分配不一定适合你的最小系统板，对照原理图和代码里的 GPIO 配置逐脚核对，必要时候自己用 CubeMX 重新分配。第四个看供电和电平。5V 传感器直接接在 3.3V MCU 上，或者 3.3V MCU 的信号线直连 5V 系统，是烧板和输出异常的常规原因。把四点过一遍，再下载工程，成功率会高非常多。

6. 效率习惯：调试方法论比多刷一百篇教程有用

6.1 调试三板斧：点亮、打印、测波形

我调试 STM32 外设的顺序永远是“点亮、打印、测波形”。点亮，是最小系统板上的 LED，确认 GPIO 配置正确、时钟树跑通，这是所有外设的基础。打印，是利用串口打印关键状态变量，看初始化是否成功、中断是否触发、数据是否符合预期。测波形，是关键时刻用逻辑分析仪抓引脚电平、示波器看时钟和协议时序。很多人卡了一个通宵的问题，往往逻辑分析仪一夹就看出来了：I2C 的 SDA 始终是高电平，CAN 的 TX 引脚没有数据，PWM 输出频率差十倍。Keil 自带的逻辑分析仪能对付低频信号，高频信号还是建议外接一台示波器。

6.2 最小工程思维与提问模板

我在自己的电脑里一直保留一个“最小可用工程”，内容只有点灯、串口 printf、定时器中断三个功能。每次启动新项目，把这个工程复制一份，再往上加外设。这样做的好处是，环境问题在复制那一刻就被隔离了，后面出现的所有报错都是新加代码引入的，排查范围小得多。给别人提问时，提问模板也建议固定：硬件型号（F103C8T6 最小系统板）、工具链（CubeMX 6.x + Keil 5.4 + HAL 库 1.11）、现象（CAN 普通模式发送返回 OK 但收不到）、已做的验证（回环模式收发正常、收发器供电正常、波特率 500k）、原理图关键部分。信息给全，你得到的回答大概率也是可以直接落地的方案，而不是“多半是接线问题”这种车轱辘话。

6.3 最后一点实际体会

我早期调 STM32 时，最爱的动作不是查手册，而是到处找现成代码。踩过几次坑之后，我现在遇到任何新外设，都先花十分钟在 CubeMX 里把 IO、时钟、外设初始化完整走一遍，生成一个最小骨架，再在这个骨架上改逻辑。这个习惯帮我省下的时间，远超过我去论坛翻一百篇经验帖。也希望你从现在开始，别再做那个收藏了无数链接、却连最小工程都跑不起来的收集者。平台和资料永远都在那里，真正拉开差距的，是你愿不愿意从“找一个能用的模板”变成“亲手搭一个自己能改的骨架”。