简介：这份资源面向学习STM32嵌入式开发的学生与工程师，提供在Proteus中完成STM32单片机仿真的完整工程实例，帮助读者在无实物硬件的情况下验证软硬件设计、降低开发成本。压缩包共433个文件，约9.04MB，以290个C源文件与43个头文件为核心，配合Keil工程文件（uvprojx、uvoptx）、编译产物（hex、axf、o、lst、map）以及Proteus工程与备份文件（pdsprj、pdsbak），另含少量汇编、配置与说明文档，覆盖从代码编写到仿真运行的完整链路。资源中涉及ADC采样、FFT与DCT等数字信号处理算法实现，可作为外设驱动与算法移植的参考范例。目前已有1124人学习下载，适合希望掌握Proteus+STM32联合仿真流程、积累工程调试经验的读者参考借鉴。

1. 在 Proteus 里跑 STM32 仿真：为什么有人十分钟点灯，有人三天出不来波形

很多人第一次听到「在 Proteus 软件中进行 STM32 单片机的仿真」，脑子里想的是：不就是画个图、加载个 hex、点运行吗？真上手才发现，有人十分钟就把 LED 点起来了，有人折腾三天连时钟波形都出不来。差别不在手速，在于有没有搞清 Proteus 仿真 STM32 的边界——它到底能仿什么、不能仿什么、哪些外设是「模型级」的、哪些只是「示意级」的。

这篇笔记面向三类人：手头没有实物开发板、想先把逻辑跑通的学生和初学者；需要在硬件打样前验证外设时序的嵌入式工程师；以及带课、需要一套可复现演示环境的从业者。核心结论先摆出来：Proteus 能仿真 STM32 的 GPIO、定时器、USART、ADC、部分 SPI/I2C，但它不是真芯片，时钟树、中断优先级、DMA 这些地方和实物有偏差，把它当「逻辑验证器」而不是「性能测试仪」，心态就对了。下面按选型、建模、写码、联调、避坑的顺序，把这条路走一遍。

2. 先选对芯片模型和工程模板：Proteus 里 STM32 的可用边界

2.1 哪些 STM32 型号在 Proteus 里有像样的模型

Proteus 的元件库对 STM32 的支持是不均匀的。经验上，F1 系列（如 STM32F103 系列）的模型最成熟，GPIO、USART、定时器、ADC、SPI 基本可用；F4 系列部分型号有模型，但外设覆盖不如 F1；到了 F7、H7 这些高性能系列，库里要么没有，要么只是个空壳，加载 hex 后行为诡异。所以选型第一条：仿真阶段优先用 F103 这类经典型号，等逻辑验证完再迁移到目标芯片。

选型时还要注意封装和引脚数。同一个型号不同封装，Proteus 里的引脚映射不一样，画原理图时如果拿 64 脚的图去配 100 脚的 hex，引脚对不上，现象就是「程序跑了但外设没反应」。常见做法是：先在目标工程里确认芯片具体型号和封装，再到 Proteus 里搜同名器件，核对引脚数一致再往下走。

2.2 建立工程模板：时钟和启动文件先对齐

Proteus 仿真 STM32 最容易翻车的地方是时钟。实物上你写SystemInit()配 72MHz，芯片就跑 72MHz；仿真里如果时钟源模型没配对，定时器周期、USART 波特率全错。所以工程模板要先把时钟树固定下来。

以常见的 F103 + 8MHz 外部晶振为例，在代码里显式配置：

// system_stm32f10x.c 中的时钟配置片段（简化示意） // 目标：HSE 8MHz -> PLL x9 -> SYSCLK 72MHz #define SYSCLK_FREQ_72MHz 72000000 static void SetSysClockTo72(void) { // 使能 HSE RCC->CR |= ((uint32_t)RCC_CR_HSEON); // 等待 HSE 就绪，超时则退回 HSI while ((RCC->CR & RCC_CR_HSERDY) == 0) { /* 超时处理略 */ } // 配置 PLL：HSE 作为源，9 倍频 RCC->CFGR &= ~RCC_CFGR_PLLSRC; RCC->CFGR |= RCC_CFGR_PLLSRC_HSE; RCC->CFGR &= ~RCC_CFGR_PLLMULL; RCC->CFGR |= RCC_CFGR_PLLMULL9; // 使能 PLL 并等待锁定 RCC->CR |= RCC_CR_PLLON; while ((RCC->CR & RCC_CR_PLLRDY) == 0) { } // 切换系统时钟到 PLL RCC->CFGR &= ~RCC_CFGR_SW; RCC->CFGR |= RCC_CFGR_SW_PLL; while ((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_PLL) { } }

