企业官网建设流程全解析

1. 项目概述：为什么这个仿真系统值得你花30分钟认真读完

Proteus、STM32、超声波测距、OLED显示——这四个词组合在一起，不是课程设计作业的简单拼凑，而是一套嵌入式工程师日常调试中真实存在的“最小可行验证闭环”。我带过十几届电子类毕业设计，每年都有学生卡在“硬件还没焊好，程序不敢烧”，结果答辩前一周疯狂改PCB；也有学生用面包板搭出电路，但示波器一接就干扰，测距数据跳变±5cm，最后硬靠软件滤波“蒙混过关”。而这个Proteus仿真实战项目，恰恰切中了这些痛点：它不依赖物理器件的批次差异、不担心焊接虚焊、不惧电源纹波干扰，却能1:1复现STM32的寄存器操作时序、HC-SR04的脉冲响应特性、SSD1306的I²C通信握手过程。更重要的是，它附带的源码不是Keil工程里一堆.h和.c文件的堆砌，而是从GPIO初始化到OLED字符缓存刷新的完整逻辑链——每一行代码都能在Proteus里单步跟踪，每一个变量变化都能对应到虚拟示波器的波形上。如果你正在准备STM32课程设计、想快速验证传感器驱动逻辑、或是刚从51单片机转岗需要建立ARM Cortex-M3的底层直觉，这个仿真系统就是你的“数字孪生实验室”。它解决的不是“能不能跑起来”的问题，而是“为什么这样写才对”的问题。接下来我会带你一层层剥开这个系统的内核，告诉你哪些地方Proteus仿真比实物调试更准，哪些地方又必须警惕仿真与现实的鸿沟。

1.1 核心需求解析：仿真不是炫技，而是精准还原关键瓶颈

很多人把Proteus仿真当成“画个电路图点运行”的玩具，这是最大的认知偏差。在这个超声波+OLED系统中，真正需要被高保真模拟的，只有三个硬性瓶颈环节：第一是超声波模块的回波脉冲宽度测量精度——HC-SR04发出40kHz方波后，回波信号到达时间决定距离，而STM32必须用输入捕获（Input Capture）功能精确捕捉高电平持续时间。Proteus的VSM（Virtual System Modelling）引擎对定时器输入捕获的建模非常扎实，它会严格按你配置的APB1时钟频率、预分频系数、计数器周期计算每个上升沿/下降沿的采样点，误差控制在纳秒级。第二是OLED的I²C通信时序容错性——SSD1306对SCL高/低电平时间、起始条件建立时间有严格要求，实物中用软件模拟I²C（bit-banging）常因GPIO翻转延迟导致通信失败，而Proteus能精确模拟每个SCL脉冲的上升沿斜率和保持时间，让你一眼看出是延时函数写错了还是上拉电阻取值不当。第三是中断嵌套与优先级的实际表现——当超声波回波触发EXTI中断，同时OLED刷新需要调用SysTick定时器更新帧缓冲区，两个中断抢占时的寄存器压栈顺序、NVIC响应延迟，在Proteus里能通过调试器实时观察SP指针变化和PSP/MSP切换过程。这三个环节，恰恰是学生实物调试中最容易陷入“玄学故障”的地方。所以这个项目的核心价值，从来不是“仿真看起来很酷”，而是把嵌入式开发中最难定位的时序类问题，变成可量化、可回溯、可反复试错的确定性过程。

1.2 为什么选STM32F103C8T6而非其他型号

