企业官网建设流程全解析

很多人一听“学 STM32”，第一反应就是先买块开发板，再配个 ST-Link 下载器，再算上杜邦线、传感器、面包板，一套下来少说也要百来块。我以前也这么干过，板子还在快递柜里躺着的时候，我盯着网上的点灯教程干瞪眼。后来我换了个思路：把整个入门过程改成“纯软件”版本，用 STM32 仿真环境在电脑上把外设一个个跑通。一个月下来，GPIO、串口、定时器、ADC 这些入门必碰的外设，我全都过了一遍，全程没花一分钱在硬件上。这篇文章就是把我走过的这条纯仿真路线完整记录下来，包括工具怎么选、工程怎么搭、每个外设到底怎么“看着”它跑，以及哪些坑替我省了快递费、哪些坑又让我差点误入歧途。

我写这篇东西前也想过：市面上教程大多默认你有板子，或者默认你舍得买板子，但实际上很多人可能只是下班后想先试试水，或者学生党暂时凑不出预算。纯软件方案的好处是零成本、低门槛、随时能开搞，而且等你真的拿到板子之后，前面通过仿真建立起来的寄存器概念、HAL 库调用逻辑、调试思路都能直接平移过去。所以这篇不只写给“买不起板子的人”，也写给“还没决定要不要买板子的人”——先花一个晚上跑通一个外设，再决定这门技术值不值得继续投入，这个决策成本几乎可以忽略不计。

1. 为什么不买板子，我先选了“纯仿真”路线

1.1 仿真能解决学习前期的绝大多数问题

STM32 入门前期的核心任务，说穿了就三件事：会配置时钟、会操作外设寄存器、会读懂程序执行流程。这三件事都不依赖真实硬件。程序编译完，扔进仿真器里，芯片内部发生的事情——哪些寄存器被写了、哪些位被置位了、中断服务函数有没有被正确调用——全都可以在调试窗口里看得清清楚楚。

举个例子。你在真板上点灯，看到的是引脚电平变了，LED 亮了。这当然很有成就感，但你其实看不到背后发生了什么。你只知道程序跑到HAL_GPIO_WritePin之后灯亮了，至于 GPIO 的 ODR 寄存器、BSRR 寄存器是怎么变的，你是“黑盒”观察。而仿真器把这些都摊开了，点灯代码一执行，外设寄存器窗口里GPIOB->ODR第 0 位立刻变成 1，你还能单步执行，看它是一步一步怎么改过来的。这种对“寄存器操作”的直观理解，恰恰是很多人在真板上学了很久都没建立起来的。

仿真能不能完全替代真板？不能，这点后面我会专门花一整节讲。但作为入门阶段的学习工具，它割了很大一块肉下来：HAL 库函数调用、外设初始化流程、中断优先级配置、程序逻辑调试，这些占入门学习量七八成的内容，仿真器都消化得了。

1.2 我判断该不该上真板的三个标准

不是说建议所有人永远不买板子，而是要在合适的时间买。我自己在决定动手前，给自己列了三条判断标准，符合任何一条，就该认真考虑买硬件；一条都不符合，那就安心先玩仿真。

第一，学习目标是“理解外设原理”还是“做产品”。前者完全可以靠仿真，后者必须上真板。因为做产品要面对的是电源设计、布线和真实总线时序，这些是仿真给不了的。第二，有没有明确要接的外部设备。如果你要驱动一块真实 OLED 屏幕、读取真实温湿度传感器的数据，那必须买板子，因为仿真器里的传感器模型和真实世界的传感器差距巨大。第三，时间预算和沉没成本。如果你手头已经有板子，那就直接上板子，不要把板子扔一边非要用仿真；如果还没有板子，又急着先看看这玩意儿是什么味，仿真就是最快的一条路。

我当时三条全占“不用买”，因为那段时间我只是想把 HAL 库的调用流程搞明白，没有任何真实外设要接。所以我花了三个月时间，前一个月用纯仿真把外设跑熟，后两个月才买板子做实物，摸底效率比一上来就买板子高了不少。

2. 纯软件环境搭建：工具组合与冷启动

2.1 三套方案的对比和我的选择

