1. 为什么我决定把 STM32 入门做成"零硬件"方案
刚接触 STM32 那会儿，我做的第一件事不是看手册，而是打开购物软件挑开发板。选型、比价、等快递、焊排针、装驱动，一套流程走下来，热情已经消耗掉一半。更让人头疼的是，板子到手后经常遇到各种意外：USB 线接触不良、串口驱动装不上、某个外设引脚被板载电路占用、烧录器固件版本不匹配。这些问题跟"学 STM32"本身没有半点关系，却实实在在地劝退了不少人。
后来我在带新人的过程中反复思考一个问题：入门阶段真正需要的是什么？是那块 PCB 吗？显然不是。入门阶段需要的是理解时钟树怎么配、GPIO 怎么翻转、中断怎么进、定时器怎么计数、串口怎么收发这些核心机制。而这些机制，完全可以在纯软件环境里跑通。于是我开始尝试用仿真工具搭一套"零硬件"的 STM32 学习流程，把常见外设一个个在电脑上跑起来，验证逻辑、观察寄存器、调试代码，全程不花一分钱买板子。
这套方案的核心思路是：用仿真器模拟 MCU 内核和片上外设，用虚拟终端和虚拟仪器观察运行结果。它不能完全替代真实硬件，但在入门阶段，它能让你把 80% 的基础概念吃透，而且调试体验甚至比真板子更舒服——你可以随时暂停、单步、查看任意寄存器的值，不用担心把板子烧了。
这篇文章我会把这套流程完整拆开讲：工具怎么选、环境怎么搭、每个外设怎么跑通、哪些地方仿真和真机会有差异、哪些坑我踩过。适合完全没有硬件、预算有限、或者想先把原理搞明白再上手的同学。如果你手里已经有板子，这套流程同样可以作为"写代码前的预演"，先在仿真里把逻辑调通，再烧到真机上，效率会高很多。
2. 仿真方案的工具选型与取舍逻辑
2.1 为什么是"内核仿真 + 外设模型"这条路
STM32 的仿真方案大致分两类。一类是指令级仿真，只模拟 Cortex-M 内核的指令执行，外设需要你自己写桩函数；另一类是带外设模型的系统级仿真，内核和外设都有对应的行为模型，代码跑起来能看到真实的外设响应。入门阶段显然要选第二类，否则你写个 GPIO 翻转，仿真里什么都看不到，等于白跑。
我最终选定的组合是Keil MDK 自带的 Simulator + 逻辑分析仪窗口 + 虚拟串口终端。理由很直接：Keil 的 Simulator 对 STM32 主流型号（F1、F4 系列）的片上外设支持比较完整，GPIO、定时器、串口、SPI、I2C、ADC 都有对应的行为模型，而且它内置了逻辑分析仪，可以把引脚电平、寄存器变化以波形形式画出来。这意味着你写GPIO_SetBits，能在波形窗口里看到引脚真的拉高了，这种"看得见"的反馈对入门极其重要。
另一个备选是Proteus，它能仿真整个电路，连 LED、数码管、按键都能画出来，视觉上更直观。但 Proteus 的 STM32 模型在时序精度和中断响应上跟真实芯片有差距，而且它的强项是"电路级"仿真，对寄存器级调试的支持不如 Keil。我的建议是：先用 Keil Simulator 把寄存器和外设逻辑搞明白，等要验证电路连接时再考虑 Proteus。两者定位不同，不冲突。
2.2 版本选择上容易忽略的细节
Keil MDK 的版本对仿真支持影响很大。老版本（比如 MDK4）的 Simulator 对 F4 系列支持不完整，有些外设模型是缺失的。我实测下来，MDK5.30 以上版本对 STM32F103 和 STM32F407 的仿真支持比较稳。安装的时候有个坑：默认安装可能不带对应器件的 Device Family Pack（DFP），你需要手动在 Pack Installer 里把目标芯片的 DFP 装上，否则新建工程时找不到器件，仿真自然也无从谈起。
还有一个细节是仿真精度设置。Keil 的 Simulator 默认是按指令周期推进的，但如果你开了过高的优化等级，编译器可能把一些"看起来没用"的代码优化掉，导致仿真行为和预期不符。入门阶段我建议优化等级设为 -O0，虽然代码体积大一点，但每一步执行都跟源码对应，调试时不会出现"断点跳来跳去"的诡异现象。
2.3 不买板子到底能跑通哪些外设
这里必须说清楚边界，避免误导。根据我的实测，下面这些外设在 Keil Simulator 里能跑通核心逻辑：
| 外设 | 仿真支持程度 | 能验证什么 | 不能验证什么 |
|---|---|---|---|
| GPIO | 完整 | 电平翻转、输入读取 | 实际驱动能力、外部电路 |
| 外部中断 | 完整 | 中断触发、优先级 | 真实抖动、边沿质量 |
| 定时器 | 完整 | 计数、PWM、输入捕获 | 时钟精度偏差 |
| 串口 USART | 完整 | 收发逻辑、中断 | 实际波特率误差 |
| SPI | 完整 | 主机时序、数据收发 | 从机真实响应 |
| I2C | 部分 | 主机时序 | 总线仲裁、从机时序 |
| ADC | 部分 | 转换流程、中断 | 真实模拟量输入 |
| DMA | 部分 | 传输流程 | 总线竞争 |
看这张表就明白了：数字外设的仿真支持普遍好于模拟外设。入门阶段重点就是数字外设，所以这套方案完全够用。ADC 和 DMA 这类，仿真能帮你把配置流程和中断逻辑跑通，但真实精度和时序还得上真机验证。
3. 从零搭建仿真工程的完整操作链路
3.1 新建工程时那几个必须改的配置
打开 Keil，新建工程，选器件。这里有个关键点：选型要选仿真支持好的型号。我一般用 STM32F103C8 或 STM32F407VG，这两个型号的仿真模型最完整。选完器件后会弹出"是否添加启动文件"，选"是"，Keil 会自动把startup_stm32f10x.s之类的启动文件加进来。
接下来是重头戏——Target 选项里的 Debug 配置。点开 Options for Target，切到 Debug 标签页，右上角的下拉框里要选"Use Simulator"，而不是默认的 ST-Link 或 J-Link。这一步如果选错，点调试会提示找不到硬件。选好 Simulator 后，旁边的 Settings 里可以配置仿真参数，我一般把 Dialog DLL 保持默认，Parameter 里填-pSTM32F103C8（对应你的型号）。
还有一个容易被忽略的地方：Utilities 标签页里的"Use Debug Driver"要取消勾选，否则它会尝试调用烧录器。入门阶段我们只仿真，不烧录，这个勾留着只会添乱。
3.2 让波形窗口显示你要看的引脚
工程建好后，先写一个最简单的 GPIO 翻转程序验证环境。代码大概是这样：
#include "stm32f10x.h" void delay(volatile uint32_t count) { while(count--); } int main(void) { RCC->APB2ENR |= RCC_APB2ENR_IOPCEN; // 使能 GPIOC 时钟 GPIOC->CRH &= ~(0xF << 20); // 清 PC13 配置位 GPIOC->CRH |= (0x2 << 20); // PC13 推挽输出，2MHz while(1) { GPIOC->ODR ^= (1 << 13); // 翻转 PC13 delay(100000); } }这段代码直接操作寄存器，不依赖标准库，仿真起来最干净。编译通过后点调试按钮进入仿真模式。这时候默认界面看不到引脚波形，需要手动打开逻辑分析仪：菜单View → Analysis Windows → Logic Analyzer。
打开后是空的，点左上角的"Setup"按钮，在弹出的窗口里点"New"，输入你要观察的信号。这里有个关键技巧：输入PORTC.13而不是PC13。Keil 的逻辑分析仪识别的是"端口.位"这种格式，写错了它不认。添加完关掉窗口，全速运行，你就能看到 PC13 的方波了。
如果波形是平的，先检查三件事：时钟有没有使能、引脚配置对不对、delay 循环是不是被优化掉了。我踩过的坑是 delay 函数没加volatile，编译器直接把整个循环优化没了，波形自然不动。
3.3 用虚拟串口终端观察收发数据
串口是入门阶段最重要的调试手段，仿真里也能用。配置好 USART1 后，在代码里调用发送函数，然后需要在 Keil 里打开虚拟终端。路径是View → Analysis Windows → UART #1（对应你用的串口）。
这里有个细节：Keil 的虚拟串口窗口需要你在代码里正确配置波特率，它才能按对应速率解析数据。如果你配的是 115200，窗口里也要确认显示的是这个速率。发送的数据会以字符形式显示在窗口里，接收的话可以在窗口下方的输入框里打字，模拟从机发来的数据。
我实测下来，虚拟串口对中断收发的支持很好。你可以写一个串口接收中断，然后在虚拟终端里输入字符，观察中断是否触发、数据是否正确存入缓冲区。这个流程跟真机几乎一致，非常适合练手。
4. 逐个外设跑通时踩过的真实坑
4.1 GPIO 仿真里"看不见"的输入
GPIO 输出好验证，波形一看就知道。但 GPIO 输入在仿真里怎么模拟？这是很多人卡住的地方。真机上你按个按键引脚就变了，仿真里没有物理按键。
解决办法是用 Keil 的"信号函数"或者直接改寄存器。在仿真模式下，打开Peripherals → General Purpose I/O → GPIOC，会弹出一个寄存器查看窗口。你可以手动勾选某个输入引脚对应的位，模拟外部电平变化。比如你把 PC0 配置成上拉输入，然后在窗口里把 IDR 的 bit0 清零，就相当于按键按下（拉低）。
这个操作在调试输入逻辑时特别有用。你可以写一个"检测 PC0 低电平就点亮 PC13"的程序，然后在寄存器窗口里手动改 IDR，观察 PC13 是否响应。整个过程不需要任何硬件，逻辑验证得清清楚楚。
注意：手动改 IDR 只在仿真暂停时生效，全速运行时改不了。所以验证输入逻辑时，建议单步执行或者在断点处修改。
4.2 定时器中断的仿真时序偏差
定时器是入门的一个坎，仿真里跑定时器中断有个必须知道的事实：仿真时间跟真实时间不是一回事。Keil Simulator 是按指令周期推进的，如果你的代码里有大量空循环，仿真里的"1 秒"可能要跑很久才到。所以你在仿真里看到中断每隔"一段时间"触发，这个时间跟真机的实际时间对不上，但中断触发的次数和逻辑顺序是对的。
我一般这样验证定时器：配置好预分频和重装载值，在中断里翻转一个引脚，然后用逻辑分析仪看波形。重点不是看周期是不是精确的 1ms，而是看波形是否均匀、中断是否稳定触发、有没有丢中断。逻辑对了，烧到真机上时间自然就准了。
还有个坑：仿真里定时器的时钟源默认是内部时钟，但如果你配置了外部时钟源，仿真可能不响应。入门阶段建议先用内部时钟，把定时器逻辑跑通再说。
4.3 串口中断里那个"收不完"的字节
写串口接收中断时，我在仿真里遇到过一个诡异现象：发送一个字符，中断进去了，但读出来的数据不对，或者中断反复触发。排查了半天，发现是没有清中断标志。真机上如果不清标志，中断会一直触发；仿真里行为一致，但因为看不到硬件，容易误以为是仿真器的问题。
正确的做法是在中断服务函数里，读 DR 寄存器（读操作本身会清 RXNE 标志），或者手动清标志位。这个细节在真机和仿真里是一样的，仿真反而帮你把这个习惯养成了。
另外，仿真里的串口没有真实的波特率误差，所以你不会遇到真机上那种"波特率不匹配导致乱码"的问题。这算是个好事，让你先专注逻辑，等上真机再处理时钟精度。
4.4 SPI 主机时序的观察方法
SPI 在仿真里能跑，但观察起来需要点技巧。因为 SPI 是同步通信，光看数据不够，还要看时钟极性、相位对不对。我的做法是：把 SCK、MOSI、NSS 三个引脚都加到逻辑分析仪里，然后发送一个字节，看波形。
重点看三件事：NSS 是否在传输期间拉低、SCK 的边沿是否在数据稳定时采样、MOSI 上的数据位顺序对不对。这三样对了，SPI 主机逻辑就没问题。仿真里没有从机响应，所以 MISO 是空的，这个正常，不用纠结。
我踩过的坑是CPOL 和 CPHA 配反了，波形一看就发现采样边沿不对。真机上这种错误可能表现为"数据偶尔对偶尔错"，很难查；仿真里波形一画，一眼就看出来了。这就是仿真调试的优势。
5. 仿真与真机的差异清单及应对策略
5.1 哪些差异可以忽略，哪些必须上真机
用仿真入门，心里要有一本账：哪些东西仿真说了算，哪些必须真机验证。我整理了一份对照清单：
| 差异点 | 仿真表现 | 真机表现 | 应对策略 |
|---|---|---|---|
| 时钟精度 | 理想时钟 | 有偏差 | 时序敏感场景上真机 |
| 中断延迟 | 固定周期 | 受优先级影响 | 复杂中断嵌套上真机 |
| 模拟量 | 手动设值 | 真实波动 | ADC 精度必须真机验证 |
| 电源相关 | 无 | 有纹波、复位 | 低功耗、复位电路上真机 |
| 外部器件 | 无响应 | 真实时序 | 通信协议对端上真机 |
看这张表就清楚了：逻辑层面仿真靠谱，物理层面真机靠谱。入门阶段我们练的是逻辑，所以仿真够用。等你把 GPIO、中断、定时器、串口这些逻辑都跑通了，再上真机，你会发现上手速度快很多，因为该踩的逻辑坑已经在仿真里踩完了。
5.2 从仿真迁移到真机时的注意事项
当你决定上真机时，代码基本不用大改，但有几个地方要调整。首先是启动文件和时钟配置，仿真里时钟是理想的，真机上要确保外部晶振起振、PLL 锁定。其次是延时函数，仿真里的空循环延时在真机上时间完全不同，建议换成 SysTick 或者定时器延时。
还有就是调试方式，仿真里用 Simulator，真机上要切回 ST-Link 或 J-Link，并且要重新配置 Debug 标签页。这个切换别忘了，否则点调试会报错。
我的建议是：仿真工程和真机工程分开建，共用同一套外设驱动代码，只是 Debug 配置和时钟初始化不同。这样两边互不干扰，迁移时只改配置不改逻辑。
6. 把这套流程变成可复用的学习模板
6.1 一个外设一个工程的组织方式
入门阶段最忌讳把所有外设塞进一个工程，代码越写越乱，出了问题不知道是哪块的。我的做法是一个外设一个独立工程，比如01_GPIO_Blink、02_EXTI_Key、03_TIMER_PWM、04_USART_Echo，每个工程只验证一个外设的核心功能。
这样做的好处是：每个工程都足够小，编译快、调试快、出问题好定位。而且当你回头复习某个外设时，直接打开对应工程就行，不用在一堆代码里翻找。等所有外设都跑通了，再建一个综合工程把它们串起来，做一个"仿真版的小项目"，比如用定时器控制 LED 闪烁、用串口接收命令改变闪烁频率，这样就把多个外设的联动也练了。
6.2 用仿真验证代码逻辑的日常习惯
养成一个习惯：写任何外设代码之前，先在仿真里把逻辑跑通。比如你要写一个按键消抖，先在仿真里用寄存器手动模拟按键抖动，看你的消抖逻辑能不能正确识别。逻辑对了，再上真机，真机上只需要处理电气层面的问题（比如上拉电阻、去抖电容），软件逻辑已经验证过了。
这个习惯能帮你省下大量时间。真机调试最耗时的往往不是逻辑错误，而是"逻辑对但硬件不配合"的排查。仿真先把逻辑错误排除掉，真机上就只剩硬件问题了，排查范围小很多。
6.3 后续可以扩展的方向
这套仿真流程跑通基础外设后，还能往几个方向扩展。一是上 RTOS，很多 RTOS 支持在仿真环境里跑，你可以观察任务调度、信号量、消息队列的行为，不用真机就能理解 RTOS 的核心机制。二是协议栈仿真，比如把 Modbus、CAN 这类协议的收发逻辑在仿真里跑通，验证帧格式和状态机。三是配合单元测试，把外设驱动写成可测试的模块，在 PC 上跑单元测试，仿真环境只负责验证硬件相关部分。
我个人在实际操作中的体会是：仿真不是"退而求其次"的方案，而是一种更高效的入门路径。它把硬件的不确定性暂时屏蔽掉，让你专注在代码逻辑和寄存器操作上。等你把这些吃透了，再上真机，你会发现那些曾经让你头疼的硬件问题，其实都只是"配置问题"，而不是"理解问题"。这个顺序反过来，先被硬件劝退，再回头补逻辑，效率会低很多。
最后分享一个小技巧：仿真调试时，善用断点 + 寄存器窗口 + 逻辑分析仪这三件套。断点让你停在关键位置，寄存器窗口让你看清每个位的状态，逻辑分析仪让你看到时序关系。这三样配合起来，比真机上"盲调"舒服太多。等你习惯了这种"全透明"的调试方式，再回到真机，你会发现自己对代码的掌控力上了一个台阶。