标题里明确写了STM32，但没指定具体型号。实际源码和仿真文件默认采用STM32F103C8T6（俗称“C8T6”），这个选择背后有三重硬性约束。首先是资源匹配度：超声波测距需要至少1个高级定时器（TIM1或TIM2）用于输入捕获，OLED显示需要I²C接口（I2C1），而C8T6恰好有TIM2（APB1总线）、I2C1（APB1总线）、以及足够容纳距离计算+OLED字模缓存的20KB SRAM。对比F103C6T6（仅10KB SRAM），后者在加载128×64点阵的汉字字库时会直接溢出；而F103ZET6（512KB Flash）则属于“杀鸡用牛刀”，Proteus对大容量Flash的仿真加载速度会明显变慢。其次是Proteus元件库成熟度：截至Proteus 8.15版本，ST官方提供的STM32F103C8T6 VSM模型已通过Keil MDK-ARM 5.37兼容性测试，其NVIC中断向量表映射、SysTick校准值、甚至ADC参考电压温漂参数都已内置。我曾试过用F407VE模型替换，结果发现Proteus对F4系列的FPU浮点运算单元建模不完整，距离计算中用到的sqrtf()函数在仿真中返回NaN。最后是成本与普及性：C8T6批量采购单价低于5元，淘宝最便宜的开发板不到15元，学生买来焊电路板毫无压力。更重要的是，所有主流STM32教程（江科大、正点原子）都以C8T6为基准，当你在仿真里调试通了，换到实物开发板上只需修改两处：一是晶振频率（仿真用内部8MHz RC，实物用外部8MHz晶振），二是JTAG/SWD下载引脚定义（仿真中PA13/PA14直接连虚拟调试器，实物需确认是否被其他外设复用）。这种“仿真即生产”的平滑迁移能力，才是选型的根本逻辑。

2. 系统架构拆解：三层结构如何实现零耦合协同

这个系统表面看只是“测距+显示”，但实际代码架构采用经典的三层分离设计：硬件抽象层（HAL）、业务逻辑层（Application）、人机交互层（UI）。这种结构不是为了炫技，而是为了解决Proteus仿真中一个致命陷阱——外设驱动与业务逻辑强耦合导致的调试雪崩。举个真实案例：某学生把超声波测距的Get_Distance()函数直接写在main循环里，每次调用都重新初始化TIM2和GPIO，结果Proteus仿真运行10秒后定时器计数器突然归零，查了3小时才发现是重复初始化导致NVIC中断使能位被意外清除。而本项目的三层架构，让每个模块的职责边界清晰到可以独立验证。

2.1 硬件抽象层（HAL）：用寄存器级操作封住仿真“假动作”

HAL层不使用ST官方HAL库（因为Proteus对HAL库中大量__weak函数的链接仿真支持不稳定），而是基于CMSIS标准手写寄存器操作。以超声波模块为例，核心是TIM2的输入捕获配置：

// hal_ultrasonic.c void Ultrasonic_Init(void) { // 1. 使能TIM2和GPIOA时钟（APB1和AHB） RCC->APB1ENR |= RCC_APB1ENR_TIM2EN; RCC->AHBENR |= RCC_AHBENR_GPIOAEN; // 2. 配置PA0为浮空输入（超声波ECHO引脚） GPIOA->CRL &= ~(0xF << 0); // 清除PA0模式位 GPIOA->CRL |= (0x4 << 0); // 输入浮空 // 3. TIM2配置：CK_CNT = 72MHz / 72 = 1MHz，即1us计数精度 TIM2->PSC = 71; // 预分频72-1 TIM2->ARR = 0xFFFF; // 自动重装载值最大 TIM2->CCMR1 |= TIM_CCMR1_CC1S_0; // CC1通道映射到TI1（PA0） TIM2->CCER |= TIM_CCER_CC1E; // 允许CC1输入捕获 TIM2->DIER |= TIM_DIER_CC1IE; // 使能CC1中断 TIM2->CR1 |= TIM_CR1_CEN; // 启动计数器 }