“纯软件”不等于“随便装个软件就能跑”。市面上的 STM32 仿真方案大致分成三类，我先把它们的底细摸了一遍，才选定自己的组合。

第一类是 IDE 自带的软件模拟器，最典型的就是 Keil MDK 里的 Simulator 功能。它不依赖任何硬件调试器，直接在 PC 上模拟 Cortex-M 处理器的执行过程，外设寄存器都能访问，还能用逻辑分析仪查看引脚波形。优势是零额外安装，和日常编译调试环境完全打通；劣势是模拟不了外部电路，你只能看到 MCU 内部，看不到芯片外面的世界。

第二类是电路级仿真软件，最常用的是 Proteus。它把 MCU 模型和外围电路元器件都做成了虚拟模型，你可以把一个 STM32、一个电阻、一个 LED 用虚拟导线连起来，通电看现象。优势是“看起来像真板”，虚拟示波器、虚拟终端都有；劣势是模型精度有限，跑复杂外设容易慢，而且部分外设模型有兼容性问题。

第三类是系统级模拟器，比如 QEMU 的嵌入式版本。它能模拟完整的开发板，甚至能跑 Linux，但配置成本高，对于只学外设入门的人来说有点杀鸡用牛刀。

我最后的选择是：Keil MDK 的 Simulator 为主，Proteus 为辅。Keil 用来验证代码逻辑和寄存器行为，Proteus 用来“看看”串口输出和模拟量输入这些 Keil 里不好模拟的东西。两个工具互补，基本覆盖了入门阶段能碰到的大部分场景。下表是我当时的对比记录，供你参考：

2.2 从零装出一个可仿真的工程

环境搭建有几个关键步骤，每一步都有对应的坑，我按自己的操作顺序说一遍。

第一步是装 IDE，我用的是 Keil MDK。装完后一定要装对应芯片系列的器件支持包，不同的 STM32 系列对应不同的 Pack，比如入门常用的 F1 系列属于 Cortex-M3，需要安装对应的 DFP 包。没装 Pack 的话，新建工程的时候根本选不到 STM32F103C8T6 这类具体型号。

第二步是装 STM32CubeMX。这个工具负责“画工程”，它能帮你把时钟树、GPIO、串口、定时器、ADC 的初始化代码自动生成出来，生成时选择 MDK-ARM 工具链，这样生成的就是一个可以用 Keil 打开的工程。

第三步是关键中的关键，在 Keil 里把调试目标切成“软件模拟器”。在 Project 菜单的 Options for Target 里，打开 Debug 选项卡，右侧默认是硬件调试器（ST-Link Debugger），你要把它改成左侧的 Use Simulator。这一步点错的人非常多，很多人说“我 Keil 仿真不了”，十有八九是这里还停在硬件调试器模式，仿真时一直报找不到调试器。

改完之后还要确认一个东西：仿真时钟频率。在 Debug 选项卡下方，有一个仿真器参数设置，其中跟目标频率相关的配置，必须和你的工程里系统时钟一致。如果代码里配置的是 72MHz，仿真参数却留成默认的 12MHz，那么依赖时间的程序全部会失真——重点是 SysTick 延时，本来延时 500ms 可能变成 3000ms，你还会以为是自己代码写错了。

第四步是编译整个工程，然后点一下 Debug 按钮，进入调试界面。此时程序应该会停在main函数入口，你可以在 Peripherals 菜单下打开相应的外设寄存器窗口，在 View 菜单下打开 Watch 窗口和逻辑分析仪窗口。到这步为止，纯软件开发环境就算跑通了。

提示：如果切到 Simulator 后发现外设寄存器窗口打不开，优先检查 Debug 选项卡里的 Dialog DLL 配置是否正常加载，许多情况下是仿真器 DLL 没有被正确绑定，重新选择一下器件型号就能修好。

3. 把外设逐个跑通：GPIO、串口、定时器、ADC 的仿真实操

这一节是全文的核心，对应标题里说的“外设一个个跑通”。我不打算讲太多教科书式的原理，重点用几个实验记录告诉你，每个外设在仿真环境里长什么样、怎么操作、以及我观察到了什么。

