1. 为什么把 STM32 入门做成了“纯软件”版本

琢磨这件事的起因很简单：不少想入门 STM32 的朋友，还没开始写代码就卡在“买板子”这一步。一块常见的开发板几十到几百不等，加上下载器、传感器模块、屏幕、线材，整套下来对刚接触嵌入式的人来说确实是一笔需要犹豫的开销。更麻烦的是，买了板子不代表能顺利跑起来——驱动装不上、下载器识别不到、杜邦线接触不良，这些都是劝退重灾区。

我想做的是把 STM32 入门学习这件事，完全搬到软件里完成。不买任何硬件，不碰下载器，不担心烧坏引脚，只要一台普通电脑，装好软件，就能把 GPIO、定时器、串口、ADC、中断、I2C 这些外设一个个跑通。这个“纯软件”版本不是只做界面演示，而是真正运行 STM32 固件逻辑：LED 会按照代码里的延时闪烁，按键按下能被检测到，串口能发出数据，ADC 能根据电压值算出数字量。说白了，它跑的是同一个工程代码，只是把芯片搬到了仿真环境里。

这套方案适合谁？如果你是零基础想接触 STM32 但不确定要不要投入硬件，如果你出差在外手边没有开发板却想继续验证代码逻辑，如果你想低成本验证某个外设的初始化流程对不对，那这个“纯软件”路线刚好能解决你的问题。

先说清楚一个边界：仿真是学习工具，不是万能工具。它能帮你理解寄存器配置、外设初始化流程、代码逻辑和引脚行为，但替代不了真实芯片的电气特性、信号完整性和复杂调试。把仿真当作一个随时随地能用的“练习场”，在真正上手硬件之前把代码逻辑跑顺，这是它最大的价值。

2. 工具链选型与仿真平台搭建

2.1 我为什么选择 Proteus 做 STM32 仿真

市面上能跑 STM32 的仿真方案其实不止一种。有人用纯软件模拟器，比如 Keil 自带的软件仿真，能看到寄存器和内存变化，但看不到外设的直观行为；有人用 QEMU 这类通用模拟器，功能强但对新手来说配置成本偏高；还有人直接用 Wokwi 这类在线仿真，画电路、写代码都在浏览器里完成，体验也不错。

我最终选择 Proteus，核心原因是它把“电路设计”和“固件运行”结合在了一起。你能在原理图里放置 STM32F103 芯片模型，给它接上 LED、按键、电阻、电位器、虚拟串口终端，然后直接把编译好的 hex 文件烧进去运行。这意味着你既能看到代码执行的结果——比如 LED 亮灭、串口输出的字符，又能看到电路层面的行为——比如引脚电平时序、按键按下瞬间的电平变化。这种“代码 + 电路”的双重视角，对入门阶段理解“程序怎么控制硬件”特别有帮助。

2.2 Proteus 仿真 STM32 的硬件基础

Proteus 仿真 STM32 的机制，和真实开发板不一样。真实板子上，STM32 芯片靠外部晶振提供时钟，代码里配置的是真实硬件寄存器。而在 Proteus 里，STM32 模型本身自带时钟源，你在代码里配置的时钟频率和仿真器内部的时间基准是对应的。

这里有一个关键点：仿真器对 STM32F103 的时钟树支持是有限制的。比如你用 STM32CubeMX 配置了 72MHz 系统时钟，但 Proteus 仿真时实际按什么频率跑，取决于仿真模型的内部实现。实操中一个很典型的现象是：同样的延时函数，在真实板子上延时 500ms，在 Proteus 里可能感觉快一点或慢一点。这不是代码写错了，而是仿真环境的时间模型和真实芯片有差异。

所以在做纯软件版本时，我的建议是：代码里配置时钟是一回事，但调试时不要过分依赖绝对时间精度，多观察相对时序。比如 LED 闪烁周期用示波器看是否稳定、串口波特率是否匹配，这些比纠结“500ms 是否精确”更有实际意义。

2.3 软件环境与仿真配置清单

先说工具组合，我用的是三件套：

• Proteus 8 系列：负责画电路、加载固件、运行仿真
• STM32CubeMX：负责生成初始化代码，配置时钟、引脚和外设参数
• Keil MDK 或任何支持 ARM Compiler 的 IDE：负责编译工程，生成 hex 文件

给新手一个完整路径参考：

