不买开发板也能学STM32？纯软件仿真入门全攻略

先把结论放这儿：不买开发板，一样能把STM32的GPIO、串口、定时器、ADC这些外设一个个跑通，而且有些场景下看得比实物板子还清楚。我最近总被朋友问：手里没板子、钱包还有点紧，能不能先把STM32学起来？我的回答是能，而且我个人这几年的经验是，先跑仿真、再买板子，这个顺序反而能帮你少走很多弯路。这篇文章就把我的“纯软件STM32入门”完整方案发出来，工具怎么配、工程怎么建、外设怎么一个个跑通，每个环节都按我实际操作的过程写，照着做基本就能复现。

1. 纯软件仿真入门：这笔账怎么算才划算

1.1 为什么我推荐先把仿真跑起来

很多刚开始接触嵌入式的人，默认思维就是“学STM32一定要先买一块开发板”，于是板子买回来、传感器模块也买了一堆，结果多数时间花在接线、查环境、找驱动上，真正用来理解代码逻辑的时间反而不多。仿真学习的第一个好处就是省钱：一块入门开发板几十上百元，加上各种外设模块（按键、LED、OLED、传感器、电机驱动）越买越多，如果只是验证学习逻辑，这笔开销完全可以在仿真里砍掉。

第二好处是省时间。实物开发里，线没接对、驱动没装好、端口被占用、下载器识别不到，这些问题每一个都能耗掉你半小时。而在仿真环境里，改一个引脚配置只要几秒钟，跑错了重新编译再点一下运行就行，不用反复插拔USB线和杜邦线。我个人在实际中体会很深的是，仿真模式特别适合“验证想法”：比如你怀疑某个定时器重装值算错了，直接在虚拟逻辑分析仪里看波形就能判断，比用示波器戳引脚快得多。

第三点可能被很多人忽略：仿真能看到实物看不到的东西。开发板上的LED亮了，你只能看到一个灯泡亮不亮；但在仿真环境里，你可以用虚拟逻辑分析仪看GPIO引脚翻转的精确时刻，可以展开寄存器窗口看ODR、BSRR到底发生了什么变化。这对于理解“寄存器配置”这种抽象概念，帮助非常直接。

所以我把这类内容总结成一句话：仿真不是买不起板子的退而求其次，而是一种“先跑通、再上板”的学习方法论。

1.2 主流仿真方案对比：哪个适合你

市面上的STM32仿真方案，其实比很多人听过的要多。我在实践过程中主要接触过三类，各自特点我整理了一下：

先说MDK的Simulator模式。这个模式在调试配置里把目标设备从“硬件调试器”改成“模拟器”，然后代码就完全在PC上按指令模拟跑。它的优点是和你平时开发用的IDE完全一致，能单步、能看变量、能看寄存器，还内置逻辑分析仪。缺点是不显示外部电路，你没法直观看到一个LED是怎么被接在PA5上的。

Proteus这类电路仿真软件走的是另一个路线。你先在原理图里把STM32芯片、电阻、LED、按键、虚拟串口终端都画出来连好线，再加载hex或elf文件运行。它的优势是“整个电路都在眼前”，特别适合理解为什么GPIO要配置成推挽输出、为什么I2C要加上拉电阻这类硬件问题。缺点是有一定上手成本，而且对某些新型号的芯片支持不一定及时。

Wokwi则更轻量，浏览器打开就能写代码、拖元件。它支持STM32F103这一类经典型号，可以在线模拟LED闪烁、串口打印、LCD显示等很多场景，还能直接分享链接，非常适合给别人演示“我跑通了什么效果”。

1.3 我自己的组合打法

我不太建议只死磕某一个工具，因为每个工具都有自己的盲区。我实际用的是一套组合：

• 主路径：STM32CubeMX生成工程 + MDK的Simulator模式。90%的代码逻辑、外设配置验证都在这条路径里完成，因为我能一边跑代码一边看寄存器。
• 电路补课：Proteus搭一个最小电路，把同一份工程编译出来的固件加载进去，看LED怎么亮、按键怎么触发、串口终端怎么输出，补齐MDK看不到的“电路连接”概念。
• 分享演示：Wokwi做一个在线Demo，把核心外设的示例整理成链接发出去，别人不用装任何软件就能看效果。

