不买开发板也能学STM32？纯软件仿真入门指南

学STM32是不是非得先买一块开发板？这是我在好几个交流群里被反复问到的老问题。以前我总习惯回答"就几十块钱，买吧"，直到我自己带了一个零预算的入门小组，才真正意识到：对很多人来说，最大的门槛不是那几十块钱，而是"还没想清楚要不要学，就要先掏钱、等快递、研究下载器怎么用"这一长串的摩擦力。所以我干脆把STM32入门做成了一套"纯软件"版本——用仿真环境代替物理开发板，GPIO、串口、定时器、ADC这些外设一个接一个地在虚拟电路里跑通，全程不用买板子。这篇文章就把这套方案完整拆开：用什么工具、怎么搭环境、外设怎么配、踩了哪些坑，给想低成本入门的朋友一条可以直接照抄的路线。

先说实话：仿真不是"玩玩具"。我用的这套组合在真实工程里也经常用来做逻辑先行验证。它尤其适合三类人：预算吃紧的学生党、想先探路再决定要不要买板的观望者、以及需要在没有硬件的情况下提前做预研的初学者。下面按我实际操作顺序写，每一步都是干了实事的。

1. 为什么要把STM32入门做成"纯软件"版本

1.1 一块板子背后的隐形门槛

先算一笔账：一块常见的STM32最小系统板大概三四十块，配一个下载器四五十，再加杜邦线、面包板、几个电阻和LED，满打满算一百块以内能搞定。说实话这不算贵，但真正的门槛不在这。我发现新手真正卡住的是"决策瘫痪"：买哪家板子？F103还是F407？下载器买哪种？ST-Link有没有正版盗版之分？板子会不会第一次上电就烧？还没来得及敲第一行代码，光是在购物平台上反复比选就已经耗掉一晚上。

更麻烦的是等待和试错的周期。快递要两天，编译环境装半天，好不容易把第一个工程建好点亮LED，大半天已经过去了。对本来就只是"想先看看嵌入式适不适合我"的人来说，这种摩擦是致命的——不少人就是在这一步被劝退的。

做成纯软件之后，这些门槛全部清零：CubeMX和HAL库是官方免费提供的，Keil有社区版授权，Proteus也有可评估的授权模式，先把流程跑通绰绰有余。下载器不需要、连线不需要、烧录不需要、板子当然也不需要。你把全部精力集中在"外设是怎么工作的"这件事本身上，而不是被一堆周边工具消耗掉。

1.2 仿真到底"真"在哪、假在哪

在往下讲之前，必须把仿真能干什么、不能干什么说清楚，免得有人把它当成包治百病。

仿真真实的地方在于：它跑的是你最终要烧进芯片的那份机器码。中断怎么被触发的、寄存器怎么被改的、HAL库调用时序是不是合理——这些逻辑层面的东西，仿真和真实芯片是严格一致的。我见过不少人在仿真里调通了UART，拿到真板子上一把成功，原因就是逻辑本来就没问题。

仿真假的地方在于电气层面：仿真里的LED没有真实LED的导通压降曲线，按键没有机械抖动，电源没有纹波，信号线上也没有串扰和干扰。也就是说，凡是"理想器件"能掩盖的问题，仿真里都看不见。所以我的定位是：仿真用来学"程序怎么写、外设怎么配"，真板用来学"电路在真实世界怎么表现"。两者不是替代关系，是接力关系。

2. 方案选型：三件套分工与取舍

2.1 三套主流方案横评

我实际把市面上常见的几种仿真路线都试过，各有各的脾气。

第一是Proteus。这是目前最"拟物"的方案，它把整个电路画出来，芯片、LED、电阻、按键、示波器、串口终端都在同一个画布上，跑起来能直接看到LED亮灭、示波器波形、串口打印。对入门来说，"看见"是最重要的反馈，所以这也是我最后选的主力方案。

第二是Keil MDK自带的模拟器。Keil调试器里有个纯软件模拟功能，可以单步、看寄存器、看变量。但它没有可视化的电路，外设模型也覆盖不全，跑起来更像"在纸上模拟一颗芯片"，感知不到外设的真实行为。我一般把它当作辅助工具，用来做断点排查。