1. 在 STM32CubeMX 里选芯片型号 STM32F103C8，配置时钟源为 HSE 或 HSI，配置你要用的外设引脚，生成 Keil 工程。
2. 在 Keil 里写应用代码，编译通过后，在 Options for Target → Output 勾选 Create HEX File，生成 hex 文件。
3. 在 Proteus 里新建原理图，放置 STM32F103C8 模型、LED、电阻、按键等元件，连接好电路。
4. 双击 Proteus 里的 STM32 芯片，在 Program File 里加载 hex 文件，配置晶振频率（一般填 8MHz 或按 CubeMX 设置）。
5. 点击运行，观察电路行为和虚拟终端输出。

注意：Proteus 加载 STM32 hex 文件的坑大多集中在“芯片模型选错”和“晶振频率没配置”。STM32F103C8 在 Proteus 元件库里直接搜 STM32F103C8，别选成 STM32F103R6 或带后缀的变体，引脚数量和内存映射都对不上。

3. 跑通第一个外设：GPIO 控制 LED

3.1 GPIO 的输出模式与推挽结构

GPIO 是 STM32 最简单也最基础的外设，但“跑通”和“理解”是两回事。在仿真里点亮一个 LED，你至少要知道代码在干什么。

STM32 的 GPIO 配置包括两个层面：一是引脚功能，是输出还是输入；二是引脚电气特性，包括推挽、开漏、上拉、下拉这些选项。控制 LED 最常用的是推挽输出模式。推挽的意思就是引脚既能向外灌电流（低电平），也能向外供电流（高电平），这样输出高电平时 LED 两端电压差明显，电流足够驱动 LED 点亮。

在 CubeMX 里配置一个引脚为 GPIO_Output，生成代码后你会看到底层其实是设置了 MODE 寄存器的对应位。理解了这一层，你再去看 GPIOB->ODR 寄存器置 1 或清 0，就明白 HAL_GPIO_WritePin 这个函数到底在操作什么了。

3.2 仿真里的最小电路：LED + 限流电阻

在 Proteus 里给 STM32 接 LED 的方法，我建议严格按真实电路来画：LED 阳极接 MCU 引脚，阴极串联一个电阻到地。电阻阻值取 220Ω 到 1kΩ 都可以。有人喜欢直接把 LED 接到 VCC 和引脚之间，仿真也能亮，但不利于建立正确的电路观。入门阶段就按真实习惯画，后面做实物时直接复用。

仿真代码基本这样写：

while (1) { HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET); HAL_Delay(500); HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET); HAL_Delay(500); }

这段代码跑在 Proteus 里，你会看到 LED 红绿蓝各种颜色灯按 500ms 间隔闪烁。为什么强调“仿真里观察”？因为你可以直接点击仿真面板的暂停按钮，在暂停时检查引脚电平是高还是低，这一招在查初始化配置问题的时候特别有用。

实操心得：仿真里 LED 不亮，先查引脚编号是否和原理图一致。CubeMX 里配置的是 PA5，Proteus 里接的却是 PB5，代码和电路各说各话，这是我在教学里看到最高频的错误。仿真环境没法像真实板子那样用万用表点引脚，所以“对照原理图逐个引脚确认”必须养成习惯。

3.3 GPIO 输入与按键检测：干扰与消抖

按键输入是 GPIO 的另一个典型场景。在仿真里做按键，重点不是“按下去能不能检测到”——这几乎都能做到——重点是“理解为什么需要上拉电阻和消抖”。

STM32 的 GPIO 输入模式下，引脚没有外部驱动时，电平状态是不确定的。所以按键电路一般有两种接法：上拉输入常闭、下拉输入常开。在 CubeMX 里配置引脚为 Input 模式时，可以选择 Pull-up 或 Pull-down，这会在芯片内部接上拉或下拉电阻，省掉外部电阻。但仿真里我建议把外部上拉电阻也画上，因为这样你可以在原理图上直观看到电平是如何被确定的。

按键消抖这个知识点，很多初学者觉得无关紧要，因为仿真里按键按下时不会出现真实机械抖动。但实际项目里按键抖动是真实存在的。我建议你在仿真代码里就把消抖逻辑写进去：检测到低电平后延时 20ms，再确认一次电平状态。这样形成肌肉记忆，后面转真实硬件时少踩一个坑。

消抖代码里有个重要细节：HAL_Delay 放在循环里，会导致整个过程被阻塞，按键响应变慢。真正的工程实现一般用定时器扫描或状态机处理。仿真阶段先用简单延时没问题，但心里要清楚这只是“能跑”，不是“最优解”。

4. 定时器外设仿真实战