这套组合的好处是，你在任何一个环节卡住了，总能有另一个工具帮你把问题看清楚。比如MDK里外部中断不好模拟，那就切到Proteus放个按钮，点一下正好能看到中断回调被触发的完整流程。

2. 环境搭建实测：用仿真把点灯跑起来

2.1 三个关键软件怎么装、装哪个版本

先说清楚，这套纯软件方案需要三个东西：

1. STM32CubeMX：图形化配置工具，用来选芯片、配时钟、配引脚，并自动生成初始化代码。
2. MDK（Keil）：编译、调试主工具，我们需要用到它的Simulator仿真模式。
3. F1系列固件包：CubeMX生成工程时要用到，在CubeMX里首次新建工程时会提示下载。

版本方面，CubeMX和MDK都建议用你所在社区里常用、稳定的版本，没必要追最新。有一个我踩过的小坑：这两个软件安装路径里都别有中文，尤其是在Windows系统上，有些老版本工程的编译会莫名其妙报错，最后发现是路径问题。另外，MDK首次安装完，要确认License能正常识别，不然编译到一半弹窗会很影响心情。

F1固件包的下载在CubeMX里是自动完成的，第一次新建F103工程会让你确认下载，网络正常就能拉下来。如果下载慢，可以考虑换一个合适的下载点，但我这边不多说细节，让CubeMX默认走就行。

2.2 用CubeMX生成第一个工程的完整步骤

我以最常见的STM32F103C8芯片为例，也就是很多人说的“蓝板板”用的那颗。操作顺序我尽量写得能直接照着点：

1. 打开CubeMX，选择“File” -> “New Project”，进入芯片选择页。
2. 在搜索框输入STM32F103C8，列表里会出现对应型号，双击进入配置界面。
3. 展开“System Core” -> “RCC”，将“High Speed Clock（HSE）”设为“Crystal/Ceramic Resonator”。这一步的意思是把外部高速晶振作为时钟源。
4. 切到“Clock Configuration”标签页。F103C8最高主频72MHz，CubeMX会自动帮你把时钟树算好。这里可以看一下HSE填的是8MHz，PLL倍频后系统时钟显示72MHz，这部分是自动的，比手动查参考手册方便很多。
5. 在芯片引脚图上找到PA5，左键点一下，选择“GPIO_Output”。这是给LED用的输出引脚，我也顺便把用户标签命名为LED，方便后续代码可读性。
6. 切到“Project Manager”标签，填工程名，注意“Toolchain/IDE”下拉框要选“MDK-ARM V5”或当前MDK对应的版本。
7. 点右上角“GENERATE CODE”，生成代码。

生成完工程后，CubeMX会把你刚刚所有图形操作自动翻译成初始化代码。你在MDK里打开这个工程，会看到main.c里已经有了GPIO初始化函数、时钟初始化函数，不需要手动写寄存器。初学者先不要急着“纯寄存器”编程，用HAL库跑通逻辑，再去看寄存器反而更容易理解。

2.3 MDK仿真点灯：从编译到逻辑分析仪

工程打开后，在MDK里做以下设置：

1. 点击“Options for Target”（魔术棒），切到“Debug”标签页。
2. 在右侧“Use”选项里，从“ULINK/CMSIS-DAP”这类调试器改成“Simulator”，点确定。
3. 点击编译按钮，确保零错误。
4. 进入调试模式（Debug -> Start/Stop Debug Session）。
5. 打开逻辑分析仪，菜单路径是“View” -> “Analysis Windows” -> “Logic Analyzer”。
6. 在逻辑分析仪窗口点击“Setup”，添加信号名PORTA.5。如果弹出选择引脚信号，选PA5即可。

然后回到main.c，在while循环里加入：

while (1) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5); HAL_Delay(200); }

全速运行后，逻辑分析仪里会出现一条方波，每200ms翻转一次。因为HAL_Delay(200)的延时基于系统时钟，理论上波形的半周期是200ms，周期约400ms。你可以在逻辑分析仪里拖动测量标尺，看一下两次上升沿之间的时间差。如果量出来不是400ms，就要回头检查CubeMX里的时钟树配置是不是被改过。这个验证方式，实物板子上你得用示波器才能做到，仿真里等于免费送了一个示波器。

2.4 为什么虚拟波形比真板子更能暴露问题