第三是QEMU这类开源全系统模拟器。功能很强，能模拟整颗芯片加操作系统，但配置门槛高，需要自己搭工具链、写配置脚本，对新手相当不友好。它适合做系统级验证，不适合作为入门第一站。另外还有一些网页版仿真器，打开浏览器就能用，但支持的STM32型号少、外设模型浅，适合随手试，不适合系统学。

2.2 我的组合：CubeMX、Keil、Proteus各管一段

定下来的组合是：CubeMX管配置、Keil MDK管编译和调试、Proteus管电路和运行仿真。

CubeMX的职责是生成初始化代码。STM32的寄存器多、时钟树复杂，手写初始化容易在时钟配置上翻车。CubeMX把引脚、时钟、外设参数用图形界面配好，直接生成HAL库工程，把最容易出错的前置步骤变成了"看图点选"。Keil负责编译出hex文件，同时调试器能提供断点、寄存器观察窗口，排查逻辑问题非常顺手。Proteus负责最关键的"虚拟硬件"，它提供STM32F103的模型，你可以摆芯片、画电路、挂虚拟示波器、挂虚拟串口终端。

这套分工的好处是：每一层都有明确的产出物，出了问题分得清是代码问题、电路问题还是配置问题。比如LED不亮，先在Keil里看寄存器翻没翻，再回Proteus里看接线对不对，不会所有可能性搅在一起瞎猜。

3. 环境搭建：让虚拟板子第一次亮起来

3.1 安装配置里的三个关键版本点

环境安装不复杂，但有几个版本细节值得交代。第一，Proteus要选8.x及以上版本，旧版本对STM32F103模型的支持很差，会出现能放芯片但跑不动的情况。第二，Keil MDK要记得安装对应芯片系列的支持包（Device Family Pack），不装的话根本找不到STM32F103C8这个型号。第三，CubeMX生成工程时，工具链要选MDK-ARM，版本号保持默认就行，Keil能直接打开。

这三个点都是"装完发现不对再回头折腾"的高频坑。建议装完之后，先在CubeMX里新建一个空工程，生成、编译全走一遍，确认工具链链路是通的，再继续后面的操作。花五分钟验证环境，比后面调半天发现是环境问题要划算得多。

3.2 CubeMX配置：先把芯片"画"正确

打开CubeMX新建项目，在芯片搜索框输入STM32F103C8，双击选中。这个型号是我反复推荐给新人的，原因很简单：资源刚好覆盖入门外设（GPIO、USART、TIM、ADC都有），Proteus模型成熟，网上案例也多。

新工程默认把引脚都设成复位态。第一步配RCC，在System Core里选RCC，把HSE设为Crystal/Ceramic Resonator，因为后面要在Proteus里放一颗8MHz晶振。第二步进Clock Configuration，把HSE设为8MHz，PLL倍频系数设为x9，让系统时钟SYSCLK达到72MHz，这是F103的典型主频。如果不熟悉F103的时钟树，记住一句话：HSE 8MHz进PLL，x9以后到72MHz，其余总线时钟CubeMX会自动分配好。

第三步配一个最简单的输出引脚。在芯片图上点一下PA5，设为GPIO_Output。为什么不选PC13？因为PC13在Proteus模型里对应板载LED的位置，直接用PA5搭电路更直观。生成工程之前设置好项目名、输出目录，工具链选MDK-ARM，其余默认。

生成的代码里，main函数已经包含HAL初始化、时钟初始化、GPIO初始化。在while(1)里加三行代码：

while (1) { HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); HAL_Delay(500); }

编译通过后，去输出文件夹找hex文件，路径通常是MDK-ARM/工程名/Debug/工程名.hex，这个文件就是要喂给Proteus的"固件"。

3.3 Proteus连线：画电路也有讲究

打开Proteus新建工程，从元件库把STM32F103C8放上来，元件名搜索"STM32F103C8"。再放一颗LED和一个330欧姆电阻，电阻一头接PA5，另一头接LED阳极，LED阴极接GND。

