简介：这份资源面向嵌入式初学者与电子设计开发者，提供在Proteus中完成STM32单片机仿真的完整工程，帮助读者在无实物硬件的情况下验证电路与程序，降低学习与开发成本。压缩包共433个文件，约9.04MB，以290个C源文件与43个头文件为核心，配合Keil工程文件（uvprojx、uvoptx）、编译产物（hex、axf、o、lst、map）以及Proteus工程与备份文件（pdsprj、pdsbak），另含少量汇编、配置与说明文档，覆盖从代码编写到仿真运行的完整链路。资源围绕STM32F103等型号，涉及GPIO、ADC、UART、SPI等外设配置与中断处理，并包含DSP库相关源码，便于读者对照工程结构理解软硬件协同设计流程。目前已有1124人学习下载，适合作为课程设计、毕业设计或自学STM32仿真的参考范例。
1. 在 Proteus 里跑 STM32 仿真：为什么有人十分钟点灯，有人三天出不来波形
很多人第一次在 Proteus 里做 STM32 单片机仿真，卡住的地方根本不是代码，而是“我明明加载了 hex，为什么引脚一点反应都没有”。这个标题讲的就是一件很具体的事：不焊板子、不插下载器，直接在 Proteus 里搭出 STM32 最小系统，加载编译产物，用虚拟示波器和虚拟终端观察 GPIO、串口、定时器的行为。它适合两类人：一类是手头暂时没有开发板、想先把逻辑跑通的学生和初学者；另一类是要给别人演示方案、又不想每次都搬硬件的工程师。需要先摆正预期：Proteus 的 STM32 模型是行为级仿真，时序和真实芯片有偏差，外设覆盖也不完整，它擅长验证“逻辑对不对、引脚配没配对”，不擅长验证“真实波形抖不抖、功耗高不高”。把这一点想清楚，后面很多翻车都能提前避开。
2. 先把最小系统搭对：Proteus 里 STM32 仿真的元件选型与连线
Proteus 仿真 STM32 失败，八成不是程序问题，而是原理图阶段就埋了雷。这一章把“选什么元件、怎么连、时钟怎么给”讲透，后面加载固件才有意义。
2.1 元件库里到底该选哪颗 STM32
打开 Proteus 的 Pick Devices，搜索框输入STM32，你会看到一堆型号。常见做法是优先选STM32F103R6或STM32F103C6这类带F103的型号，原因是它们在 Proteus 的模型库里支持度相对高，GPIO、USART、TIM 这些基础外设都能仿真。不要一上来就选STM32F407或STM32H7，高型号在部分版本里只有引脚图没有行为模型，加载固件后引脚纹丝不动，你会误以为是代码写错了。
选型时看三个信息：一是元件属性里的Program File字段能不能填 hex；二是模型是否标注了Simulation Model；三是引脚数量和你要用的外设是否对得上。如果只是点灯和串口，STM32F103R6足够。选完放到原理图里，别急着连线，先双击元件确认它的时钟频率属性，默认一般是 8MHz 外部晶振，这个值要和你的工程配置一致，否则定时器算出来的时间全是错的。
2.2 最小系统需要哪些外围元件
一个能跑起来的 STM32 仿真最小系统，元件清单其实很短，但每个都不能省：
| 元件 | 作用 | 关键参数 |
|---|---|---|
| STM32F103R6 | 主控 | 时钟属性与工程一致 |
| CRYSTAL | 外部晶振 | 8MHz，接 OSC 引脚 |
| CAP 22pF ×2 | 晶振负载电容 | 接晶振两端到地 |
| RES 10k | NRST 上拉 | 复位脚拉到 VCC |
| BUTTON | 复位按键 | 一端接 NRST，一端接地 |
| LED + RES 330Ω | 观察 GPIO | LED 串电阻接目标引脚 |
| VIRTUAL TERMINAL | 看串口输出 | 接 USART TX/RX |
连线逻辑：晶振两端分别接 OSC_IN、OSC_OUT，各配一个 22pF 到地；NRST 通过 10k 上拉到 VCC，再并一个按键到地；LED 阳极通过 330Ω 电阻接到你要测试的 GPIO，阴极接地（或者反过来，取决于你的输出极性）。串口调试时，把 Virtual Terminal 的 RXD 接到单片机的 TX 引脚，TXD 接到 RX 引脚，注意是交叉接。
提示：Proteus 里电源和地不用画电池，直接用
POWER和GROUND终端符号即可，省事且不会接错。
2.3 时钟和复位这两个“隐形开关”
时钟配置是 Proteus 仿真 STM32 最容易忽略的一环。真实板子上你写RCC_Configuration()去使能 HSE、配 PLL，Proteus 会按你元件属性里的时钟频率去驱动模型。如果你在代码里等 HSE 就绪，而原理图里晶振属性没设对，程序就会死在while(RCC_GetFlagStatus(RCC_FLAG_HSERDY) == RESET)这个循环里，表现就是“仿真跑起来了但什么都没发生”。
稳妥的做法有两种：一是原理图晶振属性设成 8MHz，代码里老老实实配 HSE+PLL；二是干脆用内部时钟 HSI，代码里不依赖外部晶振，仿真更省心。复位同理，NRST 悬空在真实板子上可能还能跑，在仿真里模型可能直接不进主循环，所以 10k 上拉别省。
3. 从 Keil 到 Proteus：固件编译、hex 生成与加载的完整链路
原理图搭好只是搭好了舞台，真正让 STM32 动起来的是 hex 文件。这一章把编译配置、hex 生成、加载和验证串成一条可复现的链路。
3.1 工程里必须打开的 hex 输出选项
很多人写完代码直接编译，然后去 Proteus 里找 hex，发现输出目录里只有.axf没有.hex。原因是 Keil 默认不生成 hex，需要手动开。步骤是：打开Options for Target，切到Output标签页，勾选Create HEX File，下面的Name of Executable保持默认即可。重新编译一次，输出目录里就会出现同名 hex。
如果你用的是别的编译链，比如基于 GCC 的工程，生成 hex 的命令通常是：
# 把 elf 转成 Intel HEX，-O ihex 指定输出格式 arm-none-eabi-objcopy -O ihex build/demo.elf build/demo.hex这条命令里-O ihex是关键参数，它决定输出的是 Intel HEX 格式，Proteus 认这个格式。如果你输出的是 bin，Proteus 加载时会报格式错误或者加载后不运行。
3.2 在 Proteus 里加载 hex 并设置仿真时钟
双击原理图里的 STM32 元件，弹出属性窗口，找到Program File一栏，点右侧文件夹图标选中刚才生成的 hex。同一窗口里还有Clock Frequency，这个值必须和你的工程里配置的系统时钟一致。比如你代码里 PLL 倍频到 72MHz，这里就填 72MHz；如果你填了 8MHz 但代码按 72MHz 算延时，LED 闪烁速度会慢得让你怀疑人生。
加载完成后，点左下角的运行按钮。如果一切正常，你会看到 LED 开始闪、虚拟终端开始吐字符。如果没反应，先别改代码，按下一节的排查顺序走一遍。
3.3 用虚拟示波器和终端验证引脚行为
Proteus 自带虚拟示波器（Oscilloscope）和虚拟终端（Virtual Terminal），这是它比真实板子方便的地方。把示波器的通道 A 接到你翻转的 GPIO 上，运行仿真，就能看到方波。如果方波周期和你代码里算的对不上，回去检查时钟属性。
串口验证更直接：在代码里初始化 USART1，波特率 9600，主循环里每隔一秒发一句字符串。虚拟终端属性里把波特率也设成 9600，运行后应该能看到字符滚动。如果看到的是乱码，九成是两边波特率不一致，或者时钟频率设错导致实际波特率偏移。
// 一个最小的串口发送示例，假设 USART1 已初始化 void USART1_SendString(char *str) { while (*str) { // 等待发送数据寄存器空 while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET); USART_SendData(USART1, *str++); } }这段代码里USART_FLAG_TXE是发送寄存器空标志，每次发一个字节前都要等它置位，否则会丢字节。在 Proteus 里如果不等这个标志，虚拟终端可能只显示第一个字符，后面的全丢了，现象很像“串口坏了”，其实是没做流控。
4. 避坑与排查：Proteus 仿真 STM32 最常见的 5 个翻车现场
这一章按“现象 → 原因 → 解决”整理，都是我在实际仿真里踩过的，按顺序排查能省下大量时间。
现象一：仿真运行了，但 GPIO 完全没反应。原因：最常见的是 hex 没加载成功，或者加载的是旧版本 hex。其次是时钟属性填错，程序卡在时钟就绪等待里。 解决：双击元件确认Program File路径正确，重新编译后重新加载；把Clock Frequency和工程配置对齐；在main函数第一行翻转一个 GPIO，排除是后面代码卡死。
现象二：LED 闪烁频率明显不对，要么快得看不清，要么慢得像卡住。原因：Proteus 的仿真时间和真实时间不是一比一，模型按指令周期推进，复杂外设会拖慢仿真速度。另外时钟属性填错也会导致定时器计算偏差。 解决：先确认时钟属性；再用示波器量实际方波周期，和理论值对比。如果只是仿真慢，属正常现象，不要改代码去迁就。
现象三：串口终端显示乱码。原因：两边波特率不一致，或者系统时钟配置和元件属性不匹配导致实际波特率偏移。 解决：虚拟终端和代码里的波特率设成同一个值；检查Clock Frequency；如果用的是 HSI，注意 HSI 精度在仿真里也可能有偏差，必要时改用 HSE。
现象四：程序在真实板子上跑得好好的，在 Proteus 里就是不动。原因：Proteus 的 STM32 模型不支持某些外设或某些寄存器操作，比如某些 DMA 通道、高级定时器的特定模式。 解决：把不相关的外设初始化暂时注释掉，逐步缩小范围，定位到具体哪个外设导致卡死。确认是模型不支持后，换用基础外设实现同样功能，或者接受“这部分只能在真实板子上验证”。
现象五：加载 hex 时提示格式错误或文件无效。原因：加载的不是 Intel HEX 格式，或者文件路径里有中文、空格导致解析失败。 解决：确认编译输出的是 hex 而不是 axf/bin；把工程和 hex 放在纯英文、无空格的路径下再试。
注意：Proteus 版本差异会直接影响 STM32 模型的支持程度，遇到某个外设死活不通时，先确认你的版本是否支持该型号的该外设，别在代码里死磕。
5. 让仿真更接近真实：进阶技巧与验证习惯
把最小系统跑通只是起点，真正让 Proteus 仿真有价值的，是把它当成一个“逻辑验证沙盒”，而不是“硬件替代品”。这一章讲几个我常用的进阶技巧。
第一个技巧是用Watch Window和断点配合。Proteus 支持在仿真过程中查看变量，虽然不如真实调试器流畅，但足以验证状态机跳转、数组越界这类逻辑问题。做法是在代码里保留调试变量，仿真运行时打开 Watch Window 观察它的变化，比单纯看 LED 闪更能定位问题。
第二个技巧是分阶段验证。不要一次性把 GPIO、串口、定时器、ADC 全写进去再仿真，而是先点灯，通了再加串口，串口通了再加定时器。每加一个外设就重新加载 hex 跑一次，出问题时你立刻知道是哪个环节引入的。这个习惯在真实项目里同样适用，只是在 Proteus 里成本更低，更值得坚持。
第三个技巧是给仿真专门留一套配置。我一般会在工程里建两个目标：一个Debug_Proteus，时钟配置保守、只开基础外设、生成 hex；一个Release_Hardware，完整配置、生成 axf 用于下载。这样切目标就能切换仿真和真实硬件，不会互相干扰。
| 验证项 | Proteus 能验证 | 建议在真实硬件验证 |
|---|---|---|
| GPIO 逻辑翻转 | 是 | 电平、驱动能力 |
| 串口收发逻辑 | 是 | 波特率误差、抗干扰 |
| 定时器计数逻辑 | 是 | 实际精度、抖动 |
| ADC 采样逻辑 | 部分 | 真实模拟量、噪声 |
| 功耗与电源 | 否 | 必须实测 |
最后说一个我自己的习惯：每次在 Proteus 里调通一个功能，我都会把对应的原理图截图和关键配置参数记在一个文本文件里，和工程放在一起。原因很简单，隔两周再打开，你大概率会忘记当时Clock Frequency填的是多少、虚拟终端波特率设的是哪个值。这个习惯帮我省下过好几次“重新排查一遍”的时间。仿真工具的价值不在于它多像真实硬件，而在于它能让你在零成本的前提下把逻辑错误犯完。希望帮到你。
本文还有配套的精品资源，点击获取