实物点灯实验里，大多数情况代码写完一烧录，看到LED有反应就算成功了。但LED亮了不代表你对GPIO的理解到位了。比如有个很经典的问题：GPIO推挽输出和开漏输出有什么区别？在实物上，如果你用开漏输出接了LED，实际表现可能只是亮度有细微变化，新手很难察觉。但在虚拟逻辑分析仪上，开漏输出的波形在没有上拉的情况下会明显“拉不上去”，电平爬升非常缓慢，看到这个波形，你才会真正理解什么叫“开漏必须配上拉电阻”。

另一个很好的例子是GPIO输出速度配置。CubeMX里GPIO有Low/Medium/High三档速度可选。仿真中你用逻辑分析仪去量GPIO翻转沿的瞬态响应，可以明显感受到速度配置对边沿陡峭程度的影响。这些问题如果只在实物上“看灯”，根本不会意识到。

还有MDK自带的外设寄存器窗口。Debug模式下，你可以展开“Peripherals” -> “GPIOA”，实时看到MODER（模式寄存器）、ODR（输出数据寄存器）、BSRR（置位/复位寄存器）在代码执行时的变化。我在给别人讲“寄存器配置”的时候，通常会让他们去Simulator里单步执行几行代码，同时观察这几个寄存器的数值变化，比背一百遍参考手册有效得多。

3. 外设逐个跑通：从GPIO到串口、定时器、ADC

3.1 GPIO输入与外部中断：按键交互怎么模拟

点灯跑通之后，下一步自然就是按键输入。GPIO输入模式在CubeMX里配置成“Input”模式，可以选择上拉（Pull-up）或下拉（Pull-down）电阻。这里的关键点是：按键按下后是接到地还是接到电源，决定了你要选择上拉还是下拉。大部分开发板上的按键都是按下接地，所以引脚配置成上拉输入，平时读到的是高电平，按下时读到低电平。

我建议在仿真里做一个带消抖的按键扫描实验，因为消抖这个细节在实物上很经典，也是新手容易踩坑的地方。原理很简单：按键按下或松开的瞬间，触点会有一串抖动信号，不处理会出现“按一次触发好多次”的假象。代码处理方式常见的有延时消抖和状态消抖：

if (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0) == GPIO_PIN_RESET) { HAL_Delay(10); // 等待抖动过去 if (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0) == GPIO_PIN_RESET) { while (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_0) == GPIO_PIN_RESET); // 等待松开 led_state = !led_state; HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, led_state); } }

外部中断的方式更接近真实产品做法。在CubeMX里把PA0配置为“External Interrupt Mode”（上升沿/下降沿触发），然后在NVIC设置里使能EXTI0中断。代码里回调函数写法如下：

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin == GPIO_PIN_0) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5); } }

我个人的建议是，按键这部分的交互验证，最好放到Proteus里跑。原因很简单，在MDK的纯软件仿真里，你想模拟“引脚被按下”这个动作比较别扭；而在Proteus里直接放一个按钮和电阻，鼠标点一下就是一次物理触发的完整过程，还能顺便观察上拉电阻的配置对不对。

3.2 串口UART：把调试日志打出来

串口可以说是嵌入式调试最重要的外设，现实中绝大多数项目的“眼睛”都是串口。纯软件方案里，串口可以连接到一个虚拟终端窗口，你把代码里的printf输出导向到串口，就能看到一行一行数据打印出来，体验和真实开发一模一样。

CubeMX里的配置很简单：选择USART1，模式选“Asynchronous”，波特率设置成115200，数据位8位、停止位1位、无校验，保持默认就行。生成代码后需要注意一件事：要看到printf输出，需要把标准输出重定向到UART接口。main.c里加上这段：

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

然后在主循环里：

printf("System clock = %d MHz\r\n", HAL_RCC_GetSysClockFreq() / 1000000); printf("GPIO initialized\r\n");

在MDK Simulator里，串口输出可以通过调试菜单里的串口窗口看到：进入Debug后，点击“View” -> “Serial Windows” -> “UART #1”。程序运行后，UART #1窗口会显示这些printf内容。如果你在Proteus里跑，接一个“Virtual Terminal”虚拟终端组件，效果更直观，而且虚拟终端还能配置波特率，如果代码里波特率和虚拟终端不一致，屏幕上会出现乱码。很多初学者第一次看到乱码的时候，第一个反应是“串口坏了”，实际上只是波特率对不上。