这段代码的关键在于所有寄存器操作都显式写出地址和位域，而不是调用HAL_TIM_IC_Start_IT()这类封装函数。原因在于：Proteus VSM模型对底层寄存器的响应是即时的，但对HAL库中复杂的中间状态机（如HAL_TIM_StateTypeDef）建模存在延迟。我实测过，当用HAL库初始化TIM2输入捕获时，Proteus调试器显示TIM2->SR寄存器的CC1IF标志位在中断触发后200ms才置位，而手写寄存器操作下该标志位在捕获到下降沿后1个系统时钟周期（13.9ns）内就生效。这种毫秒级的仿真偏差，在实物中可能被忽略，但在调试中断优先级时会导致灾难性后果——比如OLED刷新的SysTick中断被错误地认为抢占了超声波中断，实际却是仿真器自身状态同步延迟造成的假象。因此，HAL层的“笨办法”反而成就了仿真结果的可信度。

2.2 业务逻辑层（Application）：距离计算中的物理模型校准

业务层的核心函数App_GetDistance()看似简单，实则暗藏两个必须校准的物理参数：

// app_main.c uint16_t App_GetDistance(void) { static uint32_t last_time = 0; uint32_t current_time = ultrasonic_capture_value; // 从HAL层获取捕获值 if (current_time > last_time) { uint32_t pulse_width_us = current_time - last_time; // 单位：微秒 // 关键校准参数1：声速修正系数（25℃时346m/s → 34600cm/s） // 关键校准参数2：超声波模块固有延时（HC-SR04典型值为0.5ms） float distance_cm = (pulse_width_us - 500.0f) * 0.0343f; last_time = current_time; return (uint16_t)(distance_cm > 0 ? distance_cm : 0); } return 0; }

这里有两个极易被忽略的细节。第一是声速温度补偿：公式中0.0343f对应25℃声速，但Proteus仿真默认环境温度为25℃，而实物中夏季实验室温度常达35℃，声速升至352m/s。如果仿真时不引入温度变量，就会导致“仿真测距准，实物误差大”的经典矛盾。解决方案是在Proteus中双击STM32元件，进入“Properties”面板，将Temperature参数从默认25改为35，此时仿真器会自动调整内部声速模型。第二是模块固有延时扣除：HC-SR04从收到TRIG脉冲到发出超声波有约0.5ms延迟，这个值在不同批次模块间有±0.1ms波动。我在Proteus中用虚拟示波器测量TRIG引脚上升沿到ECHO引脚上升沿的时间差，实测为502μs，因此代码中减去500μs而非理论值。这种“用仿真器反向标定硬件参数”的做法，正是专业工程师的惯用技巧——与其死记数据手册，不如让仿真器告诉你真实值。

2.3 人机交互层（UI）：OLED显示的帧缓冲区优化策略

OLED层采用双缓冲机制，这是避免显示撕裂的关键。SSD1306的128×64点阵共需1024字节显存，若每次刷新都全屏重写，I²C通信耗时约12ms（按100kHz标准模式），而超声波测距周期为60ms，会导致每帧显示滞后近20%。本项目采用增量更新策略：

// ui_oled.c static uint8_t oled_buffer[1024]; // 帧缓冲区 static uint8_t oled_dirty[16]; // 行脏标记（128/8=16行） void UI_UpdateDistance(uint16_t dist) { char str[8]; sprintf(str, "%d", dist); // 仅更新数字区域（第2行，列0-3） OLED_DrawString(1, 0, str, FONT_1608); // FONT_1608为16×8点阵 oled_dirty[1] = 1; // 标记第1行（0索引）为脏 } void UI_Refresh(void) { for (uint8_t i = 0; i < 16; i++) { if (oled_dirty[i]) { OLED_WriteBuffer(&oled_buffer[i*64], i*64, 64); // 写入64字节（1行） oled_dirty[i] = 0; } } }

这个设计在Proteus中带来两个优势：一是降低I²C总线负载，避免因频繁通信导致的SCL时钟拉伸（Clock Stretching）仿真失真；二是暴露硬件真实瓶颈。当我把UI_UpdateDistance()改成全屏刷新时，Proteus虚拟逻辑分析仪显示SCL线在第7个字节传输时出现长达80μs的拉伸，这正是SSD1306内部RAM写入时的等待时间——而实物中用示波器测量，该拉伸时间为78μs，误差仅2.5%。这种毫米级的时序还原能力，让Proteus不再是“差不多就行”的玩具，而成为可信赖的硬件行为预测工具。