这里必须提醒一个很容易被忽略的地方：Proteus里的STM32模型有独立的电源引脚，VDD、VSS、VDDA、VSSA都要接上对应的电源网络，漏掉任何一个，仿真时芯片可能没有反应，或者一上电就报错。有些型号还有VBAT，也要接到3.3V。此外，为了匹配CubeMX里选的HSE晶振，需要放一颗8MHz晶振，接到OSC_IN和OSC_OUT之间，两个引脚再各接一只20pF左右的电容到地。这一步模拟的是真板子晶振电路的标准接法，仿真模型确实会按这个频率去工作。

连线完毕，双击芯片打开属性，在Program File一栏填上刚才Keil生成的hex文件路径，点确定。然后点右下角的运行按钮，LED应该以大约1Hz的频率亮灭——如果你看到了，恭喜，你的"虚拟开发板"已经跑通。

4. 外设逐个跑通：点灯、按键、串口、定时器、PWM、ADC

4.1 GPIO输入：按键进来，顺便聊聊防抖

点灯只会输出，算不上完整的外设体验。第二步建议做按键输入，顺便理解GPIO的方向配置和防抖思想。

在CubeMX里把PA0设为GPIO_Input，在GPIO设置里把User Label改成Key，把上拉模式设为Pull-up。为什么用内部上拉？按键一端接地，按下去拉低，松开时靠内部上拉保证引脚电平确定——这样电路上只需要一个按键，不需要额外上拉电阻。

读PA0电平，按下了就翻转LED：

if (HAL_GPIO_ReadPin(Key_GPIO_Port, Key_Pin) == GPIO_PIN_RESET) { HAL_Delay(10); if (HAL_GPIO_ReadPin(Key_GPIO_Port, Key_Pin) == GPIO_PIN_RESET) { HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); while (HAL_GPIO_ReadPin(Key_GPIO_Port, Key_Pin) == GPIO_PIN_RESET); } }

读到低电平先等10ms再确认一次，是真按下才翻转LED，之后等按键松开，防止一次按下触发多次翻转。这个写法在仿真里看起来有点多余，因为理想按键不会抖，但挪到真板上你就知道这10ms值多少钱了。

4.2 串口：printf重定向到虚拟终端

串口是STM32和外界"说话"的通道，也是后面看ADC数值最方便的手段。在CubeMX里打开USART1，模式选Asynchronous，参数设为115200、8位数据、1位停止位、无校验。默认引脚是PA9（TX）和PA10（RX），保持默认。

生成代码后，要让printf直接用上串口，需要重定向fputc。在main.c里包含stdio.h，并添加：

int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 100); return ch; }

这样以后写printf("hello\r\n")，字符就会从USART1发出。我习惯在字符串里带\r\n，因为虚拟终端默认收到\n不会自动换行，不带的话输出会挤成一行。

在Proteus里放一个Virtual Terminal。连接方向要看清：终端的TXD接到芯片PA9（数据流向是芯片→终端），终端的RXD接到PA10。千万不要接反。双击终端，把Baud Rate改成115200，跑起来之后虚拟终端窗口会不断出现字符串。如果什么都没显示，优先检查两个地方：波特率是不是两边不一致，TX/RX是不是接反了。这两个问题占了串口仿真故障的九成。

4.3 定时器中断：把"延时等待"改成"后台触发"

HAL_Delay延时虽然方便，但是阻塞的，延时期间CPU干不了别的活。真实项目里更常用定时器中断。这一节用TIM2做一个100ms周期中断，在回调里翻转LED。

在CubeMX的Timers里打开TIM2，设置Prescaler为7199，Counter Period为999。算一下：TIM2挂在APB1上，时钟72MHz，预分频7200，计数1000，得到周期72M/7200/1000=10Hz，也就是100ms进一次中断。在NVIC设置里勾选TIM2 global interrupt使能。

生成代码后，在main的while循环之前调用HAL_TIM_Base_Start_IT(&htim2)，然后在main.c里实现回调：

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim->Instance == TIM2) { HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); } }