4.1 从轮询延时到定时器中断：逻辑的转变

跑通 GPIO 之后，很多人会继续用 HAL_Delay 做延时，直到某一天发现延时期间什么都干不了，才意识到定时器的重要性。这正是开始仿真定时器的好时机。

定时器的核心是计数器。它本质上是硬件层面的一个递增或递减计数器，每来一个时钟脉冲就加一或减一。STM32F103 的定时器时钟来自内部时钟源，经过预分频后得到计数频率，再和自动重载值比较，溢出时产生更新事件或中断。

理解预分频和自动重载是这个阶段最重要的事。打个比方：定时器就像一个闹钟，预分频决定“一秒走几格”，自动重载决定“走到第几格响铃”。通过调整这两个值，你可以把定时中断周期拉得很精确，也可以拉得很长，而不像 HAL_Delay 那样卡住 CPU。

4.2 定时器中断实现 1kHz 周期性任务

CubeMX 里配置 TIM2 为内部时钟，设置预分频 72-1、自动重载 1000-1，如果系统时钟是 72MHz，计数频率就是 1MHz，重载 1000 次产生一次更新中断，即 1kHz。这个计算过程要亲手算一遍，别直接抄参数。

中断回调里做一个标志位或直接翻转 LED：

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

仿真运行时注意一个陷阱：Proteus 里定时器中断的触发频率可能和时钟配置不精确匹配。如果发现 LED 翻转频率明显怪异，不用急着怀疑代码，先在主循环里加一个计数变量，配合虚拟示波器或逻辑分析仪看一下实际中断频率。

4.3 PWM 输出：用示波器验证波形

定时器的另一大用途是产生 PWM。在 CubeMX 里配置 TIM2 的 Channel 为 PWM Generation，设置占空比，代码里开启 PWM 输出。仿真时在 Proteus 里加一个虚拟示波器，直接看引脚上的波形，判断占空比和频率是否符合预期。

这一步的价值在于建立“波形思维”。很多嵌入式初学者对 PWM 的理解停留在“能控制电机速度”上，但没亲眼看过波形。仿真里用示波器观察波形，你就能直观看到占空比从 10% 到 90% 变化时，高电平宽度如何改变。这是后面做舵机、调光、电机控制的重要基础。

我建议你在仿真里试试动态调占空比：用一个按键中断，每按一次，占空比增加 10%，用示波器观察波形变化。这样把定时器、PWM、中断、GPIO 输入串联起来了，一个复合练习顶好几个单独实验。

5. 串口通信仿真与调试技巧

5.1 串口配置背后的波特率计算

串口是嵌入式系统最常见的调试手段之一，也是仿真里最容易出效果的外设。在 Proteus 里跑串口，你能在虚拟终端上看到 MCU 发送的字符——从“代码运行到这里”到“传感器读到了什么值”，整个调试体验和真实开发很接近。

串口配置在 CubeMX 里并不复杂。选择 USART1，配置波特率 115200、数据位 8、无校验、停止位 1。生成代码后，HAL_UART_Transmit 和 HAL_UART_Receive 就能收发数据了。

但“波特率是怎么来的”这个底层逻辑，建议搞清楚。波特率由串口时钟和波特率寄存器共同决定。在 STM32F103 上，串口时钟由 APB2 总线提供，如果 APB2 是 72MHz，那么 USARTDIV 的数值应确保实际波特率接近目标值。仿真时如果发现虚拟终端出现乱码，大概率就是这里的时钟配置和仿真模型不匹配。

5.2 Proteus 的虚拟终端与串行调试

在 Proteus 里，找到 VIRTUAL TERMINAL 元件，把 RX 接到 STM32 对应的 TXD 引脚，把 TX 接到 RXD 引脚——注意，交叉连接。设置虚拟终端的波特率要和代码一致。这个设置很多人忽略：代码里配了 115200，虚拟终端默认 9600，结果全是乱码。这是仿真串口“翻车”的第一大原因。

发送代码大同小异：

char msg[] = "Hello STM32!\r\n"; HAL_UART_Transmit(&huart1, (uint8_t *)msg, strlen(msg), 100);

仿真跑起来后，虚拟终端上就会出现字符串。接收方向的调试思路类似：在虚拟终端打字，MCU 通过中断方式接收，然后把收到的字节再发回去，也就是回显功能。这个小功能看起来简单，但把串口接收中断、环形缓冲思想、发送函数串起来了，值得做一遍。

5.3 在纯软件环境里用串口打印调试信息