3. 核心模块实操详解：从原理到Proteus配置的完整链路

要让这个仿真系统真正跑起来，光有源码远远不够。Proteus中的元件选型、参数配置、调试设置，每一步都直接影响仿真结果的真实性。下面我以超声波模块和OLED模块为例，手把手拆解那些文档里绝不会写的“魔鬼细节”。

3.1 HC-SR04超声波模块：Proteus中不可见的“内部时钟源”

HC-SR04在Proteus元件库中名为HC-SR04，但它的仿真行为与实物存在一个关键差异：内部40kHz振荡器的相位噪声建模缺失。实物中，由于压电陶瓷片的机械谐振特性，HC-SR04发出的超声波并非理想方波，而是带有±5%频率抖动的准正弦波，这会导致回波信号过零检测点漂移。而Proteus默认模型输出的是完美方波，使得测距结果异常稳定——这恰恰掩盖了实物中最常见的“距离跳变”问题。

解决方案是手动注入相位噪声。步骤如下：

1. 双击HC-SR04元件，打开属性面板；
2. 找到Oscillator Frequency参数，默认为40000；
3. 将其改为表达式：40000 + 2000 * sin(2 * pi * time)；
4. 这个表达式让振荡频率在38kHz~42kHz间正弦波动，模拟压电片谐振特性。

提示：此操作需Proteus 8.13及以上版本支持动态表达式。若使用旧版本，可在TRIG引脚前串联一个PULSE信号源，将其周期设为25μs（40kHz），占空比设为50%，并勾选Random Jitter选项，抖动幅度设为10%。实测表明，加入抖动后，Proteus中测距结果的标准差从0.1cm提升至0.8cm，与实物万用表测量的0.7cm标准差高度吻合。

另一个易错点是ECHO引脚的电气特性配置。HC-SR04的ECHO是开漏输出，需外接上拉电阻。Proteus中若直接将ECHO连到STM32的PA0，会因缺少上拉导致电平无法拉高。正确做法是：

• 在ECHO与PA0之间放置一个RESISTOR元件；
• 双击电阻，将Resistance设为4.7kΩ；
• 在Proteus元件库中搜索PULLUP，添加一个上拉电阻到ECHO引脚（非必需，但更符合实物）。

我曾见过学生因忘记上拉电阻，导致Proteus中ECHO始终为低电平，调试半天以为是STM32代码问题，最后发现是电路图根本没画对。这种基础错误，在仿真阶段就能100%暴露，正是Proteus的最大价值。

3.2 SSD1306 OLED模块：I²C地址冲突的隐形杀手

OLED模块在Proteus中通常选用SSD1306_I2C模型，其默认I²C地址为0x78（写）/0x79（读）。但实物中，很多廉价OLED模块的地址跳线默认接地，实际地址为0x7A/0x7B。如果仿真时没修改地址，编译通过但屏幕不亮，你会陷入“代码没错，硬件坏了”的死循环。

修改步骤极其简单但常被忽略：

1. 双击OLED元件，打开属性面板；
2. 找到I2C Address字段，默认值为0x78；
3. 改为0x7A（注意是十六进制，不要加引号）；
4. 同时检查STM32代码中I²C地址定义：#define OLED_I2C_ADDR 0x7A。

注意：Proteus中I²C地址必须是8位格式（含读写位），而STM32 HAL库常用7位地址。例如，若Proteus设为0x7A，代码中应写0x3D（0x7A>>1），但本项目手写寄存器操作，直接使用8位地址，避免转换错误。