3.1 GPIO 点灯：仿真里验证的不只是“灯亮”

GPIO 是几乎所有 STM32 入门的第一道菜。CubeMX 里把 PB0 配置成输出模式，生成代码后，在 main 里写一个翻转逻辑：

HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_SET); HAL_Delay(100); HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_RESET); HAL_Delay(100);

这段代码在真板上，现象就是 PB0 的 LED 一秒闪五次。但在仿真器里，我没有 LED 可看，我打开的是外设寄存器窗口，盯着地址0x40010C14也就是 GPIOB 的 ODR 寄存器。单步执行到GPIO_PIN_SET这一行，ODR 的第 0 位瞬间变成 1；执行到GPIO_PIN_RESET，这一位又变成 0。说实话，第一次看到这个变化的时候，我对“写引脚”这个动作的理解完全不一样了——原来点灯的本质就是往一个内存地址里写 1 和写 0。

更有意思的是用逻辑分析仪看波形。Keil 的逻辑分析仪可以添加PortB.0这个信号，也可以直接添加GPIOB->ODR表达式，把它按位显示出来。全速运行程序时，你能看到一个循环方波。把光标挪到波形上，能直接量出高电平持续时间和低电平持续时间。我实测 100ms 延时的波形宽度在仿真器里基本对得上，但精度没办法和真实示波器比，用它看“大概对不对”完全够，看“精确到微秒”就别指望了。

GPIO 仿真给到的真正价值，不是“灯亮了很爽”，而是你亲手确认了“寄存器写入 -> 引脚外设行为”这条逻辑链。仿真器把这条链上最容易被忽略的那个环节——寄存器到底是什么——暴露在了你面前。

3.2 串口收发：虚拟终端让我第一次“看到”程序说话

串口仿真我换了姿势，因为 Keil 的模拟器里想模拟一个外部终端输入并不方便，但输出很舒服。最直接的办法是用printf重定向到 UART，然后在 Keil 的 Debug 窗口里看输出。

在 CubeMX 里把 USART1 配置成异步模式，波特率 115200，生成代码后，在工程里加上重定向代码：

#include <stdio.h> int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF); return ch; }

然后在 main 里写一句printf("Hello STM32 Simulator\r\n");。在 Keil 的仿真模式下，用 Debug (printf) Viewer 窗口就能看到这句话。这里有个细节：很多人忘了勾选微库 MicroLib，导致printf浮点支持相关的内容出问题，或者重定向没有生效。我的经验是，CubeMX 生成的工程里要留意 Target 选项卡中 Use MicroLib 这个勾选，勾上能省掉一堆printf实施上的奇奇怪怪问题。

想看“程序收数据”的话，我的做法是把工程放到 Proteus 里跑。Proteus 里的 STM32 模型可以接一个虚拟终端，相当于一个“串口助手”窗口。我在代码里写了一个很简单的回显逻辑：收到什么字符，原样发回去。在 Proteus 的虚拟终端里输入A，立刻就能看到A回显出来。这个体验非常接近真板接串口助手的感觉，而它的好处是不需要任何外接 USB 转串口工具。

串口仿真的另一个价值是验证波特率配置。我写了一个每秒发送一次包含毫秒时间戳的字符串，然后把发送波形的间隔比对一下，基本能确认 USART 波特率寄存器没有配错。真板上这些当然也能测，但仿真环境的好处是零成本、不占桌面，改完重跑，一秒钟看到结果。

3.3 定时器与 PWM：用虚拟示波器验证计算值

定时器是 STM32 外设里比较抽象的一类，很多人学到这里开始迷糊，因为“看不见摸不着”。仿真器在这里是绝佳教具，尤其在你配 PWM 的时候。

我用 CubeMX 配置了 TIM2 的通道 1 输出 PWM，目标频率 1kHz，占空比 50%，输出引脚是 PA0。这里有一个很经典的计算公式：PWM 频率等于定时器时钟除以（预分频器 + 1）再除以（自动重装载值 + 1）。比如定时器时钟 72MHz，我设预分频值 PSC 为 71，自动重装载值 ARR 为 999，那么频率就是 72MHz / 72 / 1000 = 1kHz。占空比则由比较值 CCR 决定，CCR 设为 500 就是 50%。

