1. 为什么我决定把 STM32 入门做成"零硬件"方案
很多人第一次接触 STM32 的时候，卡住的地方其实不是代码，而是硬件。开发板要钱、下载器要钱、各种传感器模块要钱，买回来之后还要面对焊接、接线、供电、接触不良这一堆破事。我见过太多人，板子买回来吃灰，因为点个灯都能折腾一星期，最后热情被磨没了。
我当初带一个刚入门的朋友学 STM32，他手头只有一台笔记本，预算有限，也不想一上来就投入几百块买一堆东西。于是我就想，能不能把整个入门流程做成"纯软件"版本——不买板子，不接任何实物，照样把 GPIO、定时器、串口、中断、ADC 这些外设一个个跑通，把该理解的概念都理解透。
答案是完全可以。STM32 的官方生态里本来就有一套仿真机制，配合集成开发环境和调试器，可以在电脑上模拟芯片的运行行为。你写的代码是真的编译成 ARM 指令，跑在模拟的 Cortex-M 内核上，寄存器、内存、外设寄存器都能看到变化。这跟"纸上谈兵"完全是两回事，它是真的在执行。
这篇文章就是把我这套"零硬件入门路线"完整拆开讲。适合谁看？适合预算有限的学生、想先摸清概念再决定要不要买板子的观望者、以及手头板子暂时不在身边但想练手的开发者。我会把工具选型、环境搭建、每个外设怎么在仿真里验证、以及我踩过的坑，全部讲清楚。你跟着做，一台电脑就能把 STM32 的核心外设过一遍。
需要先说明一点：仿真不是万能的，它替代不了真实硬件的全部体验，比如电气特性、时序抖动、真实外设的物理响应。但对于"理解外设工作原理、验证代码逻辑、熟悉寄存器操作"这个阶段的目标，它足够用了。等你把仿真里的外设都跑通，再去碰真板子，上手速度会快很多。
2. 仿真方案的工具选型与背后的取舍逻辑
2.1 为什么是 Keil MDK 加内置仿真器这条路线
市面上能跑 STM32 仿真的方案不止一种，我最终选的是 Keil MDK 配合它自带的仿真调试器。原因很实际：它对 STM32 的外设仿真支持相对完整，尤其是 GPIO、定时器、串口、中断这些入门必学的外设，寄存器视图和逻辑分析窗口都能用。而且它的工程模板成熟，新建工程、选芯片型号、配置时钟树这套流程，跟真实开发几乎一模一样，学到的操作可以直接迁移到真板子上。
另一个常见选择是基于 Eclipse 的免费工具链，但它的仿真外设支持相对弱一些，很多外设寄存器只能看不能"动"，验证起来不够直观。还有纯命令行的模拟器方案，灵活是灵活，但对新手不友好，配置成本高。综合下来，Keil 这条路线对入门者最省心。
注意：Keil MDK 有社区版和商业版的区别，个人学习用途用社区版即可，芯片型号选择上优先挑仿真支持好的经典型号，比如 STM32F103 系列，它的外设仿真资料最全。
2.2 芯片型号怎么挑才不影响仿真体验
选型号这件事，很多人随手挑一个最新的高性能型号，结果发现仿真时外设行为对不上，或者干脆某些外设没法模拟。我的经验是：入门仿真优先选 STM32F103C8 或 STM32F103RB 这类经典款。原因有三点。
第一，这类芯片的外设结构简单清晰，GPIO、TIM、USART、EXTI、ADC 都是标准配置，仿真器对它们的建模最成熟。第二，网上针对这个系列的例程和寄存器手册最多，你遇到问题容易找到参考。第三，它的时钟树不复杂，配置起来不容易出错，适合把注意力放在外设逻辑本身而不是时钟计算的细枝末节上。
如果你非要选高性能型号，也不是不行，但要做好心理准备：某些外设的仿真可能不完整，比如高级定时器的某些互补输出功能、复杂的 DMA 请求映射，仿真里可能看不到预期效果。入门阶段没必要给自己找这个麻烦。
2.3 仿真能覆盖和不能覆盖的边界
这一点我必须提前讲清楚，否则你会在某个环节怀疑人生。仿真能覆盖的：内核指令执行、寄存器读写、GPIO 电平变化、定时器计数与中断触发、串口收发数据、外部中断触发、ADC 采样值注入。这些在仿真里都能验证逻辑对不对。
仿真覆盖不了的：真实引脚上的电气特性、外部器件的物理响应、精确的时序抖动、电源相关的行为、以及依赖外部模拟信号的场景。举个例子，你想验证"按键按下触发中断"这个逻辑，仿真里可以手动触发中断标志位来模拟，但真实按键的抖动、上拉电阻的选型，这些得靠真硬件。
所以我的建议是：把仿真当成"逻辑验证器"和"概念学习器"，而不是"硬件替代品"。心态摆正了，这套方案的价值就出来了。
3. 从零搭建仿真工程：环境准备里最容易翻车的细节
3.1 安装与器件包配置的坑
安装 Keil MDK 本身不复杂，真正容易翻车的是器件支持包（Device Family Pack）的安装。很多人装完主程序，新建工程时发现列表里找不到 STM32F103，就是因为没装对应的器件包。这个包需要单独下载安装，装完之后芯片型号才会出现在选择列表里。
我的操作顺序是：先装主程序，再装器件包，最后确认 Pack Installer 里对应系列显示为已安装状态。如果装完还是找不到型号，多半是版本不匹配，换个稍旧一点的稳定版本通常能解决。这一步别嫌麻烦，器件包没装对，后面全白搭。
3.2 新建工程时的关键选项
新建工程时，选完芯片型号会弹出一个运行时环境管理窗口，问你要不要添加启动代码和中间件。入门阶段，我建议只勾选 CMSIS 核心和启动文件，其他中间件先不碰。原因很简单：中间件会引入额外的依赖和配置，容易让新手在还没搞懂外设之前就被一堆配置文件绕晕。
工程建好后，第一件事是确认目标选项里的调试器设置。在 Debug 标签页里，把调试方式选成软件仿真（Use Simulator），而不是硬件调试器。这一步是"纯软件"方案的核心开关，选错了就会提示找不到硬件。选对之后，你点调试按钮，程序就会在模拟环境里跑起来。
3.3 时钟配置：仿真里也不能偷懒
有个误区是"反正是仿真，时钟随便配配就行"。这个想法很危险。因为定时器、串口波特率这些外设的行为都依赖系统时钟，时钟配错了，仿真里看到的定时周期、波特率全是错的，你验证出来的结论也是错的。
所以即便在仿真里，也要老老实实把系统时钟配置对。以 STM32F103 为例，常见做法是用外部晶振倍频到 72MHz。仿真环境下，你可以在系统初始化代码里按标准流程配置时钟树，然后在调试时查看相关寄存器，确认时钟确实切到了预期频率。这一步做扎实，后面定时器和串口的验证才有意义。
提示：仿真时如果发现定时器周期和理论值对不上，第一件事就是回头查系统时钟配置，八成是这里出了问题，而不是定时器本身。
4. GPIO 与外部中断：在仿真里把"点灯"和"按键"跑通
4.1 GPIO 输出：用寄存器视图看电平翻转
点灯是所有人的第一课，但仿真里的点灯有个好处：你能直接看到寄存器位的变化，理解"写寄存器"和"引脚电平"之间的对应关系。操作上，先配置 GPIO 为推挽输出模式，设置好输出速度，然后在主循环里翻转对应引脚。
跑起来之后，打开外设寄存器视图，找到对应 GPIO 端口的输出数据寄存器，你会看到那一位在 0 和 1 之间跳变。这个直观程度是真实板子给不了的——真板子上你只能看到灯亮灭，看不到寄存器。通过这个练习，你能真正理解"库函数封装背后到底操作了哪个寄存器的哪一位"。
我建议这个阶段刻意用两种方式各写一遍：一次用标准库函数，一次直接操作寄存器。对比着看，你对底层机制的理解会深很多。这也是仿真方案的一个隐藏价值：它逼着你去关注寄存器，而不是停留在调库的层面。
4.2 GPIO 输入与按键消抖的逻辑验证
按键输入在仿真里怎么验证？核心思路是手动改变输入数据寄存器的值，模拟按键按下和松开。你先把某个引脚配置为上拉输入，然后在调试时手动把对应输入寄存器的位清零，就相当于按键被按下。
这里有个值得在仿真里专门练的点：消抖逻辑。真实按键有机械抖动，代码里通常要做延时确认或多次采样。在仿真里，你可以精确地控制"按下"和"松开"的时机，去验证你的消抖逻辑是不是真的能过滤掉短时间的抖动。比如你写一个 20ms 的延时确认，就在仿真里模拟一个持续 5ms 的抖动，看程序会不会误判。这种精确控制，真硬件上反而不好做。
4.3 外部中断的触发与响应验证
外部中断是入门的一个小门槛。配置流程是：把引脚设为输入，配置外部中断触发边沿（上升沿、下降沿或双边沿），使能对应的中断线，然后在中断服务函数里写处理逻辑，最后在中断控制器里使能该中断。
仿真里验证中断，关键是找到中断挂起寄存器。你可以手动置位对应的挂起位，模拟一次外部触发，然后观察程序是否跳进了中断服务函数。如果没跳进去，排查顺序是：中断线配置对不对、中断控制器里使能了没有、优先级设置有没有问题、中断服务函数名字和向量表里的对不对得上。这个排查链路在仿真里走一遍，比在真板子上盲猜高效得多。
注意：中断服务函数的名字必须和启动文件里定义的向量名完全一致，差一个字母都不会进中断。仿真里不进中断时，先核对这个名字。
5. 定时器与串口：仿真中最能体现"时序"价值的两个外设
5.1 定时器计数与中断周期的验证方法
定时器是 STM32 里最核心也最容易配错的外设之一。配置流程大致是：使能定时器时钟、设置预分频器和自动重装载值、配置计数模式、使能更新中断、启动定时器。这里的关键是算清楚定时周期。
计算公式是：定时周期 = (预分频值 + 1) × (自动重装载值 + 1) / 定时器时钟频率。假设定时器时钟是 72MHz，你想要 1ms 的周期，可以设预分频为 71（得到 1MHz 计数频率），自动重装载值为 999，这样每 1000 个计数就是 1ms。这个计算过程一定要自己动手算一遍，别直接抄。
仿真里验证的时候，启动定时器后观察计数寄存器的值在递增，到自动重装载值后归零并触发更新中断。你可以在中断服务函数里翻转一个 GPIO，然后在寄存器视图里看这个 GPIO 是不是按预期周期翻转。如果周期不对，回头检查预分频和重装载值，以及定时器时钟源是不是你预期的那个。
5.2 串口收发的仿真验证思路
串口在仿真里的验证稍微特殊一点，因为真实的收发依赖外部设备。但仿真器通常提供了串口数据的注入和查看功能。配置好波特率、数据位、停止位、校验位之后，你可以在仿真环境里手动往接收寄存器写入数据，模拟"收到一个字节"，看程序的中断或轮询逻辑有没有正确读取。
发送方向，你让程序往发送寄存器写数据，然后在仿真器的串口窗口里看输出的内容对不对。这里最容易出问题的是波特率配置。波特率的计算依赖总线时钟，如果系统时钟配错了，波特率就会偏，仿真里可能表现为数据错乱。所以还是那句话，时钟是根，先把时钟搞对。
我个人的习惯是，串口调试阶段先做回环测试：收到什么就发回什么。这个逻辑简单，但能一次性验证收发两条链路。仿真里把注入的数据和输出的数据一对比，链路通没通一目了然。
5.3 用逻辑分析窗口观察时序关系
Keil 的仿真环境里有个逻辑分析窗口，可以把你关心的引脚加进去，观察它们的电平随时间的变化。这个功能在验证定时器 PWM 输出、多个 GPIO 的时序配合时特别好用。
比如你想验证两路 PWM 的相位关系，或者想看清楚中断触发和 GPIO 翻转之间的时间差，把相关引脚加到逻辑分析窗口里，跑一段时间，波形就出来了。这种"看得见时序"的能力，是纯软件仿真相对真硬件的一个优势——真硬件上你得接逻辑分析仪才能看到，而这里直接内置了。
6. 仿真路线的局限与我踩过的那些坑
6.1 外设仿真不完整导致的"假故障"
我踩过最典型的一个坑，是某个外设的仿真行为跟真实芯片不一致。当时我在验证一个 ADC 采样逻辑，仿真里注入的采样值读出来总是对不上，排查了半天代码，最后发现是这个型号的 ADC 仿真支持本身就不完整。换成另一个仿真支持好的型号，同样的代码就正常了。
这件事给我的教训是：遇到仿真里怎么都调不通的情况，先确认这个外设在当前型号下是不是被完整仿真了。方法很简单，查一下仿真器的外设支持列表，或者换个型号试同样的代码。别一头扎进代码里死磕，有时候问题根本不在你的代码。
6.2 过度依赖仿真带来的认知偏差
另一个坑是心态上的。仿真跑通了，容易产生"我已经掌握了"的错觉。但实际上，真实硬件上还有一堆仿真里遇不到的问题：供电不稳、引脚复用冲突、外部器件时序不匹配、电磁干扰等等。
我的建议是，把仿真阶段的目标定清楚：它的目标是让你理解外设的工作原理和代码逻辑，不是让你成为硬件调试高手。等你把仿真里的外设都跑通，对寄存器操作和中断机制有了实感，再去碰真板子，你会发现上手快很多，因为你已经知道"代码应该怎么跑"，剩下的只是排查硬件层面的问题。
6.3 调试技巧：断点、单步与寄存器观察的配合
仿真调试有个真硬件比不了的优势：你可以随便下断点，不用担心影响实时性，也不用担心把芯片"跑飞"。我的习惯是，在每个外设初始化的关键节点下断点，单步执行，同时盯着寄存器视图看每一位的变化。
比如配置 GPIO 的时候，单步走过每一行配置代码，看模式寄存器、输出类型寄存器、输出速度寄存器是不是按预期被改写。这种"逐行验证"的方式，能让你对库函数到底做了什么有非常清晰的认识。真硬件上你没法这么从容地单步，因为有些外设一旦启动就停不下来。
提示：仿真调试时善用"变量观察窗口"和"寄存器窗口"的组合，把关键变量和对应寄存器放一起看，能快速定位是代码逻辑问题还是配置问题。
7. 从仿真到真板子的平滑过渡建议
7.1 哪些代码可以原样迁移
好消息是，仿真阶段写的绝大部分代码，迁移到真板子上是可以直接用的。GPIO 配置、定时器配置、中断配置、串口配置这些逻辑，只要芯片型号一致，代码基本不用改。你需要的只是把调试方式从软件仿真切换成硬件调试器，然后连上真板子下载运行。
真正需要调整的，往往是那些依赖具体硬件特性的部分，比如外部器件的驱动时序、引脚的实际连接关系。但这些属于"应用层"的适配，核心的外设配置逻辑是通用的。所以你在仿真里练的功夫不会白费。
7.2 迁移时优先验证哪几个外设
我的建议是，迁移到真板子后，按这个顺序验证：先 GPIO 点灯，确认最基本的输出通路没问题；再串口，确认能打印调试信息，这是后续排查的基础；然后定时器，确认时序相关功能正常；最后中断和 ADC 这些相对复杂的外设。
这个顺序的逻辑是：从最简单、最容易观察的外设开始，逐步建立信心，同时把调试通道（串口）先打通，后面遇到问题才有手段排查。如果一上来就搞复杂外设，出了问题你连从哪查都不知道。
7.3 仿真阶段就该养成的工程习惯
最后说几个我觉得在仿真阶段就该养成的习惯，这些习惯迁移到真硬件后会让你少走很多弯路。第一，每个外设单独建一个测试工程，别把所有外设堆在一个工程里，出问题不好定位。第二，配置代码写注释，把关键参数的计算过程写清楚，比如定时周期的计算、波特率的计算。第三，善用条件编译或宏定义管理不同型号的配置差异。
这些习惯在仿真阶段看起来有点"多余"，因为仿真里改起来快。但等你到了真硬件阶段，工程规模一大，这些习惯的价值就体现出来了。我自己就是吃了没养成这些习惯的亏，后来返工重写了不少配置代码。
这套纯软件入门路线，我自己带人走过好几轮，效果是实打实的。它最大的价值不是"省钱"，而是让你在没有硬件干扰的环境里，把外设的工作原理和代码逻辑彻底搞明白。等你真正拿到板子的时候，你面对的不再是"这代码为什么不动"的迷茫，而是"我知道它该怎么动，现在只是把它跑起来"的从容。这个差别，就是入门和没入门的差别。