更隐蔽的问题是I²C总线电容效应。Proteus默认I²C总线电容为0pF，而实物中PCB走线+OLED模块引脚会引入约20pF寄生电容，导致SCL上升沿变缓。这在高速模式（400kHz）下会引发通信失败。解决方案是在SCL和SDA线上各并联一个CAPACITOR元件，容量设为20pF。实测表明，加入电容后，Proteus虚拟示波器显示SCL上升时间从10ns增至120ns，与实物示波器测量的115ns几乎一致。这种对寄生参数的主动建模，让仿真结果真正具备指导实物设计的能力。

3.3 STM32F103C8T6的Proteus调试配置：避开Keil与Proteus的握手陷阱

Proteus与Keil的联合调试是最大痛点。常见错误是：Keil编译生成.hex文件，Proteus加载后点击“Debug→Start Debugging”，结果提示“Cannot connect to target”。这通常由三个原因导致：

原因一：调试接口模式不匹配
Proteus中STM32元件的Debug Interface默认为SWD，但Keil中若配置为JTAG，则无法握手。解决方法：

• Keil中：Project→Options→Debug→Settings→Port选择SWD；
• Proteus中：双击STM32→Properties→Debug Interface设为SWD；
• 确认Proteus中PA13(SWDIO)和PA14(SWCLK)未被其他外设复用（如USART1的TX/RX）。

原因二：时钟配置冲突
Proteus仿真时，STM32的系统时钟由RCC寄存器配置，但若Keil工程中使用了ST-Link Utility烧录，其时钟配置可能覆盖Proteus设置。解决方案是强制Proteus接管时钟：

• Proteus中双击STM32→Properties→System Clock设为72MHz；
• 在代码中删除所有RCC->CFGR相关配置，改用Proteus预设时钟；
• 或在SystemInit()函数开头添加RCC->CR = 0x00000001;（仅使能HSI），让Proteus完全控制时钟树。

原因三：HEX文件路径含中文或空格
这是最蠢也最常见的错误。Proteus对含中文路径的.hex文件加载失败率100%。务必确保：

• Keil输出目录为纯英文路径，如D:\STM32_Project\Output\；
• Proteus中加载.hex时，右键STM32→Edit Properties→Program File路径不含任何中文或空格；
• 若路径错误，Proteus日志窗口（View→Debug Log）会显示Failed to load program file，但不会弹窗提示。

我统计过，83%的“Proteus无法调试”问题源于这三个原因。把它们写清楚，比教你一百行代码都管用。

4. 源码与仿真文件深度解析：从Keil工程到Proteus运行的全流程

标题中强调“附源码与仿真文件”，但很多学生拿到后直接双击.proteus文件运行，发现屏幕空白，然后开始怀疑人生。其实源码和仿真文件是共生关系，必须理解它们的耦合逻辑。下面我以实际文件结构为例，逐层拆解。

4.1 Keil工程结构：为什么必须禁用MicroLib

本项目Keil工程（MDK-ARM 5.37）包含以下核心文件：

Project/ ├── Core/ │ ├── startup_stm32f10x_md.s // 启动文件（MD系列，非HD） │ └── system_stm32f10x.c // 系统时钟初始化 ├── Drivers/ │ ├── hal_gpio.c // GPIO寄存器操作 │ ├── hal_tim.c // TIM2输入捕获 │ ├── hal_i2c.c // 软件模拟I²C（非硬件I2C） │ └── driver_ssd1306.c // OLED驱动 ├── Application/ │ ├── app_main.c // 主循环与距离计算 │ └── app_oled.c // OLED显示逻辑 └── User/ └── main.c // main函数入口

关键点在于hal_i2c.c采用软件模拟I²C而非硬件I2C外设。原因在于：Proteus对STM32硬件I2C外设的建模存在严重缺陷——当I2C1_CR1寄存器的PE位（外设使能）置1后，Proteus模型会立即锁死SCL/SDA引脚为高阻态，导致无法响应OLED的ACK信号。而软件模拟I²C通过GPIO翻转实现，Proteus对GPIO的建模极为精准，每个GPIOA->ODR ^= (1<<0)操作都能在虚拟示波器上看到精确的电平跳变。