代码不需要自己写，CubeMX 会根据配置直接生成。跑起来之后，我打开 Keil 的逻辑分析仪，添加TIM2->CCR1和PA0两个信号。波形出来后，先看周期：完整一个方波的周期大约 1ms，对应的就是 1kHz，说明我的预分频和重装载值算对了。再看高电平占比：高电平部分约 0.5ms，占空比 50%，说明 CCR 设置正确。

在真板上你当然也可以用示波器看这个波形，但如果你手头暂时没有示波器——很多初学者第一块板子拿回来的时候，并没有像样的测量工具——仿真器里的虚拟示波器就是一个免费替代品。它也许不如一两万的示波器精准，但用来理解 PWM 频率和占空比的概念，绰绰有余。

我还额外做了一个验证定时器中断的实验。在 CubeMX 里使能 TIM2 更新中断，在中断回调函数里对一个全局变量tick_count做自增，然后在 Keil 的 Watch 窗口里观察它。全速运行时，可以看到tick_count按预期增长；暂停程序时，还能从它的当前值反推出定时器中断触发了多少次。这种对中断触发“有实感”的体验，是规格书和教程都很难直接给你的。

3.4 ADC 采集：改寄存器模拟电压输入

ADC 的仿真比前面几个外设都麻烦一点，因为仿真器里没有真实的电位器来产生模拟电压。但我摸索出一个足够用的办法，思路很简单：既然 ADC 转换的最终结果会放进 ADC 的数据寄存器，那我只需要在仿真的调试过程中，手动往这个寄存器里写一个值，就能验证从“读取转换结果”到“处理数据”的整条软件链路。

CubeMX 里配置 ADC1 的通道 0，生成初始化代码。在 Keil 仿真环境里跑起来后，程序停在某个断点上，此时不靠仿真器自动转换，而是用调试器的内存窗口直接定位到 ADC1 的数据寄存器，手动写入0x0FFF，也就是 4095，代表转换结果为满量程。然后继续运行或者单步几步，看软件分支是否正确地走到了“满量程”对应的处理逻辑里。再把寄存器改成0x0000，也就是 0，看另一套逻辑是否被触发。

这个做法的价值在于，它把“纯软件”调试和“数据流”调试结合起来了。真实硬件上，ADC 的值取决于外部电压，你改的是物理旋钮；仿真里没有旋钮，但你把“转换结果”这个最终输入手动注入进去，程序对高值、低值、中间值的分支处理逻辑，哪些写对了、哪些漏了，一下就测出来了。

如果你想要更接近硬件的体验，就用 Proteus。我在 Proteus 里放了一个电位器模型，把中间抽头接到 ADC 输入引脚，鼠标拖动电位器的滑块，就能看到 ADC 数据寄存器的值跟着变化。跑起来之后调节滑块，程序的逻辑分支会随电压变化来回切换。这个体验和真板几乎一样，但我依然建议你把两种方式都试一遍：Proteus 负责“感性认识”，Keil 负责“精确断点分析”，两个配合能把 ADC 这个外设彻底摸透。

4. 仿真和真板之间的差距：哪些能迁移，哪些别当真

我把仿真作为入门主力过了差不多一个月之后，拿到真板的第一个晚上，就发现了一些仿真里完全想象不到的问题。这一节的价值在于给正在用纯软件方式入门的你打预防针，让你在迁移到真板时少走弯路，而不是让你对仿真失去信心。

4.1 仿真验证不了的硬件边界

仿真器能把软件逻辑模拟得很像，但硬件世界里的物理规律，它基本无能为力。首先是电气特性。引脚输出的驱动能力、电平转换速度、电压阈值，这些在仿真器里都是理想化的。真板上一个引脚接到负载很重的电路，电平可能会被拉低，代码逻辑一模一样，但实测波形可能变得很难看。其次是外部器件的真实行为。我在仿真里调好的 I2C 时序，拿到真板连上真实传感器，第一个问题就是应答信号收不到，因为仿真模型永远不会模拟真实器件的 min/max 时序要求。