真实的嵌入式开发里，printf 重定向是家常便饭。在仿真里也可以这样做，而且更方便。把标准库的 fputc 重定向到 HAL_UART_Transmit，然后就能用 printf 输出格式化的调试信息。

这里有一个常见问题：Keil 环境下使用微库 MicroLIB，printf 重定向更简单，但某些函数在 ARM 编译器的标准库和微库下行为不同。我的建议是入门阶段直接用微库，代码简洁，功能足够。后面做大型项目时再切换到更严格的配置。

串口仿真还有一套高效的排查技巧：

• 发送端正常、接收端没反应：检查虚拟终端的 RX/TX 是否接反
• 有乱码：对一下波特率，尤其是在每个配置步骤之后检查一遍
• 数据重复或丢失：看是不是代码里发送缓冲区没等发完就再次调用发送函数

这些问题的排查思路，和真实硬件调试完全一致。也就是说，你在仿真里建立的调试习惯，能直接迁移到实物开发中。

6. ADC 采样与传感器数据读取仿真

6.1 分辨率、参考电压与采样时间的关系

ADC 外设的仿真让我尤其推荐，因为真实硬件里你可能需要接一个可调电位器才能改变输入电压，而在 Proteus 里同样可以用电位器，效果直观且不用动烙铁。

先理清几个核心概念。STM32F103 的 ADC 是 12 位，意味着它将参考电压（一般是 3.3V）分成 4096 份，输入电压和转换结果的对应关系是线性的。比如输入 1.65V，ADC 读数理论上接近 2048。

分辨率 12 位是硬件决定的，但采样时间可以配置。CubeMX 里可以设置 Sample Time，这个时间影响 ADC 内部采样电容充电的完成度。在一个高低阻抗的输入源上，采样时间太短会导致转换结果不准，甚至读取到的是前一状态的残留值。仿真里不明显，但我建议你仍然按真实项目的习惯配置合理采样时间，不要一味求快。

6.2 电位器模拟传感器，串口输出 ADC 值

在 Proteus 里放置一个 POT-HG 电位器元件，中脚接 STM32 的 PA1，另外两脚分别接 3.3V 和 GND。运行时旋转电位器，引脚电压从 0 到 3.3V 变化。代码里循环读取 ADC，通过串口打印数值。

CubeMX 配置很简单：使能 ADC1，选择通道 1（对应 PA1），分辨率保持 12 位，生成代码后调用 HAL_ADC_Start 和 HAL_ADC_PollForConversion，再读 HAL_ADC_GetValue。

uint32_t adc_val; while (1) { HAL_ADC_Start(&hadc1); if (HAL_ADC_PollForConversion(&hadc1, 100) == HAL_OK) { adc_val = HAL_ADC_GetValue(&hadc1); printf("ADC: %ld\r\n", adc_val); } HAL_Delay(100); }

仿真时旋转电位器，虚拟终端上会看到 ADC 数值连续变化。你可以顺手验证一下线性的边界：旋转到最左端电压接近 0，读数应该在个位数；最右端接近 3.3V，读数应该在 4095 附近。如果两个极端的读数都不对，先查引脚连接和电位器两端接法。

实操心得：仿真里 ADC 读数为 0 或者满量程且不变化，多半不是代码问题，而是电位器两端接反或引脚连错。你可以用 Proteus 的电压探针直接看引脚上的电压值，让“代码看到的电压”和“理论上的电压”对得上。

6.3 用 ADC 数据验证数学换算：电压值计算

有了 ADC 原始读数之后，下一步是把数字量转换成实际电压值。公式非常简单：

电压 = (ADC 读数 / 4096) × 参考电压

如果把参考电压设为 3.3V，那么在代码里：

float voltage = (float)adc_val * 3.3f / 4096.0f;

这个换算本身不复杂，但建议在仿真里认真验证一次：用电压探针测引脚电压，和代码算出的电压值对比，误差应在可接受范围内。这个过程能帮助你建立对 ADC 量化的直觉理解——数字世界里的 4096 个台阶，如何映射回模拟世界的电压。

有了这个基础，后面再接温湿度传感器、光敏电阻、电池电压检测，本质上都是在不同传感器特性下复用同一套 ADC 读取逻辑。仿真阶段把这一环吃透，上实物只是换一个传感器的问题。

7. 中断体系与低功耗设计的仿真验证

7.1 EXTI 外部中断的仿真要点