注意回调是在中断上下文执行的，千万别在回调里放printf这类耗时操作，否则中断不及时退出会影响主循环。这是新手写中断最容易犯的毛病，仿真里表现得更明显——放一个printf进去，整个仿真节奏都会乱。

4.4 PWM：用占空比模拟"可变电压"

定时器另一个重要应用是PWM。用PWM控制LED亮度，是呼吸灯、电机调速这些入门项目的基础。这一节用TIM3输出1kHz的PWM，通过调节占空比让LED亮度变化。

在CubeMX里打开TIM3，把Channel1设为PWM Generation CH1，引脚映射到PA6。设置Prescaler=71，Counter Period=999，PWM频率算出来是72M/72/1000=1kHz。初始Pulse值设500，对应50%占空比。生成的代码里，在初始化之后启动PWM输出：

HAL_TIM_PWM_Start(&htim3, TIM_CHANNEL_1);

想改变亮度，用比较值设置宏：

__HAL_TIM_SET_COMPARE(&htim3, TIM_CHANNEL_1, pulse);

pulse的范围是0到999，0全灭，999全亮，中间值对应不同亮度。在Proteus里把PA6接到示波器通道，就能看到方波；改pulse值，可以看到方波高电平宽度在变，这就是占空比变化。LED看到的是"交替供电"的平均效果，占空比越高，平均电压越高，灯就越亮。这些看一眼波形，比背概念扎实得多。

4.5 ADC采集：让芯片学会读电压

最后把ADC跑通，这是入门外设里最有"感知"价值的一个：芯片读取外部模拟电压，把它变成一个数字值。我用Proteus里的电位器模拟可调电压源，接到ADC通道，把采集结果用串口打印出来。

在CubeMX的Analog里打开ADC1，把IN0通道配置上，对应引脚是PA0。转换模式用单次转换，扫描模式关闭，采样时间和其余参数保持默认。生成代码后，在需要采集的地方做三件事：启动ADC转换、等待转换完成、读取数据。

HAL_ADC_Start(&hadc1); HAL_ADC_PollForConversion(&hadc1, 10); uint16_t adc_val = HAL_ADC_GetValue(&hadc1); float voltage = adc_val * 3.3f / 4096.0f; printf("ADC=%d, Voltage=%.2fV\r\n", adc_val, voltage);

在Proteus里放一个电位器（POT-HG），两端分别接3.3V和GND，中间滑动端接PA0。运行后旋转电位器，虚拟终端打印的ADC值和电压会跟着变化。F103的ADC是12位的，最大读数4095，所以用4096做分母换算电压。如果你换到其他型号，分辨率变了，换算公式分母也要跟着变。很多人仿真里显示电压永远不对，就是在这里栽的。

5. 调试技巧：仿真环境里如何快速定位问题

仿真环境有一个物理板子比不了的优势：你看得见信号。这一节说一下我是怎么利用这个优势做排查的。

5.1 把虚拟示波器和逻辑分析仪用起来

Proteus自带的虚拟示波器在元件库里搜Oscilloscope就能找到。接法是把示波器A通道接到目标信号引脚，比如PWM输出的PA6，点运行后调一下时间基准，就能看到波形。如果波形看起来是平的，先看通道接没接对，再看是不是没有启动对应外设输出。

逻辑分析仪适合看多路数字信号，比如同时观察UART的TX、RX状态，能直观看到电平跳变和时序关系。对入门来说，示波器看PWM、逻辑分析仪看串口时序，这两个用途基本覆盖了大部分排查场景。用这些仪器的时候，我的习惯是先把时间基准放大，确认一个周期的形态，再慢慢缩小看整体，不然很容易被高频画面晃晕。

5.2 Keil调试器：在"芯片内部"看值

Proteus负责外部信号，Keil负责内部状态。编译后点Start Debug Session，可以单步执行、打断点、在Watch窗口查变量的实时值，也能打开Peripherals菜单点开具体的寄存器组，比如GPIOA的数据寄存器ODR，看引脚电平变化。