这里有一个让我印象很深的经验：在仿真里做串口通信，波特率是否匹配一眼就能看出来，而在实物开发板上你通常需要外接USB转串口模块才能看到，一旦没接对TX和RX，又是一通排查。仿真环境天然帮你把链路简化了，这个阶段专注理解“数据是怎么从芯片流到外面”的，比折腾线序重要得多。

3.3 定时器与PWM：从延时到精确计时

前两步做完，你已经会用CPU“死等”做延时了。但HAL_Delay()这种阻塞式延时有个问题：延时期间CPU干不了别的活，这在真实项目里是非常奢侈的。定时器才是解决“一边计时、一边干活”的正解。

CubeMX里配置一个基本定时器，我习惯用TIM2。以F103系列为例，它内部有两个APB1总线上来的定时器时钟，默认配置下定时器时钟是主频的2倍，也就是72MHz。要把72MHz降到一个合适的计数频率，需要做“预分频”。我想通这部分花了不少时间，后来发现用公式理解就很简单：

• 预分频值Prescaler设为71，那么计数器频率 = 72MHz /（71+1）= 1MHz，也就是每1微秒计一个数。
• 自动重载值AutoReload设为999，那么计数器从0数到999，耗时1000微秒，也就是1毫秒中断一次。
• 所以定时中断周期 =（PSC+1）×（ARR+1）/ 定时器时钟 = 72 × 1000 / 72MHz = 1ms。

在配置界面上，直接把PSC填71、ARR填999，TIM2的中断周期就是1ms。你在中断回调里放一个计数器变量，累加到1000就是1秒。在仿真里验证这个时间精确与否非常容易，只要在调试模式里看这个变量的变化速度，或者用逻辑分析仪输出一个翻转信号量周期。

PWM是这个方向上的下一步。定时器除了能精确延时，还能输出可调占空比的PWM信号。CubeMX里将TIM2的通道1设置为PWM Generation，对应引脚PA0，PWM频率设置成1kHz，然后修改比较值CCR来改变占空比：

__HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, 250); // 25%占空比 __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, 500); // 50%占空比

这里的原理是：计数器在0到999之间循环，当计数值小于CCR时输出高电平，大于CCR时输出低电平。CCR占ARR的比例就是占空比。在逻辑分析仪里观察PA0的波形，你可以清楚看到占空比变化，这比在实物上用LED亮度判断占空比准确得多。PWM也是后面驱动电机、调屏幕亮度、做呼吸灯的基础，仿真里把波形搞明白，后边写实物的控制逻辑会很有底气。

3.4 ADC采样：把模拟电压变成数字量

ADC是另一个让我觉得“仿真里练熟真能省钱”的外设。ADC的作用是把连续的模拟电压转换成数字量，所有传感器，比如温度传感、光敏电阻、电位器输出，都要通过ADC读取。F103的ADC是12位分辨率，采集结果范围是0到4095。换算公式是：电压值 = ADC读数 × 参考电压 / 4095。如果参考电压是3.3V，读到2048，就代表输入电压大约1.65V。

CubeMX里配置ADC1的通道IN1，对应PA1引脚，分辨率选12位，模式可以根据需要选单次转换或者连续转换。生成代码后，读取一次的流程是：

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

在MDK Simulator里，外部电压不好直接提供给ADC引脚，所以我更推荐在Proteus里做这个实验：拖一个电位器，把中间抽头接到PA1，然后用鼠标拖动电位器改变输出电压，串口终端里打印的ADC值就会跟着变化。你会直观看到，电位器旋到中间，电压近似1.65V时，AD值稳定在2048附近。这种“模拟电压变数字”的对应关系，在纯文字描述里很难建立，但在仿真里拖一下电位器就懂了。

我额外做过一个温度传感器模拟：用LM35的仿真模型，它的输出电压是10mV/摄氏度，25摄氏度时输出0.25V。接进ADC后，打印出来的电压值可以反推当前“环境温度”。整个过程没有碰一块真实传感器，但对传感器标定、电压换算、阈值判断的思路都跑通了。

3.5 总线和外部显示：I2C与SPI仿真

串口、PWM、ADC跑完之后，常见的入门外设基本都算过了一遍。如果还想往上走，下一步就是总线和显示，I2C和SPI这两个总线在仿真里也能跑，而且我觉得在仿真里看它们的时序，比实物接一堆杜邦线更容易理解。