第三是时钟精度。仿真器的时钟是虚拟的，永远稳定。真板上的外部晶振有起振时间，PLL 有锁定过程，这些都不在仿真器视野内。而且不同板子的晶振误差不同，同样的延时参数，A 板闪灯刚刚好，B 板闪灯可能肉眼可见地快了或者慢了。这些不是软件问题，是硬件容差，仿真器无法反馈给你。

用表格概括就是：

4.2 从仿真切到真板，最容易翻车的三个位置

第一个容易翻车的是时钟配置。仿真里 HSE 外部高速晶振总是能起振，所以从 HSE 切换到 PLL 的流程顺风顺水。真板上如果外部晶振电路有问题，或者电容焊错了位置，HSE 就起振不了，然后程序会卡死在HAL_RCC_ClockConfig的等待标志循环里。我第一个真板程序就碰到过一次，当时第一反应是代码问题，排查了半天才发现是晶振旁边的负载电容焊错了型号。这个坑仿真完全不会提示你。

第二个容易翻车的是外部中断。仿真里我用调试器改一个寄存器值，就能模拟一次外部中断触发，感觉很顺。真板上外部中断信号是真实引脚电平变化产生的，你得考虑按键抖动、信号毛刺、触发沿的保持时间，这些都会导致中断不触发，或者一次按下触发多次。代码逻辑一样，但真实物理世界的“脏信号”处理，是仿真环境无法给你的经验。

第三个容易翻车的是电源和复位。仿真里 MCU 永远上电成功，永远不复位。真板上，如果电源纹波太大，或者复位电路时间常数不对，芯片可能间歇性复位，表现为程序跑着跑着重启了，毫无规律。这类问题往往不在你的业务代码里，而在原理图设计里。我做第一个带外部设备的真板项目时，足足花了两天才意识到程序重启是电压跌落导致的，而不是逻辑跑飞。

这些坑不是说“仿真没有用”，而是说在仿真里学会的内容，解决的是“软件写得对不对”的问题；真板解决的问题，是“硬件能不能跑起来”的问题。两者是不同维度的能力，先用仿真把前一个问题解决掉，再用真板去面对后一个问题，反而是一种更高效的学习节奏。

5. 我踩过的仿真坑与排查思路

纯仿真学习虽然省钱，但也不是一帆风顺。我差不多用一个下午的时间在跟各种“跑到一半没反应”的毛病打架，这里记录几个印象最深的问题和我的排查思路，希望对你有用。

5.1 仿真跑不起来：启动文件和时钟相关的几类问题

第一次把工程切到 Simulator 后，点 Run，程序没有像预想的那样跑起来，而是卡在启动文件里出不来，或者在SystemInit附近反复跳。我当时的第一反应是代码写坏了，后来冷静下来，发现这类问题大部分逃不出三个原因。

第一个原因是前面提过的调试目标没切换，Keil 还在试图连接硬件调试器，仿真模式没有真正生效。这个最好排查，打开 Debug 选项卡看一眼就行。第二个原因是芯片型号和启动文件不匹配。我用 F103 的工程选了别的系列器件，或者器件 Pack 没装好，启动文件里的向量表不对，代码自然跑飞。解决方式是重新确认所选器件，重新生成 CubeMX 工程。第三个原因和时钟有关。某些工程在进入 main 之前要先完成时钟初始化，如果仿真参数里给的时钟源和代码想要的不一致，初始化流程可能陷入死循环。我把仿真参数里的系统时钟改成和工程目标一致之后，启动文件就不再卡住了。

这类问题的通用排查链路，我的经验是：先看启动文件停在哪一行，如果停在LoopFillZerobss或者复位处理里，说明是编译链接层面的问题；如果停在等待某个标志位的循环里，说明是时钟或外设初始化层面的问题；如果停在某个 HAL 函数里，那就先用单步逐行执行，看它卡在等待哪个状态位。

5.2 串口输出看不到：问题多半不在串口本身

