1. 为什么我决定把 STM32 入门做成"纯软件"版本
很多人第一次接触 STM32，卡住的地方其实不是代码，而是"板子还没到"。想学 GPIO 点灯，得先下单开发板；想试串口，得先焊好 USB 转 TTL；想调 ADC，还得配个电位器。等快递那几天，热情基本就凉了一半。更别说有些朋友预算有限，或者只是想在正式买板子之前先摸清楚这套东西到底是怎么回事。
我这次做的事情，就是把这整个"等硬件"的环节彻底砍掉。用纯软件的方式，在电脑上把 STM32 的外设一个一个跑通——GPIO、外部中断、定时器、串口、ADC、DMA、PWM，甚至简单的 RTOS 任务调度，全部不依赖任何实物开发板。你需要的只是一台能跑仿真环境的电脑，加上一份愿意折腾的心。
这套方案的核心思路是：用仿真器模拟 MCU 内核和片上外设，用虚拟终端和虚拟仪器替代物理引脚上的 LED、按键、示波器。代码还是那份代码，寄存器还是那些寄存器，只是"世界"从一块 PCB 变成了软件里的一个模型。对于入门阶段来说，这个模型已经足够真实，足够让你把外设的配置逻辑、时序关系、中断流程全部走一遍。
适合谁看？三类人最合适。第一类是零基础、还没买板子、想先确认自己能不能学下去的朋友；第二类是已经买了板子但手头没有示波器、逻辑分析仪，想先把外设原理搞明白再上硬件的；第三类是老手，想找一个不插线、不烧录、改完代码立刻看结果的快速验证环境。这三类人在这套纯软件流程里都能拿到自己想要的东西。
我先把结论放这儿：仿真不能完全替代真机，尤其是涉及模拟信号精度、高速时序、电源完整性的场景。但对于"把外设一个个跑通"这个目标，它完成度非常高，而且省下来的时间和金钱是实打实的。下面我按实际操作的顺序，把整套流程拆开讲。
2. 仿真环境到底模拟了什么，又漏掉了什么
2.1 内核与外设的软件模型是怎么工作的
要理解纯软件方案为什么可行，得先搞清楚仿真器到底在干什么。STM32 这类 MCU 本质上是一个 CPU 内核加上一堆挂在总线上的外设。CPU 执行指令，通过总线读写外设的寄存器，外设根据寄存器的值改变自己的行为，再通过引脚或者中断把结果反馈给 CPU。
仿真器做的事情，就是用一个软件模型去扮演这个 CPU 和这些外设。你写的 C 代码被编译成 ARM 指令，仿真器逐条解释执行这些指令。当指令访问到某个外设的寄存器地址时，仿真器不会真的去读写物理内存，而是调用对应外设模型的处理函数。比如你往 GPIO 的输出寄存器写了个 1，GPIO 模型就把这个引脚的状态标记为高电平，然后通知所有"连接"在这个引脚上的虚拟设备。
这个机制带来的直接好处是：你可以像调试普通 PC 程序一样，在任意一行代码打断点、看变量、单步执行。真机上你只能靠串口打印和 LED 猜，仿真里你可以直接看到寄存器每一位的变化。对于理解外设配置流程，这个能力比真机强太多。
2.2 哪些外设能跑，哪些跑起来会失真
不是所有外设都适合在仿真里玩。我把常见外设分了个类，方便你判断哪些值得在软件阶段花时间。
| 外设类型 | 仿真支持程度 | 说明 |
|---|---|---|
| GPIO 输入输出 | 很好 | 电平状态完全可观测，适合点灯、按键逻辑 |
| 外部中断 EXTI | 很好 | 可以手动触发中断，验证中断服务函数 |
| 定时器 TIM | 较好 | 计数、PWM 输出可模拟，高频场景时序有偏差 |
| 串口 UART | 很好 | 可对接虚拟终端，收发数据完整 |
| ADC | 一般 | 能读寄存器，但模拟量输入需要手动注入 |
| DMA | 较好 | 传输流程可验证，带宽相关场景失真 |
| SPI/I2C | 一般 | 主机模式可跑，从机设备需要额外建模 |
| USB/CAN | 较差 | 协议栈复杂，仿真模型不完整 |
看这张表你就明白了：数字逻辑类外设（GPIO、中断、串口、定时器）在仿真里几乎和真机一样好用，模拟类和高速总线类外设则要打折扣。入门阶段重点恰恰就是数字逻辑类，所以这个匹配度非常高。
2.3 仿真和真机的边界在哪里
我踩过的一个坑是：在仿真里把 ADC 采样跑得特别顺，结果上真机发现读数一直在跳。原因很简单，仿真里的 ADC 输入是我手动写死的理想值，真机上电源纹波、参考电压漂移、走线干扰全都会影响结果。这不是仿真错了，是我对"仿真通过"这件事的理解错了。
所以我的经验是：仿真用来验证"逻辑对不对"，真机用来验证"电气行不行"。配置流程、中断优先级、状态机跳转这些逻辑问题，仿真里查得又快又准；而信号质量、驱动能力、功耗这些电气问题，必须上真机。把这两件事分清楚，你就不会对仿真产生不切实际的期待，也不会因为真机上的一点小问题就否定整个软件阶段的价值。
3. 从零搭起一套能跑外设的仿真工程
3.1 工具链的选择与安装顺序
纯软件方案的工具链其实不复杂，核心就三样：一个能编译 ARM 代码的编译器、一个能模拟 MCU 的仿真器、一个能看结果的虚拟终端或调试界面。我用的组合是开源工具链，全部免费，跨平台也能跑。
安装顺序有讲究，我建议按这个来：
- 先装 ARM 交叉编译工具链，确保
arm-none-eabi-gcc能在命令行里跑起来。装完敲一下arm-none-eabi-gcc --version，有版本号输出才算成功。 - 再装仿真器本体。这一步要注意版本，太老的版本对新款 MCU 的外设模型支持不全。
- 最后配调试前端。如果你习惯命令行，直接用仿真器自带的 GDB 接口就行；如果喜欢图形界面，可以接一个支持 GDB 的 IDE。
注意：安装路径里尽量不要有中文和空格，交叉编译工具链对路径里的特殊字符很敏感，这是很多人第一步就卡住的原因。
3.2 工程目录怎么组织才不乱
入门阶段最容易犯的错，是把所有文件堆在一个目录里。跑通一个外设还行，跑到第五个外设的时候，你自己都分不清哪个文件是干嘛的。我建议从一开始就按下面的结构组织：
project/ ├── startup/ # 启动文件、链接脚本 ├── drivers/ # 外设驱动，一个外设一个文件 │ ├── gpio.c │ ├── uart.c │ └── tim.c ├── app/ # 应用逻辑，main 在这里 ├── common/ # 公共头文件、宏定义 └── build/ # 编译输出，不纳入版本管理这个结构的好处是，每个外设的配置代码独立成文件，你想单独验证某个外设时，只要在 main 里调用对应的初始化函数就行，不会互相干扰。等你后面上真机，这套目录结构可以直接复用，驱动文件几乎不用改。
3.3 链接脚本和启动文件的关键改动
这是纯软件方案里最容易被忽略、又最容易出问题的一环。真机上链接脚本描述的是 Flash 和 RAM 的物理地址，仿真里这些地址是模型约定的，必须和仿真器的内存映射对上。
具体来说，你要确认两件事：Flash 起始地址和大小、RAM 起始地址和大小。这两个值在仿真器的文档里能查到，把它们填进链接脚本的 MEMORY 段。启动文件里的向量表位置也要和链接脚本一致，否则中断一来就飞了。
我当时的做法是，先拿一个官方模板工程，把链接脚本里的地址改成仿真器要求的值，编译一次看能不能正常加载。能加载之后再动别的。这个顺序很重要，先保证"能跑起来"，再保证"跑得对"，不然你会在链接错误里耗掉一整天。
4. GPIO 与外部中断：第一个能看见结果的外设
4.1 点灯逻辑在仿真里怎么"看见"
真机点灯，你看的是板子上那颗 LED。仿真里没有 LED，那怎么确认 GPIO 配置对了？答案是看引脚状态。仿真器通常提供一个虚拟引脚监视窗口，你能看到每个 GPIO 端口的每一位当前是高还是低。
配置流程和真机完全一样：使能 GPIO 时钟、设置引脚为推挽输出、设置速度、然后往输出寄存器写值。写完之后，在监视窗口里找到对应的引脚，看它有没有跟着变。变了，说明你的时钟使能、模式配置、寄存器操作这一整条链路都是通的。
这里有个细节值得说：很多人点灯失败，问题出在时钟没使能。真机上你还能靠"灯不亮"这个现象去猜，仿真里你可以直接在时钟使能寄存器上打断点，看那一位置没置起来。这种"看得见内部状态"的调试体验，是仿真最大的价值之一。
4.2 按键输入与消抖的软件验证
按键比点灯多一层：你要读输入。仿真里读输入的方式是手动改变引脚电平，模拟按键按下和松开。这个操作在虚拟引脚窗口里点一下就行，比真机上还要焊按键、接上拉电阻方便得多。
消抖逻辑是这里的重点。真机上按键抖动是物理现象，仿真里没有真实抖动，但你可以手动制造抖动——快速连续切换引脚电平，看你的消抖代码能不能正确识别出一次有效按下。我当时的做法是写一个循环，每 1 毫秒翻转一次引脚，持续 20 毫秒，模拟一次带抖动的按键。如果你的消抖逻辑写对了，最终只会触发一次事件；写错了，就会触发好几次。
提示：消抖时间不要照抄别人的 20 毫秒。机械按键的抖动时间跟按键型号有关，5 到 50 毫秒都常见。仿真阶段你可以随便试，但上真机前一定要用实际按键测一遍。
4.3 外部中断的触发与优先级验证
外部中断是 GPIO 的进阶用法。仿真里触发中断有两种方式：一是手动改变引脚电平，二是直接在调试器里调用中断触发函数。我推荐第一种，因为它更接近真机的行为。
配置中断的流程是：配置引脚为输入、设置触发边沿（上升沿、下降沿或双边沿）、配置 NVIC 使能对应的中断线、写中断服务函数。跑起来之后，在中断服务函数里打个断点，然后手动翻转引脚，看断点有没有命中。
优先级验证是仿真比真机强的地方。真机上你想验证两个中断的抢占关系，得用示波器看两个引脚的时间差。仿真里你可以直接看 NVIC 的寄存器状态，看高优先级中断有没有正确抢占低优先级中断。中断嵌套这种容易出错的地方，在仿真里验证一遍，上真机基本不会翻车。
5. 定时器、PWM 与串口：把时序类外设跑明白
5.1 定时器计数的观测方法
定时器是 STM32 里最灵活也最复杂的外设之一。仿真里验证定时器，核心是看计数器的值有没有按预期变化。你可以配置一个基本定时器，预分频和自动重装载值设好，启动之后在调试器里观察计数寄存器。
这里有个计算要搞清楚：定时时间 = (预分频值 + 1) × (自动重装载值 + 1) / 时钟频率。比如时钟 72 兆赫兹，预分频 7199，重装载 9999，那定时就是 (7199+1)×(9999+1)/72000000 = 1 秒。仿真里你可以把这三个值改一改，看计数周期是不是跟着变，这样对公式的理解会比死记硬背深得多。
5.2 PWM 输出的占空比验证
PWM 本质上是定时器的一个输出比较功能。仿真里验证 PWM，看的是输出引脚的高低电平切换。你设一个 50% 占空比，理论上引脚应该一半时间高、一半时间低。在虚拟引脚窗口里，你能看到这个切换过程。
更严谨的验证方式是在定时器的比较中断里记录时间戳，算一下高电平持续时间和总周期的比值，看是不是等于你设的占空比。这个方法在仿真里很好用，因为你可以精确读到每次中断的时刻。真机上你要么用逻辑分析仪，要么用输入捕获，都比仿真麻烦。
5.3 串口收发对接虚拟终端
串口是我认为仿真体验最好的外设。仿真器一般支持把 UART 的数据重定向到虚拟终端或者文件，你printf出来的东西能直接在终端里看到，你从终端输入的东西也能被 MCU 收到。
配置串口的流程：使能时钟、配置引脚复用、设置波特率、数据位、停止位、校验位、使能收发。跑起来之后，在虚拟终端里敲字符，看 MCU 能不能收到并回显。这个"发出去能看见、收进来能处理"的闭环，在真机上要接 USB 转 TTL 才能实现，仿真里开个终端就搞定。
注意：波特率在仿真里通常不影响功能，因为数据是软件搬运的，不存在真实采样。但上真机前一定要按实际时钟重新算一遍波特率寄存器，仿真里能通不代表真机上能通。
6. ADC、DMA 与 RTOS：进阶外设的仿真取舍
6.1 ADC 采样值的注入与读取
ADC 在仿真里的尴尬之处在于，它需要一个模拟输入，而软件里没有真实的电压。解决办法是手动注入采样值。大多数仿真器允许你为 ADC 的某个通道设定一个固定的数字量，MCU 读的时候就会读到这个值。
这个机制用来验证"读取流程"是够的：启动转换、等待转换完成标志、读数据寄存器、做换算。整条链路你都能跑通。但如果你想验证"采样精度""参考电压稳定性"这些，仿真给不了你答案，必须上真机。
我的建议是，ADC 在仿真阶段只验证配置和读取逻辑，精度相关的实验留到真机。这样既省时间，又不会对仿真结果产生误判。
6.2 DMA 传输流程的验证思路
DMA 的价值是"不占 CPU 搬运数据"。仿真里验证 DMA，重点看两件事：传输有没有发生、传输完成后中断有没有触发。
你可以配置 DMA 把一段内存的数据搬到外设数据寄存器，或者反过来。启动之后，在调试器里看源地址和目标地址的内容有没有按预期变化。传输完成中断里打个断点，看有没有命中。这两点都对了，说明你的 DMA 配置逻辑是通的。
带宽相关的场景，比如高速 ADC 连续采样加 DMA 搬运，仿真里会因为模型简化而失真。这类场景我建议直接上真机，仿真阶段把配置流程走通就够了。
6.3 在仿真里跑一个最小 RTOS 任务调度
RTOS 在仿真里跑，其实比裸机更能体现价值。因为任务切换、优先级、信号量这些机制，在仿真里你可以通过断点和变量观察得一清二楚。
我当时的做法是创建两个任务，一个高优先级、一个低优先级，高优先级任务里加个延时让出 CPU，看低优先级任务能不能得到执行。然后在任务切换的地方打断点，看栈指针和任务控制块有没有正确切换。这种"看得见调度过程"的体验，对理解 RTOS 原理帮助极大，真机上你只能靠打印日志猜。
7. 从仿真到真机，我踩过的几个坑
7.1 时钟配置在仿真里"太顺"的陷阱
仿真器对时钟树的建模往往比较理想化，你配置完 PLL，它立刻就是稳定的。真机上 PLL 锁定需要时间，时钟切换也有过渡过程。我在仿真里跑得好好的代码，上真机偶尔会卡在时钟就绪等待那一步。
经验是：仿真阶段就要把时钟就绪的等待逻辑写完整，不要因为仿真里"秒过"就省略。while(!(RCC->CR & RCC_CR_PLLRDY));这种等待，仿真里可能一次就过，真机上可能要循环几百次，但逻辑必须在那儿。
7.2 中断优先级在仿真与真机上的差异
仿真器对中断优先级的处理通常是准确的，但真机上还有硬件层面的优先级分组、中断延迟等因素。我在仿真里验证过的抢占关系，上真机大体一致，但极端情况下（比如两个中断几乎同时到达）行为会有细微差别。
所以我的做法是：仿真里验证优先级的逻辑正确性，真机上用实际场景压测。两者结合，才能既保证逻辑对，又保证实际稳。
7.3 那些仿真永远测不出来的问题
有些问题注定只能在真机上暴露：电源纹波导致的复位、引脚驱动能力不足导致的信号畸变、PCB 走线引起的串扰、温度变化导致的时钟漂移。这些都不是仿真的锅，是物理世界的固有属性。
认清这一点，你就不会在仿真里死磕这些测不出来的东西。仿真的边界就是逻辑，物理的问题交给真机。把精力分配好，入门阶段的效率会高很多。
8. 我个人的一点使用体会
这套纯软件方案我用了挺长时间，最大的感受是：它把"学 STM32"这件事的门槛从"买板子"降到了"装软件"。很多人在等板子的那几天里热情消退，或者因为一块板子几十上百块而犹豫，这套方案直接把这个障碍拿掉了。
但它不是万能药。我见过有人仿真里跑得飞起，上真机连点灯都点不亮，原因是他从来没关心过引脚的实际电气特性。所以我的建议是：仿真用来打基础、验证逻辑、快速试错，真机用来验证电气、积累手感、建立对硬件的直觉。两者不是替代关系，是先后关系。
如果你现在手头没板子，或者想先确认自己能不能学下去，那就从这套纯软件流程开始。把 GPIO、中断、定时器、串口这几个外设跑一遍，你会对 STM32 的配置逻辑有一个非常扎实的理解。等你拿到真板子的时候，你会发现那些寄存器操作你已经很熟了，剩下的只是把代码烧进去而已。
最后分享一个小技巧：仿真阶段就把代码按驱动分层写好，上真机时只改时钟和引脚相关的宏定义。这样你的仿真工程和真机工程能共用绝大部分代码，切换成本极低。我自己就是这么干的，从仿真到真机，改动量不到百分之五。