实操心得：在hal_i2c.c中，SCL和SDA的翻转必须使用BSRR和BRR寄存器，而非ODR直接赋值。例如：

// 正确：原子操作，无读-修改-写风险 GPIOA->BSRR = (1 << 0); // SCL = 1 GPIOA->BRR = (1 << 0); // SCL = 0 // 错误：Proteus仿真中可能因时序竞争导致电平错误 GPIOA->ODR |= (1 << 0); GPIOA->ODR &= ~(1 << 0);

这是因为Proteus VSM引擎对BSRR/BRR的处理是单周期指令，而ODR赋值涉及读取-修改-写入三步，在高频率翻转时会产生不可预测的中间态。

另一个重要配置是禁用MicroLib。Keil默认启用MicroLib（小型C库），其printf函数会占用大量Flash空间且与Proteus的__sys_write系统调用不兼容。必须在Keil中：Project→Options→Target→Use MicroLIB取消勾选。否则编译生成的.hex文件在Proteus中加载后，串口打印功能会失效，且Flash利用率飙升至95%，留给用户代码的空间不足。

4.2 Proteus仿真文件配置：六个必须检查的参数

.pdsprj文件是Proteus项目的灵魂，其中六个参数直接决定仿真成败：

特别提醒Simulation Speed参数：设为10x后，Proteus会自动缩放所有时间相关参数。例如，HC-SR04的60ms测距周期在仿真中变为6ms，但TIM2的计数器仍按1us精度运行，因此捕获值不变。这让你能在1分钟内完成10次测距测试，极大提升调试效率。但要注意，加速仿真时虚拟示波器的时间轴会同步压缩，需手动调整时基（Timebase）才能看清波形细节。

4.3 源码关键算法解析：三角函数优化与抗干扰滤波

距离计算中sqrtf()的使用是个陷阱。STM32F103C8T6没有硬件FPU，sqrtf()函数由软件库实现，执行一次需约1200个时钟周期（16.7μs）。在60ms测距周期中占比虽小，但若后续扩展为多点测距，CPU占用率会飙升。

本项目采用查表法+线性插值替代sqrtf()：

// math_sqrt.c const uint16_t sqrt_table[256] = { 0,1,1,2,2,2,2,3,3,3,3,3,3,3,3,4, // ... 完整256项 }; uint16_t Fast_Sqrt(uint32_t x) { if (x == 0) return 0; uint8_t index = x >> 8; // 取高8位作索引 uint16_t low = sqrt_table[index]; uint16_t high = sqrt_table[index+1]; uint8_t offset = x & 0xFF; // 低8位作插值权重 return low + ((high - low) * offset) / 256; }

实测表明，该函数执行时间降至1.2μs，提速13倍，且误差小于0.3%。Proteus中可通过调试器对比Fast_Sqrt()与sqrtf()的返回值，验证精度。

抗干扰滤波采用中值+均值混合滤波，而非简单的移动平均：

#define FILTER_DEPTH 5 uint16_t distance_filter[FILTER_DEPTH]; uint16_t Get_Filtered_Distance(void) { // 1. 中值滤波：剔除突变毛刺 uint16_t temp[FILTER_DEPTH]; memcpy(temp, distance_filter, sizeof(temp)); // 冒泡排序取中值 for (uint8_t i = 0; i < FILTER_DEPTH-1; i++) { for (uint8_t j = 0; j < FILTER_DEPTH-1-i; j++) { if (temp[j] > temp[j+1]) { uint16_t t = temp[j]; temp[j] = temp[j+1]; temp[j+1] = t; } } } uint16_t median = temp[FILTER_DEPTH/2]; // 2. 均值滤波：平滑小幅波动 uint32_t sum = 0; for (uint8_t i = 0; i < FILTER_DEPTH; i++) { sum += distance_filter[i]; } return (median + sum / FILTER_DEPTH) / 2; }

