Proteus 仿真环境，STM32 驱动无源蜂鸣器播放乐曲。无源蜂鸣器必须输入对应频率方波才能发声，有源蜂鸣器只需要高低电平。 一开始打算用定时器中断，在中断里翻转 IO 口，输出不同频率 PWM 方波来播放音乐。 仿真运行：蜂鸣器完全无声，波形抓取也异常；硬件代码逻辑在真实板子上可以跑，但是 Proteus 仿真下定时器中断方案行不通。

对比：有源蜂鸣器给高电平就响；无源蜂鸣器必须周期性翻转 IO 产生方波，频率对应音符。

排查过程

1. 检查定时器时钟配置、预分频、自动重装载值，音符频率计算公式没问题。
2. 中断优先级、NVIC 配置核对无误，代码在实体 STM32 开发板能够正常播放音乐。
3. 进入 Proteus 仿真，开启波形探针观察：定时器中断触发不稳定，中断回调函数执行存在卡顿、丢中断。
4. Proteus 软件仿真属于事件驱动仿真，不是真实硬件。STM32 的定时器中断在仿真模型里有缺陷，高频中断容易丢失、时序失真。
   • 播放音乐需要高频中断（几百～几千 Hz），Proteus 仿真引擎跟不上高频中断，大量中断事件积压，直接失效。
   • 低频中断可能勉强可用，音乐音符需要的高频方波在仿真环境下基本不可用。

解决方案：放弃定时器中断，改用软件延时翻转 IO（仅仿真用！）

⚠️ 重要：软件延时方案只适合 Proteus 仿真演示，实体板子不推荐，会阻塞主程序。 原理：不同音符对应不同延时时间，while 循环里翻转蜂鸣器 IO，软件延时控制方波周期。

// 示例：播放单个音符，freq音符频率，time持续时间
void BEEP_PlayNote(uint16_t freq, uint16_t time_ms)
{
	uint32_t t = time_ms * 1000;
	uint32_t half_period = 1000000UL / freq / 2;
	while(t > 0)
	{
		HAL_GPIO_TogglePin(GPIOA,GPIO_PIN_0);
		delay_us(half_period);
		t -= half_period * 2;
	}
	HAL_GPIO_WritePin(GPIOA,GPIO_PIN_0,GPIO_PIN_RESET);
}

循环翻转 IO，delay_us 控制方波半周期，从而产生对应音符频率。 仿真测试：Proteus 波形正常，蜂鸣器可以正常播放乐曲。

方案取舍总结

✅ 定时器中断方案：

• 实体硬件推荐：非阻塞，不占用 CPU，多任务友好。
• ❌ Proteus 仿真坑：高频定时器中断仿真模型容易丢中断、时序错乱，无源蜂鸣器无声。

✅ 软件延时翻转 IO 方案：

• ✅ Proteus 仿真可用，代码简单，波形稳定，适合课程设计、毕设仿真演示。
• ❌ 缺点：阻塞式，播放音乐期间 CPU 卡死，不能同时跑其他任务；实体产品不建议。

踩坑要点

1. 分清无源 / 有源蜂鸣器：无源需要方波；有源只需要电平。很多人仿真直接搞错器件。
2. Proteus 仿真 ≠ 真实芯片，高频外设、中断是重灾区，定时器、SPI、I2C 高频场景经常出现仿真和实物不一致。
3. 毕设 / 课程设计仿真演示：优先软件延时做演示；实物代码单独写定时器中断版本。
4. 仿真里 delay_us 函数精度也会影响音调，延时不准会出现跑调。

拓展思考

如果不想阻塞主程序，仿真环境下折中办法：降低乐曲采样速度，或者改用定时器 PWM 输出（部分版本 Proteus 对 PWM 模型支持也一般）。