STM32 的中断体系涉及多个层面：外部中断、定时器中断、串口中断、DMA 传输完成中断等。仿真环境下我建议优先跑通外部中断（EXTI），因为它能直观体现“事件驱动”的编程思维。

CubeMX 里把某个引脚配置为 GPIO_EXTI，触发模式可选上升沿、下降沿或双边沿。生成代码后，Handler 会调用对应的回调函数，你可以在回调里翻转 LED 或修改某个全局变量。

仿真时你在 Proteus 里操作按键，EXTI 引脚电平变化，芯片立刻响应。可以在回调函数里加一个计数器，串口打印“按键按下次数”，用来验证中断触发是否每次都被捕获。

这里必须多说一句：仿真环境的电平变化是理想化的，不存在真实按键的抖动、不存在毛刺。所以你在仿真里测试 EXTI，更多是验证“中断配置对不对”和“回调逻辑是否正确”。真实硬件上要考虑的问题，比如 EMC 干扰造成误触发，仿真里不会出现。这个区别要想清楚，别把仿真结果等同于硬件鲁棒性。

7.2 中断优先级与嵌套逻辑

中断不只是“触发后执行回调”，还有个被很多人忽视的优先级问题。STM32 的 NVIC 支持抢占优先级和子优先级，两个中断同时到来时，优先级高的先执行；如果低优先级中断正在执行，高优先级可以打断它，这叫抢占。

在仿真里验证优先级，有个很直观的办法：用按钮触发外部中断，在中断回调里处理一个长任务，比如延时 200ms；同时定时器每 10ms 触发一次中断，打印时间戳。观察打印顺序，就能看出哪个中断的优先级更高，能不能打断低优先级任务。

这个实验能让“中断优先级”从一个抽象概念变成可见的运行结果。很多初学者在真实项目里遇到“中断里面跑飞了”“长时间不出数据”的问题，都和对优先级理解不透有关。仿真里先把这个逻辑摸清楚，后面写真实代码心里有底得多。

7.3 中断服务函数里为什么不能做耗时操作

提到中断，必须提一个从入门到进阶都适用的原则：中断服务函数里不要做耗时操作。具体来说，不要在中断回调里直接调用 HAL_Delay、printf 重定向、复杂浮点运算。原因是在中断内执行的时间越长，其他中断被挂起的时间就越久，实时性越差。

仿真里你可以故意“犯个错”：在定时器中断回调里打印一串信息，打开虚拟终端看运行效果。你会立刻发现终端输出变得迟钝、不流畅，这就是耗时操作挤占主循环的表现。改成正确定式——中断里只置标志位，主循环里检测标志位再打印——你会感觉到整个系统顺畅多了。

这种“错误示范 + 正确示范”的对比教学方式，特别适合纯软件环境来做。反正不涉及硬件损耗，可以反复折腾，把一种设计决策的后果看得清清楚楚。

8. 仿真环境的常见问题与排查技巧

8.1 一张表格整理我踩过的坑

运行环境稳定，不代表仿真过程顺利。我把实操中最高频的问题整理成了一张表，按发生率排序：

这里面有一个冷却经验：仿真里出现“程序卡死”，最常见的不是代码死循环，而是外设时钟未使能就访问外设寄存器。CubeMX 生成的代码默认会打开外设时钟，但如果你手动添加代码更新寄存器，就可能漏掉 RCC 时钟使能。仿真器对这类问题的表现很直接——程序跑到某条语句就不再前进。

8.2 为什么仿真能跑通、实物不一定能跑通

纯软件版本做得再好，也必须明确一条边界：仿真跑通 ≠ 实物跑通。仿真是理想化的，元件模型没有真实世界中的寄生电容、线路电阻、电源噪声和温度漂移。代码在仿真里表现完美，到了实物上可能遇到以下情况：

• 某些引脚驱动能力不足，LED 亮度比预期暗淡
• 按键抖动导致中断触发多次
• 电源纹波使 ADC 读数不稳定
• 外部干扰导致串口偶发乱码

如果你的目标是扎实掌握 STM32 开发，我的建议是把“纯软件版本”当作第一阶段工具，利用它快速理解外设的原理和代码写法。掌握之后再考虑购置一块入门级开发板，把同样的代码移植到真实硬件上验证一次。仿真帮你建立的大多数直觉和习惯是有效的，剩下的差异通过真实硬件去补齐。

8.3 排查问题的通用思路