这段代码的逻辑是：先开 HSE，等它稳定，再配 PLL 倍频，最后把系统时钟切过去。参数上，PLLMULL9对应 8MHz 输入得到 72MHz；如果你在 Proteus 里用的是内部 HSI（8MHz 且精度差），倍频后频率会偏，定时器就不准。所以仿真时也建议挂一个外部晶振模型，和实物保持一致。

启动文件（startup_stm32f10x_md.s）要和芯片容量匹配：小容量用 ld、中容量用 md、大容量用 hd。选错了，中断向量表偏移不对，现象是「一进中断就跑飞」。这一步没有捷径，对着芯片手册的 Flash 容量选。

3. 在 Proteus 里搭最小系统：从电源到下载口的连线细节

3.1 最小系统的元件清单和连线顺序

搭最小系统不要一上来就堆外设，先把「能跑起来」这件事做扎实。元件清单如下：

• STM32F103 芯片模型 1 片
• 8MHz 晶振 1 个 + 22pF 电容 2 个
• 复位电路：10k 上拉 + 100nF 电容
• 电源：VDD/VDDA 接 3.3V，VSS/VSSA 接地
• BOOT0 下拉电阻（10k 到地）
• 一个 LED + 限流电阻（330Ω~1k）接某个 GPIO

连线顺序建议：先电源和地，再晶振，再复位，最后 BOOT0 和 LED。为什么强调顺序？因为 Proteus 里电源网络如果没连全，芯片模型会「静默不工作」，不报错也不跑，新手很容易卡在这。连完用电气规则检查（ERC）扫一遍，比肉眼靠谱。

3.2 加载 hex 和设置仿真参数

代码编译出 hex 后，双击芯片模型，在属性里找到Program File一栏，指向 hex 路径。同时把Clock Frequency设成和代码一致的 72MHz（或你实际用的频率）。这两个参数不一致，是「程序明明对但外设不动」的头号原因。

# 用命令行工具链编译出 hex 的典型流程（以常见 ARM 工具链为例） # 1. 编译 arm-none-eabi-gcc -c -mcpu=cortex-m3 -mthumb main.c -o main.o # 2. 链接，指定链接脚本 arm-none-eabi-ld -T stm32f103.ld main.o -o main.elf # 3. 转 hex arm-none-eabi-objcopy -O ihex main.elf main.hex

这三步的含义：编译把 C 变成目标文件，链接按链接脚本把代码段、数据段放到正确地址，objcopy 转成 Proteus 能读的 hex 格式。参数上，-mcpu=cortex-m3要和芯片内核匹配，F103 是 M3 内核，写成 M4 虽然可能编过，但指令集差异会在仿真里暴露。链接脚本里的 Flash 起始地址通常是 0x08000000，改错了 hex 加载后 PC 指针就跑偏。

提示：Proteus 加载 hex 后如果没反应，先看仿真日志窗口有没有「invalid opcode」或「no program file」之类的提示，比盲猜快得多。

4. 用 GPIO 和定时器验证仿真是否真的在跑

4.1 点灯只是开始：用定时器中断确认时钟真的对

点灯能亮，只说明 GPIO 通了，不代表时钟对。真正验证时钟的办法是用定时器做一个精确的 1Hz 翻转，然后用 Proteus 的虚拟示波器看波形周期。如果示波器量出来是 1Hz，说明时钟树基本正确；如果偏成 0.5Hz 或 2Hz，就是时钟配置或 Proteus 时钟参数的问题。

// TIM2 定时 500ms 中断，实现 1Hz 翻转 void TIM2_Config(void) { RCC->APB1ENR |= RCC_APB1ENR_TIM2EN; // 使能 TIM2 时钟 TIM2->PSC = 7199; // 预分频：72MHz / (7199+1) = 10kHz TIM2->ARR = 4999; // 自动重装：10kHz / (4999+1) = 2Hz 更新 TIM2->DIER |= TIM_DIER_UIE; // 使能更新中断 TIM2->CR1 |= TIM_CR1_CEN; // 启动定时器 NVIC_EnableIRQ(TIM2_IRQn); // 使能 NVIC 中断 } void TIM2_IRQHandler(void) { if (TIM2->SR & TIM_SR_UIF) { TIM2->SR &= ~TIM_SR_UIF; // 清中断标志 GPIOA->ODR ^= GPIO_ODR_ODR5; // 翻转 PA5 } }

参数说明：PSC=7199把 72MHz 分频到 10kHz，ARR=4999让计数器每 5000 个计数溢出一次，即 2Hz 中断，中断里翻转 IO 得到 1Hz 方波。这里的关键是预分频和重装值都要减一，这是 STM32 定时器的固定规则，忘了减一周期就错。在 Proteus 里接虚拟示波器到 PA5，量周期应该是 1 秒。

