简介：面向嵌入式初学者与电子设计竞赛备赛者的STM32+Proteus仿真实践包，围绕在虚拟环境中完成STM32硬件搭建、程序加载与软硬件联合调试展开，可用于课程实验、毕业设计原型验证及Keil工程复现。压缩包共433个文件，约9.04MB，以290个C源文件、43个头文件为主，并含Keil工程（uvprojx、uvoptx）、Proteus工程（pdsprj）、HEX烧录文件、汇编与链接脚本、调试及中间产物，完整保留从源码到仿真验证的工程结构。已有1128人学习。读者可据此理解STM32外设初始化、AD采集示例、库文件组织与工程编译配置，借助Proteus观察I/O状态和信号波形，并参考现有工程排查编译、下载与仿真不匹配等问题，适合边做边学与二次开发。
1. Proteus 里跑 STM32：为什么有人五分钟点亮，有人卡在第一步
Proteus 的 STM32 仿真是典型的“看起来简单、上手就卡住”的活。从元件库里拖一个 STM32F103R6 出来，双击选中 HEX，点运行，引脚电平一动不动——八成不是程序写错，而是模型、时钟、固件三者没对齐。这份资源包给的就是把这套对齐关系固定下来的东西：Proteus 工程底稿、配套可编译的固件工程、最小系统与常用外设的仿真电路，以及一份把编译输出接到仿真器上的操作说明。手上暂时没有开发板、想先把逻辑跑通的人，拿它当底稿改比从零画原理图省事得多；要给别人讲外设时序又不想搬硬件的人，也能直接拿它当演示台。它的门槛不在语法，而在“编译—加载—观测”这条链路有没有一次配平。
2. 选型与最小系统：STM32F103R6 的四个参数决定仿真能不能起来
Proteus 的 VSM 模型不是照着数据手册一比一复刻的，它是行为级模型：引脚翻转、串口收发、定时器计数这些能对上，但涉及到模拟精度、USB 协议栈、DMA 仲裁这类深水区，模型往往只做简化处理。所以第一步不是写代码，而是把“用哪个型号、画哪几根线、属性填什么”这三件事定死。这三件事定不下来，后面调试会一直在毫无依据的环境里反复试错。
2.1 模型库里三个常见 F103 型号的差别
同一个固件，换成不同型号的模型，仿真结果可能完全不一样。常见型号的差异大致是这样：
| 型号 | 引脚数 | Flash | RAM | 模型完整度 | 适合的场景 |
|---|---|---|---|---|---|
| STM32F103R6 | 64 | 32KB | 10KB | 较完整，多数版本自带 | 最小系统、GPIO、串口、定时器教学演示 |
| STM32F103C8 | 48 | 64KB | 20KB | 需较新版本模型库 | 引脚需求少的小项目，外设演示 |
| STM32F103RB | 64 | 128KB | 20KB | 部分版本仅基础模型 | 程序体量偏大、需要更多 RAM 的场景 |
选 R6 的理由很实在：引脚多，接 LCD、按键、串口、ADC 激励源不用挤在十几个 IO 上；模型在多数 Proteus 版本里自带，不用额外装库；32KB Flash 对仿真演示级别的固件绰绰有余。代价是 RAM 只有 10KB，一旦你在里面开大数组、跑 FatFs 或者塞一个 4KB 的发送缓冲，编译能过、仿真直接卡死或者进 HardFault，很容易被误判成“模型有问题”。
判断自己的工程能不能塞进去，最直接的办法是看编译输出的.map文件，确认Total RO Size + RW Size没有贴着 32KB 走、RW Data + ZI Data没超过 10KB。留 20% 余量是底线，行为级模型本身还要吃掉一部分内存。
提示：如果打开别人的工程时双击 MCU 提示模型找不到，先别怀疑文件损坏，多数是版本里没有对应型号。换 R6 重新编译一次，比到处找模型库省时间。
2.2 最小系统在原理图上要落的六条线
Proteus 里的 STM32 元件默认把 VDD、VSS 这些电源引脚设为隐藏并自动连接，所以原理图上你看不到电源网络，但这不代表可以不管供电配置。真正需要动手接的，是下面这几条：
- NRST 复位脚：接 10k 上拉到 VDD，再并一个 100nF 电容到地，串一个按键到地。Proteus 里不接复位电路，仿真通常也能跑，但一旦程序跑飞，你连个手动复位的入口都没有，只能关掉仿真重开。
- BOOT0：用 10k 下拉到地。悬空在实物上是大忌，在仿真里虽然模型不一定严格解释，但保持这个习惯能让原理图和实物对得上。
- 外部晶振：8MHz 晶振两端各接一颗 22pF 电容到地。Proteus 的仿真时钟由 MCU 属性里的 Clock Frequency 决定，晶振电路更多是让图纸完整，但省掉它以后你要换成实物板，图纸就废了。
- 去耦电容：每对 VDD/VSS 旁边放 100nF。仿真里没影响，画图习惯问题。
- 调试串口：USART1 的 PA9/PA10 引到 Virtual Terminal 元件上，TXD 接终端 RXD、RXD 接终端 TXD，交叉接。这是后面排查问题的主力通道，一开始就画上。
- 至少一个可控输出：比如 PA5 接一个 LED 串 330Ω 到地，或者接一个电压探针。没有可见输出，你无法判断程序到底跑没跑。
画完这些，工程就可以保存为模板了。以后每个新实验复制一份改，别每次从空白图开始。
2.3 属性面板里三个必须改的参数
双击 MCU 元件弹出的属性框，是整条链路最容易出错的地方。真正需要关注的只有三个：
| 属性项 | 推荐值 | 填错的后果 |
|---|---|---|
| Program File | 固件工程输出目录下的.hex | 空着就是空芯片，引脚全无反应 |
| Clock Frequency | 8MHz（与固件 HSE_VALUE 一致） | 串口波特率整体偏移，终端满屏乱码 |
| 元件命名（Reference） | U1、U2 顺序编号 | 多 MCU 或多模块时排查找不到对象 |
Clock Frequency 这一项值得多说两句。它是仿真内核的基准时钟，而固件里的 RCC 配置（HSE 起振、PLL 倍频到 72MHz）在行为级模型里只被部分解释。稳妥的做法是让两边的“源头”对齐：属性里填 8MHz，固件里 HSE_VALUE 也定义 8MHz，波特率计算按固件实际跑起来的 PCLK 走。跑不通的时候，两个值一起改、用虚拟终端反推，比死磕某一个更有效。
改完 HEX 路径，建议顺手确认一下加载的是不是最新编译产物。我一般会在编译脚本后面挂一条检查：
# 找出比 main.c 更新的 hex；没有输出说明 hex 是旧的，Proteus 会加载到上一版固件 find ./output -name "*.hex" -newer ./src/main.c -print-newer是拿文件的修改时间做比较，输出为空就意味着源码改过了但没重新编译。这个坑非常隐蔽：现象是“我明明改了代码，仿真一点变化都没有”，实际是 Proteus 加载的还是上次那个 hex。养成编译后跑一遍这条命令的习惯，能省掉大量无意义的自我怀疑。
3. 编译链路打通：从 Keil 工程到能被 Proteus 吃进去的 HEX
Proteus 不认.uvprojx，也不认.axf（部分版本能读 ELF 调试信息，但加载程序还是走 hex），它只认 Intel HEX。所以整条链路的关键节点是：Keil 有没有产出 hex、hex 里的时钟假设和 Proteus 属性对不对得上、加载后用什么手段确认程序真的在跑。
3.1 三个编译开关决定有没有 HEX
打开 Options for Target，三处必须确认：
- Output 页 → Create HEX File：不勾这项，编译只会产出
.axf，Proteus 里选文件时你根本看不到 hex。 - Target 页 → Use MicroLIB：如果你的代码里有
printf，不勾这个，标准库的重定向会拉进一大堆用不到的东西，10KB RAM 的 R6 很容易被撑爆。 - C/C++ 页 → Define：填
STM32F10X_MD,USE_STDPERIPH_DRIVER。前者告诉库你用的是中容量芯片，后者启用标准外设库。少一个都会编译报错或者链接出一堆未定义符号。
日常我就是命令行编译，省得每次点菜单：
# -b 后台编译整个工程，-j0 不弹任何对话框，-o 把日志写到 build.log # 返回码 0 表示没有 error；返回 1 说明有 error，去 build.log 里搜 "error:" UV4.exe -b ".\Project\STM32_Demo.uvprojx" -j0 -o ".\build.log"-b是 build 模式，等价于点“Rebuild All”，会先清再编；-j0抑制所有弹窗，适合放进批处理里连续跑；-o把编译输出重定向到文件，脚本里 grep 关键字比看滚动窗口靠谱。注意UV4.exe的路径要按自己的安装位置改，别直接抄。
3.2 时钟宏对不上，串口一定是乱码
固件里跟仿真时钟直接挂钩的是system_stm32f10x.c中的HSE_VALUE：
/* 这颗宏必须等于原理图上那颗晶振的频率，单位是 Hz 写错的话 SystemInit 里算出来的 PLL 倍频系数是错的， 最终 PCLK 跟着错，USART 的 BRR 寄存器值也就错，终端必然乱码 */ #if !defined HSE_VALUE #define HSE_VALUE ((uint32_t)8000000) #endif /* SystemInit 之后系统时钟被配置成 72MHz： HSE 8MHz / 1 * 9 = 72MHz，AHB 不分频，APB2 不分频，APB1 二分频 = 36MHz */改完这个宏，务必整工程 Rebuild，而不是增量编译——这个头文件被大量.c引用，增量编译有时候不会全部重编。判断当前系统时钟对不对，最直接的办法是把SystemCoreClock变量打到串口上，或者在调试窗口里看它的值，应该是 72000000。
还有一处容易漏：如果你的工程是从别人的模板拷来的，stm32f10x.h里可能同时存在HSE_VALUE的默认定义，两边打架时以先展开的为准。编译时如果看到HSE_VALUE redefined之类的警告，一定要处理掉，别当成噪音。
3.3 加载与观测：三种手段各管一段
HEX 加载进去之后，靠什么判断程序在正常跑，决定了你排查问题的效率。三种手段分工不同：
| 手段 | 放置方式 | 能看什么 | 局限 |
|---|---|---|---|
| Virtual Terminal | 接 USART 的 TX/RX（交叉） | 打印字符串、变量值、状态机跳转 | 波特率必须与固件一致，否则全是乱码 |
| 示波器（Oscilloscope） | 探针接目标引脚 | PWM 频率、占空比、脉冲宽度 | 时间窗口窄，看长周期事件不方便 |
| 逻辑分析仪 / 数字图表 | 添加 Digital Analysis，选引脚 | 多路时序关系、I2C/SPI 波形、中断响应间隔 | 需要设置采样率和时间轴，初次配置麻烦 |
我的习惯是先上虚拟终端。串口能打字符，说明时钟、启动文件、中断向量表这几层基本是通的，剩下的问题都在具体外设上。串口一个字都收不到，问题就在更底层——时钟没起来、GPIO 复用没配、或者 hex 根本没加载。
配置虚拟终端的步骤：元件库搜VIRTUAL TERMINAL，放到图纸上，双击把 Baud Rate 设成跟固件一致（比如 115200），然后把 MCU 的 PA9（TX）接到终端的 RXD、PA10（RX）接到终端的 TXD。注意是交叉，不是同名相接。很多人第一次接错就是这里，现象是能发不能收，或者干脆两边都没反应。
4. 外设仿真实战：GPIO、USART、定时器、ADC 的四段配置
外设代码本身不难，难的是“仿真环境下的参数该填多少”。同一个配置在实物上跑得好好的，搬进 Proteus 可能出现频率偏移、采样值不动、中断不触发。这一章把四个最常被仿真用到外设的配置写清楚，每一段都标出参数是怎么算出来的。
4.1 GPIO 输入输出与按键
先看一段最小可用的按键扫描，按键接 PA0 到地，LED 接 PA5：
#include "stm32f10x.h" /* PA0 上拉输入：按键另一端接 GND，平时读 1，按下读 0 PA5 推挽输出：驱动 LED，串 330Ω 限流电阻到地 */ void Key_Led_Init(void) { GPIO_InitTypeDef gpio; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); gpio.GPIO_Pin = GPIO_Pin_0; gpio.GPIO_Mode = GPIO_Mode_IPU; /* 上拉输入，省掉外部上拉电阻 */ gpio.GPIO_Speed = GPIO_Speed_50MHz; /* 输入模式下该项被忽略 */ GPIO_Init(GPIOA, &gpio); gpio.GPIO_Pin = GPIO_Pin_5; gpio.GPIO_Mode = GPIO_Mode_Out_PP; /* 推挽输出，能主动拉高拉低 */ GPIO_Init(GPIOA, &gpio); GPIO_SetBits(GPIOA, GPIO_Pin_5); /* 默认灭：LED 阳极接 PA5 时是高电平点亮 */ } /* 10ms 节拍调用的扫描函数，非阻塞；返回 1 表示检测到一次有效按下 */ uint8_t Key_Scan_10ms(void) { static uint8_t last = 1, cnt = 0; uint8_t now = GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0); if (now != last) { /* 电平发生变化，开始计时 */ if (++cnt >= 2) { /* 连续两次采样一致才认，等效 20ms 消抖 */ last = now; cnt = 0; if (now == 0) return 1; /* 只在下降沿（按下）时返回 */ } } else { cnt = 0; /* 电平稳定，计数器清零 */ } return 0; }这段的关键在GPIO_Mode_IPU。仿真里如果没有外部上拉，用浮空输入GPIO_Mode_IN_FLOATING读到的电平是不确定的，Proteus 会给一个灰色/未知状态，你的按键逻辑就会随机跳。上拉输入让引脚有确定的默认电平，这是仿真里比实物更需要在意的一点。
消抖的写法用“连续两次采样一致”，而不是delay_ms(20)。原因是仿真里的软件延时跟真实时间不是一比一，for循环空转在仿真器里可能跑得飞快也可能极慢，用固定延时消抖会让按下响应时间变得不可预测。用 10ms 定时节拍采样，抖动窗口由定时器决定，跟仿真速度解耦。
注意：Proteus 里按键元件有
BUTTON和SWITCH两种，前者是点动、松手即断，后者是自锁。用错元件会出现“按一下灯亮、再按一下不灭”的现象，很容易被误判成代码里的状态机写错。
4.2 USART 与虚拟终端
串口是仿真里最有价值的观测通道，配置也就三行关键代码：
#include "stm32f10x.h" #include <stdio.h> /* 115200-8-N-1：PCLK2 = 72MHz 时，BRR = 72000000 / (16 * 115200) = 39.0625 库函数会自动算小数部分，但前提是 RCC 配置正确、SystemCoreClock 变量准确 */ void Uart1_Init(uint32_t baud) { GPIO_InitTypeDef gpio; USART_InitTypeDef uart; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_USART1, ENABLE); gpio.GPIO_Pin = GPIO_Pin_9; /* TX：复用推挽输出 */ gpio.GPIO_Mode = GPIO_Mode_AF_PP; gpio.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &gpio); gpio.GPIO_Pin = GPIO_Pin_10; /* RX：浮空输入或上拉输入 */ gpio.GPIO_Mode = GPIO_Mode_IN_FLOATING; GPIO_Init(GPIOA, &gpio); uart.USART_BaudRate = baud; uart.USART_WordLength = USART_WordLength_8b; uart.USART_StopBits = USART_StopBits_1; uart.USART_Parity = USART_Parity_No; uart.USART_HardwareFlowControl = USART_HardwareFlowControl_None; uart.USART_Mode = USART_Mode_Tx | USART_Mode_Rx; USART_Init(USART1, &uart); USART_Cmd(USART1, ENABLE); } /* printf 重定向：MicroLIB 下实现 fputc 即可，逐个字符阻塞发送 */ int fputc(int ch, FILE *f) { while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET); USART_SendData(USART1, (uint8_t)ch); return ch; }GPIO_Mode_AF_PP这一项写错是高频翻车点：TX 脚配成普通推挽输出，串口照样能“发出”数据，但波形不对，虚拟终端收到的就是乱码或者什么都收不到。原因是复用功能没接管引脚，输出的是 GPIO 寄存器的值而不是 USART 移位寄存器的输出。
另外，while (TXE == RESET)这个等待循环在仿真里可能变成死等——如果 USART 时钟没使能、或者 TX 引脚被别的外设占用，TXE 标志永远不置位，程序就卡在这行，表现出来是“程序刚开始跑就停住了”。排查时在fputc前后各翻转一个空闲 IO，用示波器看，能立刻定位卡在哪。
4.3 定时器 PWM 与示波器探针
PWM 是仿真里最容易“看着不对”的外设，因为频率和占空比都是算出来的，任何一级分频错都会体现在波形上：
/* 目标：TIM1_CH1（PA8）输出 1kHz、30% 占空比的方波 计数时钟 = 72MHz / (PSC + 1) = 72MHz / 72 = 1MHz 周期 = (ARR + 1) / 1MHz = 1000 / 1MHz = 1ms → 1kHz 占空比 = CCR / (ARR + 1) = 300 / 1000 = 30% */ void PWM_Init(void) { GPIO_InitTypeDef gpio; TIM_TimeBaseInitTypeDef tb; TIM_OCInitTypeDef oc; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_TIM1, ENABLE); gpio.GPIO_Pin = GPIO_Pin_8; gpio.GPIO_Mode = GPIO_Mode_AF_PP; /* PWM 输出必须走复用推挽 */ gpio.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &gpio); tb.TIM_Prescaler = 71; /* 72 分频，得到 1MHz 计数时钟 */ tb.TIM_Period = 999; /* 自动重装值，决定周期 */ tb.TIM_CounterMode = TIM_CounterMode_Up; tb.TIM_ClockDivision = TIM_CKD_DIV1; TIM_TimeBaseInit(TIM1, &tb); oc.TIM_OCMode = TIM_OCMode_PWM1; oc.TIM_OutputState = TIM_OutputState_Enable; oc.TIM_Pulse = 300; /* 比较值，改这个就是改占空比 */ oc.TIM_OCPolarity = TIM_OCPolarity_High; TIM_OC1Init(TIM1, &oc); TIM_CtrlPWMOutputs(TIM1, ENABLE); /* 高级定时器必须开主输出，否则引脚无波形 */ TIM_Cmd(TIM1, ENABLE); }参数之间的关系就三个公式：f_pwm = 72MHz / ((PSC+1) * (ARR+1))、占空比 = CCR / (ARR+1)、分辨率 = 1 / (ARR+1)。想提高占空比精度就加大 ARR，但频率会跟着降；要保频率又要高分辨率，就只能提高计数时钟或者换更高主频。
TIM_CtrlPWMOutputs(TIM1, ENABLE)这行是 TIM1/TIM8 这类高级定时器独有的，普通定时器（TIM2~TIM5）不需要。漏了它的现象特别典型：代码逻辑全对、寄存器值也对，示波器上就是一条直线。这个坑我在第一次用 TIM1 时踩过，翻了半天寄存器才发现是主输出开关没开。
观测时，示波器的探针接 PA8，时间轴设成 200μs/格 左右，1kHz 的波形一格能看到两个完整周期。如果看到的是方波但频率差很多，先回去核对 Clock Frequency 属性；如果看到的是直线，先查复用配置和主输出开关。
4.4 ADC 采样与激励源
Proteus 里 ADC 引脚悬空读到的是不确定值，必须外接激励源。做法是从元件库拖一个DC VOLTMETER或者可调电位器POT-HG，接到 ADC 的输入引脚上。
/* PA1 作为 ADC1_IN1 的模拟输入，单次转换、软件触发、右对齐 */ void Adc1_Init(void) { GPIO_InitTypeDef gpio; ADC_InitTypeDef adc; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_ADC1, ENABLE); RCC_ADCCLKConfig(RCC_PCLK2_Div6); /* 72MHz / 6 = 12MHz，不超过 14MHz 上限 */ gpio.GPIO_Pin = GPIO_Pin_1; gpio.GPIO_Mode = GPIO_Mode_AIN; /* 模拟输入，必须设成 AIN，不能是浮空 */ GPIO_Init(GPIOA, &gpio); adc.ADC_Mode = ADC_Mode_Independent; adc.ADC_ScanConvMode = DISABLE; adc.ADC_ContinuousConvMode = DISABLE; adc.ADC_ExternalTrigConv = ADC_ExternalTrigConv_None; adc.ADC_DataAlign = ADC_DataAlign_Right; adc.ADC_NbrOfChannel = 1; ADC_Init(ADC1, &adc); ADC_RegularChannelConfig(ADC1, ADC_Channel_1, 1, ADC_SampleTime_55Cycles5); ADC_Cmd(ADC1, ENABLE); ADC_ResetCalibration(ADC1); while (ADC_GetResetCalibrationStatus(ADC1)); ADC_StartCalibration(ADC1); while (ADC_GetCalibrationStatus(ADC1)); /* 不校准的话，仿真里读数会整体偏移 */ } uint16_t Adc1_Read(void) { ADC_SoftwareStartConvCmd(ADC1, ENABLE); while (!ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC)); return ADC_GetConversionValue(ADC1); /* 12 位，0~4095，对应 0~3.3V */ }几个参数值得单独说。RCC_PCLK2_Div6把 ADC 时钟压到 12MHz，是因为 F103 的 ADC 时钟上限是 14MHz，超了读数会明显飘。ADC_SampleTime_55Cycles5是采样时间，阻值大的信号源（比如大阻值电位器）要拉长采样时间，否则采样电容充不满，读数偏低。GPIO_Mode_AIN必须设，配成浮空输入的话引脚上的数字输入缓冲还开着，会干扰模拟读数。
仿真里读数不动或者一直是 4095，先去查激励源：电位器三端要正确连接（两端接 VDD 和 GND，中间抽头接 ADC 引脚），只接抽头两端悬空的话，分压结果没有参考点。
5. 排查清单：仿真跑不起来时的五条血泪记录
仿真环境的问题有个共同点：报错信息极少，多数时候就是“没反应”。所以排查不能靠猜，得有固定顺序。下面五条是我和同事踩得最多的，按出现频率排。
5.1 现象：代码改完，仿真现象一点没变
原因：Proteus 加载的 HEX 是旧的，或者你在仿真运行状态下重新选了文件但没重启仿真。Proteus 在仿真运行中不会自动重载程序文件。
解决：先停掉仿真，再双击 MCU 重新确认 Program File 路径和修改时间；用前面那条find -newer命令确认 hex 确实比源码新；最后重新点运行。还有一种情况是编译输出目录配了两个，Keil 输出到Objects\，Proteus 指向的是Output\，看着文件名一样但内容差了好几版。统一成一个输出目录，问题就没了。
5.2 现象：程序一跑就停住，或者 LED 闪一下就再也不动
原因：多数是内存溢出或者栈溢出。R6 只有 10KB RAM，一个 2KB 的全局数组加一个 1KB 的局部缓冲，再算上栈，很容易踩线。另一种可能是SystemInit里的 PLL 配置在等待 HSE 就绪时死循环——如果属性里的时钟设成了外部晶振但模型没起振，while (RCC_GetFlagStatus(RCC_FLAG_HSERDY) == RESET)就永远出不来。
解决：看.map文件里的Total RW Size，跟 10KB 对比；把大数组改成static或者干脆砍掉；在SystemInit前后各翻转一个 IO，用逻辑分析仪看是不是卡在时钟初始化。实在不行，把 PLL 那段临时换成直接跑 HSI 8MHz，先确认程序主体逻辑没问题，再回头调时钟。
5.3 现象：虚拟终端满屏乱码，或者只收到一个字节就没了
原因：三种可能——波特率不匹配、TX/RX 没交叉接、fputc里的等待标志写错。波特率不匹配最常见，尤其是 MCU 属性里的 Clock Frequency 跟固件里的 HSE_VALUE 不一致时，实际波特率会整体偏移，偏差超过 3% 就开始出乱码。
解决：把虚拟终端的波特率和固件里的baud参数对齐，两个都试 9600 和 115200；确认 PA9 接终端 RXD、PA10 接终端 TXD；在fputc里先发一个固定字符0x55（二进制 01010101，示波器上最容易量脉宽），用示波器量这个字符的位宽，反推实际波特率。位宽 8.68μs 对应 115200，量出来差得远，就是时钟的问题。
5.4 现象：PWM 引脚用示波器测不到方波
原因：按可能性从高到低——GPIO 没配成AF_PP、高级定时器没开TIM_CtrlPWMOutputs、通道号和引脚对不上（TIM1_CH1 是 PA8，不是 PA9）、定时器没TIM_Cmd使能。
解决：按顺序排查这四项，不要跳。通道和引脚的对应关系建议直接查数据手册的复用功能表，别凭记忆。另外，示波器探针要接在 MCU 的输出引脚上，而不是接在 LED 或者负载之后——中间串了电阻，波形幅度会变，容易误判成“没有输出”。
5.5 现象：仿真跑得极慢，定时器时间明显对不上
原因：Proteus 的仿真速度受电路复杂度和主机性能影响，加了示波器、逻辑分析仪、多个虚拟终端之后会明显变慢。更关键的是，仿真时间是“模型时间”，不保证跟真实时间一比一；软件延时循环在仿真里的实际耗时取决于模型解释速度。
解决：把观测工具的数量压到最少，只留当前要看的那个；用定时器中断产生的节拍来驱动逻辑，不要用for空转做延时；在while等待循环里加超时计数，避免仿真卡死在某个标志位上不动。如果只是要验证逻辑，把时钟属性调低一档也能提速，但波特率要跟着重算。
6. 把仿真当验收台：三个自检动作让工程能交付
多数人把 Proteus 当“跑通就行”的工具，我个人更愿意把它当成一块低成本的验收台。同一份固件，在仿真里能稳定跑过三轮自检，再烧到实物板子上，出问题的概率会低很多。这套习惯是从一次返工里来的：当时一个串口协议在实物上死活收不全，最后发现是缓冲区边界没处理，而这个 bug 在仿真里用固定长度的测试帧跑一遍就能暴露。
第一个动作是边界值注入。ADC 输入分别给 0V、1.65V、3.3V 三个点，串口打印原始码值，看是不是落在 0、2048、4095 附近；按键连续快速点击二十次，看状态机有没有卡死；串口一次性灌 256 字节，看接收缓冲会不会溢出。这些在仿真里改激励源就行，成本几乎为零。
第二个动作是时序留痕。在关键路径的首尾各翻转一个空闲 IO，用逻辑分析仪看两段之间的间隔。比如中断进入后处理耗时、主循环一轮的时间、串口发送一帧的阻塞时长。这些数字在仿真里量出来虽然绝对值不准，但相对关系是对的，能发现“某个函数耗时是别人的二十倍”这类结构性问题。
/* 用一个空闲 IO 标记临界区，逻辑分析仪上直接看宽度 */ #define MARK_HIGH() GPIO_SetBits(GPIOB, GPIO_Pin_0) #define MARK_LOW() GPIO_ResetBits(GPIOB, GPIO_Pin_0) void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_Update) != RESET) { MARK_HIGH(); /* 中断处理开始 */ Key_Scan_10ms(); MARK_LOW(); /* 中断处理结束 */ TIM_ClearITPendingBit(TIM2, TIM_IT_Update); } }第三个动作是参数回归表。把每个外设的关键参数（波特率、PWM 频率、ADC 采样时间、定时器周期）列成一张表，每次改动固件后重新量一遍，跟表里对。参数漂了，说明某处配置被顺手改掉又忘了改回来，这在多人协作或者从模板复制工程时特别常见。
提示：这轮自检做完，把 Proteus 工程和固件工程打包成一个版本目录，别在同一个目录里反复覆盖。仿真工程和代码的对应关系一旦错乱，排查成本比重新搭一遍还高。
从那以后我每次交付前都强制走一遍这三个动作，哪怕只是改了一行 GPIO 初始化。仿真不是万能的，它跑不出真实电路的时序余量和电源噪声，但它能把“逻辑对不对”这件事在你焊板子之前就问清楚。希望帮到你。
本文还有配套的精品资源，点击获取