仿真环境里的问题排查和真实项目有共通方法论。第一，确认“代码正确”和“电路连接正确”是被独立验证的。仿真时你可以先跑一个最简单的代码，比如只配置一个 GPIO 输出，什么都不做。如果这个都跑不通，那问题多半在环境搭建或芯片模型配置，而不是外设代码。

第二，善用 Proteus 的暂停和单步功能。程序运行时点暂停，你能看到当前执行到的代码行，再结合左侧寄存器窗口查看变量的实时值。仿真器的价值就是让你无限次反复调试，不会烧板子，也不会损坏芯片，所以大胆去看、去改、去试。

第三，把“输出”拆成多个维度。LED 只是一个输出，串口是另一个输出，ADC 数值是第三个输出。当某个外设不工作时，别只盯着它的配置，试着在代码里加一个无关的 LED 闪烁，如果 LED 也不闪了，那问题可能不在这个外设本身，而在整个工程的时钟或启动流程上。

9. 仿真走向实物的迁移路径

9.1 从 Proteus 到真实开发板：代码能复用多少

很多人关心一个问题：我在仿真里写的代码，到了真实开发板上能直接用吗？答案是大部分能，前提是你严格使用标准库或 HAL 库的接口来写应用层代码。HAL_GPIO_WritePin、HAL_UART_Transmit、HAL_ADC_GetValue 这些 API 在开发板上同样存在，你只需要改掉引脚配置（因为实物开发板上 LED 可能接在 PB0 而不是 PA5），重新生成初始化代码，应用层逻辑基本不变。

这实际上是 STM32CubeMX 带来的最大红利：初始化代码由工具生成，应用层逻辑由你编写，两者解耦。你在仿真里反复调通的应用逻辑，迁移到实物时行为一致；而容易出错的时钟树、GPIO 模式、外设参数的配置，CubeMX 无论在哪种环境下都用同一套逻辑生成。

9.2 仿真调试和实物调试的思维差异

仿真环境调试时，你可以暂停、单步、观察变量，体验接近完整。真实硬件调试时，你没有那么多“上帝视角”。你只能通过打印调试信息、观察外围器件反馈、使用示波器或逻辑分析仪来判断系统状态。有些问题只有在硬件上才能暴露，比如引脚初始化前的一瞬间电平状态。

我建议在完成纯软件学习循环之后，有意识地进行一次“盲调”训练：把仿真程序里所有的调试输出全部保留，但完全凭借代码阅读来猜测运行现象，然后用虚拟终端验证猜测。这实际上是在模拟“没有示波器”的调试过程，对提升逻辑推理能力有很大帮助。

9.3 纯软件学习路线的最终状态

一个合理的纯软件 STM32 入门闭环是这样的：能熟练用 CubeMX 建工程 → 能配置 GPIO、定时器、串口、ADC → 能在 Proteus 里画出对应电路并跑通 → 能通过虚拟终端和虚拟示波器分析运行结果 → 能定位并修复外设配置问题。走到这一步，你对 STM32 的整体框架、开发流程、调试方法已经建立起了基础认识。

后面即使没有任何实物，还可以继续深入：DMA 传输、I2C 读取传感器、SPI 驱动屏幕，这些外设都能在仿真环境里跑通。只是要注意，仿真模型的时序精度有限，对于非常依赖精确时间对齐的外设（像 DHT11 这类单总线协议），仿真结果只能做参考，不能作为严格依据。

10. 从“能跑”到“好用”：我的个人体会

做这一套纯软件的入门方案，我最大的体会是：学习嵌入式开发，最大的障碍不是昂贵的硬件，而是“不知道从哪开始”的心理门槛。一旦有了一个随时能打开、随时能实验的环境，很多恐惧感就消失了。你不用小心翼翼护着开发板，不用担心烧错程序造成硬件损坏，可以大胆尝试、大胆改代码，这种心态本身对学习特别重要。

我也清楚记得第一次在仿真里把串口调通、虚拟终端打出“Hello STM32”的场景。那一刻我觉得，原来 STM32 并没有想象中那么神秘。它只是需要你在一个合适的环境里，把“配置引脚 → 写代码 → 观察结果”这个循环走通几遍而已。

最后再分享一个小技巧：把仿真工程像真实项目一样管理，每个外设单独一个文件夹，留下实验记录。比如“GPIO 点灯实验，配置了 PA5 推挽输出，周期 1s”，这样几个月后你再回来看，能很快回忆起当时的思路和踩过的坑。这套纯软件版本的价值，不只是省了买板子的钱，更是给了你一个可以反复试错、完整记录学习过程的自留地。