这种设计在Proteus中效果显著：当人为在ECHO线上注入500ns尖峰干扰时，单纯均值滤波会使距离跳变±3cm，而混合滤波将跳变抑制在±0.5cm内。这证明了算法设计必须结合仿真环境的干扰特性。

5. 常见问题与排查技巧实录：那些只在Proteus里才会发生的“灵异事件”

Proteus仿真中会出现一些在实物中绝不可能发生、但又极其消耗调试时间的“灵异问题”。以下是我在十年教学中收集的TOP5问题及独家解决方案，全部来自真实踩坑记录。

5.1 问题1：OLED显示乱码，但I²C通信波形完全正常

现象：Proteus虚拟示波器显示SCL/SDA波形完美符合I²C协议，START/STOP/ACK序列齐全，但OLED屏幕显示为随机噪点。

根本原因：SSD1306的DC（Data/Command）引脚电平被Proteus错误解释。实物中DC为高电平时写入显示数据，低电平时写入命令。但Proteus默认模型将DC引脚视为普通GPIO，未关联到内部命令解析器。

解决方案：

1. 双击OLED元件→Properties→找到DC Pin字段；
2. 将其值从None改为PA2（假设你用PA2控制DC）；
3. 确保代码中DC引脚初始化为推挽输出：

GPIOA->CRL &= ~(0xF << 8); // PA2模式位清零 GPIOA->CRL |= (0x1 << 8); // PA2推挽输出

实操心得：这个配置在Proteus 8.10之前是隐藏功能，8.10版本后才在UI中暴露。若使用旧版本，需在.pdsprj文件中手动编辑，找到SSD1306_I2C节点，添加DCPin="PA2"属性。

5.2 问题2：超声波测距值稳定在0或65535，且TIM2计数器不递增

现象：Proteus调试器中TIM2->CNT寄存器始终为0，TIM2->CCR1无变化，距离显示为0或溢出值65535。

排查链路：

1. 首先检查TIM2->CR1寄存器的CEN位是否为1（启动位）；
2. 若为0，检查RCC->APB1ENR中TIM2EN位是否置1；
3. 若TIM2EN为0，检查RCC->CR中HSION（内部高速时钟）是否使能——Proteus中若未使能HSI，APB1时钟为0，TIM2无法工作；
4. 最隐蔽的原因：TIM2->CCMR1寄存器的CC1S位配置错误。HC-SR04的ECHO信号必须连接到TI1（PA0），若误配为TI2（PA1），则捕获永远失败。

终极验证法：在Proteus中打开Virtual Instruments→Logic Analyzer，将通道1接PA0，通道2接PA1，触发方式设为PA0上升沿。若PA0无信号而PA1有信号，说明硬件连接错误；若两者皆无，则检查HC-SR04的TRIG引脚是否被正确驱动。

5.3 问题3：Proteus运行几秒后崩溃，报错“Access Violation at address XXXX”

现象：仿真运行2~5秒后Proteus无响应，Windows弹出“Proteus has stopped working”。

唯一原因：STM32代码中存在未处理的HardFault中断，且Proteus对HardFault的仿真处理存在内存越界。常见诱因是数组越界访问OLED缓冲区：

// 危险代码：未检查索引范围 oled_buffer[y * 128 + x] = pixel; // y最大为63，x最大为127 // 若y=64，则访问oled_buffer[8192+]，超出1024字节数组

解决方案：

1. 在HardFault_Handler中添加死循环并点亮LED（PA4）：

void HardFault_Handler(void) { GPIOA->BSRR = (1 << 4); // PA4 = 1 while(1); }

2. Proteus中将PA4连接到LED元件，仿真崩溃时LED亮起即确认HardFault；
3. 使用Proteus调试器的Memory Browser，查看0x20000000起始的SRAM，定位越界写入位置。

注意：Proteus 8.15修复了此崩溃问题，若使用旧版本，务必