4.2 虚拟示波器和虚拟终端的用法

Proteus 自带虚拟示波器（Oscilloscope）和虚拟终端（Virtual Terminal）。示波器看波形，终端看串口输出。用示波器时，把通道探针接到目标引脚，仿真运行后波形会实时刷新。注意示波器的时基要调对，时基太小看不到完整周期，太大波形挤成一团。

虚拟终端用于 USART 调试：把 STM32 的 TX/RX 接到虚拟终端的 RXD/TXD，设置相同波特率，就能在终端窗口看到printf输出。这一步能验证 USART 配置是否正确。常见坑是波特率算错——F103 的 USART 挂在 APB2（72MHz）或 APB1（36MHz）上，算波特率时要看总线频率，用错总线频率，终端里就是乱码。

5. 避坑与排查：Proteus 仿真 STM32 最常见的 5 个翻车现场

5.1 现象：程序加载了但芯片完全不动

原因通常是三类：hex 路径没设对、时钟频率参数和代码不一致、电源网络没连全。排查顺序是：先看芯片属性里 Program File 是否指向存在的 hex，再看 Clock Frequency 是否和代码一致，最后用 ERC 检查电源和地。这三步能解决八成「完全不动」的问题。

5.2 现象：GPIO 能翻转但定时器周期不对

这是时钟树的问题。要么代码里时钟配置和 Proteus 参数不一致，要么预分频/重装值算错。解决方法是先用示波器量系统时钟相关的输出（比如 MCO 引脚），确认时钟频率，再回头核对 PSC 和 ARR 的计算。记住公式：中断频率 = 时钟 / ((PSC+1) * (ARR+1))。

5.3 现象：串口终端里全是乱码

波特率不匹配是主因。检查三处：代码里 USART 的波特率寄存器值、Proteus 虚拟终端的波特率设置、以及 USART 挂在哪条总线上。F103 的 USART1 在 APB2，其余在 APB1，两条总线频率不同，算波特率时分母不一样。用错总线频率，实际波特率就偏，终端自然乱码。

5.4 现象：中断进不去或进去一次就卡死

中断向量表偏移和优先级配置是重点。启动文件选错（容量不匹配）会导致向量表地址不对；NVIC 优先级分组没设，多个中断可能互相打断出乱象。解决方法是核对启动文件、确认NVIC_PriorityGroupConfig调用、并在中断里及时清标志位。忘了清标志，中断会反复触发，看起来就像卡死。

5.5 现象：仿真跑一会儿就变慢或卡顿

Proteus 是软件仿真，CPU 占用高时仿真速度会下降，尤其是开了示波器、终端、多个外设模型时。这不是代码问题，是仿真器性能问题。缓解办法：关掉暂时不用的虚拟仪器、降低示波器采样密度、把不相关的外设模型从原理图里移除。如果还是卡，说明这个模型太重，考虑换更简单的验证方式。

6. 把仿真变成可复用的验证流程：我的三个固定习惯

第一个习惯是先仿真后打样，但只仿真逻辑不仿真性能。GPIO 时序、状态机跳转、协议帧格式这些用 Proteus 验证性价比很高；但 ADC 精度、DMA 吞吐、中断响应延迟这些，仿真结果和实物差得远，别拿仿真数据当性能依据。我一般会在仿真里把功能逻辑跑通，把边界条件（比如按键抖动、超时重试）测一遍，然后直接上实物验证性能。

第二个习惯是给每个仿真工程配一份参数对照表。表里记清楚：芯片型号、封装、时钟源和频率、Proteus 时钟参数、关键外设的总线归属。这份表在换芯片或换电脑重装 Proteus 时能救命，因为参数不一致是仿真失败的头号原因，有表可查就不用重新试错。

第三个习惯是用版本管理管仿真工程。Proteus 工程文件（.pdsprj）和代码分开管理，每次改完原理图或代码都提交一次，并在提交信息里写清「改了什么、验证了什么现象」。这样当仿真行为突然变化时，能快速定位是哪次改动引入的。血泪经验：有一次改了个电阻值，仿真就不跑了，翻提交记录才发现是误删了一根电源连线，没有版本管理的话，这种问题能查一下午。

最后一个具体技巧：善用 Proteus 的仿真日志和断点。很多人不知道 Proteus 支持在源码级设断点（需要配合调试信息），也忽略了仿真日志窗口。日志里会打印模型加载、内存访问异常等信息，遇到「玄学」问题时，先看日志再动手改，比盲目试参数高效得多。希望帮到你。

本文还有配套的精品资源，点击获取