我用 Keil 仿真器跑printf的时候，遇到过输出窗口一片空白。排查了一圈，最后发现问题根本不是串口没配置好，而是printf重定向压根没生效。在嵌入式工程里，printf最终调用的底层字符输出函数是fputc，它默认指向的可能是标准库的半主机模式实现，而半主机模式在仿真环境里不工作，于是所有输出都被吞掉了。加上我之前说的，把Use MicroLib勾选上，并且明确实现自己的fputc，用HAL_UART_Transmit把字符送到 UART，问题就解决了。

在 Proteus 里跑串口输出时，我也遇到过虚拟终端只显示乱码的情况。这个问题的根因通常是两端的波特率不一致。STLINK 虚拟终端默认配置和代码里设置的 115200 不一致，或者模型里设置的时钟频率与代码预期的时钟频率存在偏差，导致波特率计算错误。我就顺手整理了一个检查清单：

1. 代码里的波特率值是多少，终端里的波特率是否一致；
2. 数据位、停止位、校验位是否一致；
3. MCU 模型的主频设置是否和代码里的时钟树一致；
4. 是否因为代码在上电后没有先初始化串口，而终端已经在收乱码。

5.3 寄存器窗口“纹丝不动”：先怀疑这三件事

仿真里写好了点灯代码，单步执行也看着程序往下走了，但打开 GPIO 外设寄存器窗口，里面的 ODR 值就是不变。遇到这种诡异现象，我后来总结出最常见的三种原因。

第一是编译器优化。优化等级如果开到较高，某些看起来是“写寄存器”的语句可能被优化掉，或者执行顺序被调整，导致你在窗口里观察不到预期的瞬时状态。调试仿真时把优化等级调低，比如 -O0，能极大减少这种困惑。第二是观察窗口没有及时刷新。Keil 的外设寄存器窗口在单步执行后通常会自动刷新，但全速运行期间改动它不一定实时更新。停下来之后如果发现数据和预期不符，重新点击窗口，强制刷新一次。第三是代码根本没执行到你断点所在的位置。很多人在 main 函数入口打断点，但忽略了此前启动文件和中层初始化已经跑过了。我踩过一次：程序在进入 main 前的时钟初始化阶段崩溃了，但调试器没提示，外设窗口自然一动不动，我也误以为自己是寄存器写不进去。

5.4 让仿真更接近真机的一些习惯

经过这几轮折腾，我养成了几个“仿真时把自己当真机对待”的习惯，分享出来。第一个习惯是每次新建工程，先把时钟配置和实际系统频率写在笔记里，仿真参数、定时器计算、串口波特率全部围绕这个基准来，免得出现“仿真正常、上板乱套”的问题。第二个习惯是仿真通过后，不要急着认为万事大吉，我会刻意检查一遍代码里那些依赖时间的逻辑，比如延时函数、超时判断，在真板上大概率会需要重新校准。

第三个习惯是每隔一段时间，就把仿真的成果哪怕是最简单的点灯程序，放到真板上跑一次。这个动作的意义不在于验证代码，而在于校准“仿真和现实的落差”。每次真板跑通一次，我都会在笔记里记下两者之间的差距：延时慢了多少、串口输出是不是正常、引脚波形有没有毛刺。这样积累几轮之后，你对“仿真的话能信几分”这件事就有非常清晰的感觉了。

提示：仿真时如果发现外设行为异常，先别急着怀疑仿真器有 bug。绝大多数情况下，是时钟配置、优化等级、或者调试窗口刷新方式的问题。把这些基础变量一一排除，再谈仿真器模型问题才有意义。

最后再分享一个我个人的操作习惯：我在做每个外设实验时，都会把仿真器里的寄存器截图、波形截图、以及和外设配置相关的关键参数存在同一个项目文件夹里，形成一份“外设调试档案”。这个习惯让我在后来切真板时，遇到问题能很快回看当时的仿真状态，判断到底是仿真模型偏差还是真实硬件问题。这个档案一点不花哨，但实用性很强，相当于给每个外设都留了一条可回溯的调试记录。如果你也正走在纯软件入门 STM32 的路上，建议从第一个外设就开始这样做，等你跑通三四个外设之后，回头翻着这些记录，会发现自己对芯片的理解已经比单纯看教程时深了一大截。