组合使用方法：在Keil里设断点，跑到关键代码处停下，回头对照Proteus里看到的电路状态。比如LED不亮，就在HAL_GPIO_TogglePin那行设断点，看每次执行时ODR寄存器是不是在翻转。如果翻转了但灯不亮，问题在电路连接；如果寄存器都没变，问题在代码逻辑。这个"内外对照"的思路，是仿真环境排查问题最核心的方法，比真板上拿万用表戳引脚还要直接。

5.3 仿真速度和实时性的平衡

很多人在仿真里会遇到"跑得特别慢"的问题。Proteus在运行大型仿真时，尤其是多个外设同时工作、示波器采样率又高的时候，要实时计算每个模拟量，自然会变慢。我的习惯是：把示波器采样率适当调低，把不需要观察的外设暂时在代码里关掉，把延时函数从1ms级换成100ms级，仿真能流畅很多。

另外，Proteus右下角有运行模式选择，可以选实时运行或者尽可能快。纯看结果时选"尽可能快"，要看示波器波形时序时选"实时"，切换着用，效率会高不少。

6. 常见问题速查：我把踩过的坑整理成了表格

做这套仿真的过程中，我把遇到的和身边人遇到的典型问题都记了下来，整理成一张表，可以直接对照排查。

6.1 几个容易被忽略的细节

除了表格里的现象，还有几个心得值得单独说。第一，Proteus的STM32模型对"没有初始化就使用的外设"容忍度较高，也就是说代码里忘了开时钟、忘了初始化，仿真可能不报错，但外设就是不动。这提示我们写代码要养成先初始化再操作的习惯，别指望报错来提醒你。

第二，printf重定向之后，如果在中断回调里调用printf，仿真里会看到终端输出明显卡顿。中断里只放功能代码，打印放主循环，这条纪律在真板上同样适用。

第三，不要一次性把五个外设全部调通再仿真。每调通一个外设就烧一次hex跑一下，确认没问题再叠加下一个。增量验证可以把问题精确锁定在某个模块里，五个外设一起出问题，排查成本会翻好几倍。我见过有人一次性配完所有外设，跑不通的时候连是哪个外设卡的都分不清。

7. 从仿真到真板：哪些经验能带走，哪些坑要重踩

整套方案跑下来，我最大的感受是：仿真入门真正教会你的不是"怎么操作某某软件"，而是一套"先想清楚再动手"的工作方式。CubeMX逼你把引脚和时钟想明白，Proteus逼你画出电路，Keil逼你读懂寄存器。等你把这套流程走完，再拿真板子，缺的只是下载器插上USB那几秒钟的动作。

7.1 能直接带走的与必须重新面对的

能带走的是整套代码逻辑和配置思路。你在仿真里调好的HAL工程，拿到真板子上重新编译下载，灯照样闪、串口照样打、ADC照样出数，因为芯片寄存器和外设行为是一致的。引脚规划、时钟配置、外设参数的数，也完全通用。

必须重新面对的是电气和时序的真实性。真板上按键会抖，LED亮度受电阻和压降影响，电源纹波可能让ADC最低位跳动，电机一启动还可能把MCU拉复位。这些在仿真里都遇不到，遇到才知道它们的脾气。另一个差异是性能：仿真的时间基准很理想，真板上的定时器中断、DMA传输的时序余量，需要拿示波器实测才能确认。

7.2 学完仿真之后，我建议的下一步

我给身边人的建议一直是：先用仿真把这一整套外设思路跑通，再决定要不要买板子。仿真阶段连配置外设都提不起兴趣，真板大概率也学不下去，省下来的钱和时间都是赚的；仿真跑得津津有味，买了板子之后半天就能上手，因为最劝退的环节已经在虚拟板上趟平了。

最后分享一个我实际养成的习惯：每跑通一个外设，就在工程目录下写几行注释，记录当时的引脚分配、时钟配置和关键参数。这个速查文件在仿真阶段没什么感觉，到了真板阶段，对照着它做迁移和查错，效率能高一截。工具会变、板子会换，但你自己梳理出来的那份配置表不会过时。