I2C在Proteus里可以挂一个虚拟的EEPROM芯片，在Wokwi里甚至可以挂SSD1306的OLED显示。重点不是把代码跑起来，而是用逻辑分析仪同时抓SCL和SDA两路信号，你会看到时钟线和数据线上高低电平的配合关系，这样理解“I2C是靠两条线传一串数据”就非常直观。有一个在仿真里也适用的细节：I2C总线的两条线通常都要接上拉电阻，否则信号拉不高，仿真里的波形会出现台阶，和实物开漏输出忘加上拉时的现象一模一样。

SPI我建议用一个虚拟的SPI Flash模块来做，或者直接驱动仿真的LCD。SPI和I2C最大的区别是有独立的时钟线、独立的收线发线，速度也快很多。在仿真里你可以在“时钟极性”和“时钟相位”这两个配置里切换，配合逻辑分析仪看数据在时钟上升沿还是下降沿被采样，这个概念在实物里不好理解，仿真里波形一放就清楚了。

4. 仿真与真实硬件的差异：踩坑指南和实践技巧

4.1 仿真帮不了你的三件事

仿真很强，但有些事它真的做不到。诚实地把边界讲清楚，能帮你少走很多弯路。

第一件事是电气特性。仿真里不会出现引脚短路冒烟、外设电流过载烧芯片这种情况，但这也意味着你没法在这里学到真实电路中的“敬畏感”。比如一个GPIO到底能拉多少毫安电流、LED限流电阻怎么选，这些必须在真实电路里验证。仿真对于“逻辑正确”很友好，对于“电气正确”无能为力。

第二件事是模拟噪声和干扰。仿真里ADC读数干净得让人觉得传感器世界很美好，但实物中电源纹波、电机干扰、长导线感应噪声都会叠加到信号上。你在仿真里调通的阈值判断程序，拿到实物上可能需要加滤波、迟滞处理才能稳定。这是仿真里没法替代的实战能力。

第三件事是时序的真实性。MDK Simulator跑的是指令级模拟，外设行为的时序是软件建模出来的，和真实芯片内部状态机的行为并不完全一致。特别是DMA并发、多级中断嵌套这类复杂场景，仿真里的表现只能作为参考，不能当作最终结论。我一直的观点是：仿真跑通不代表实物100%没问题，但它能帮你排除掉90%的逻辑错误。

4.2 常见问题快查

我在折腾这套纯软件环境的过程中，整理了下面这张速查表，大部分问题是新手几乎一定会遇到的：

4.3 实测下来比较实用的几个细节

最后分享几个实操里体会比较深的细节，不算机密，但是不试过真的很难注意。

一个是CubeMX生成代码后，MDK里的“Optimization”（优化等级）我建议先用默认值。仿真跑代码时，优化太高会让某些局部变量在调试窗口里看不到，对初学者排查问题很不友好。等仿真没问题了，再调高优化不迟。

另一个是每个外设单独拉通后再组合。我见过不少同学一口气在工程里同时开了UART、PWM、ADC、I2C，结果出问题根本不知道怪谁。我的习惯是：先只点灯，再只跑串口，串口跑通了再往里叠加PWM，每个外设开一个“初始化完成”的printf日志，程序启动后一眼就能看到哪个外设配置失败了。

还有一个不算技巧但很重要的是，仿真工程记得多存档。MDK的Simulator如果没弹出正确波形，我有过几次是把窗口关了重新进入调试模式就好了，比如逻辑分析仪信号列表丢了，或者寄存器窗口显示不全。这种小问题重启调试会话通常能解决，不用怀疑工程文件坏了。

最后分享一点我自己的习惯

每次有人问我“到底先仿真还是先买板子”，我的回答都是：如果你想长期做嵌入式，两者都逃不掉。但顺序很重要，我的实际体会是，先用仿真把外设的原理、寄存器配置、代码流程跑明白，再上手真实板子，会顺利得多。真实板子教你敬畏电路，而仿真教你理解逻辑。先理解逻辑，再去碰电路，那个“敬畏感”才真正能转化为排查问题的能力。纯软件跑完这一轮，你大概就能知道自己对哪个方向最感兴趣，到时候再决定买什么板子、做哪些扩展，钱花得也更有数。