企业官网建设流程全解析

我用STM32给蜂鸣器写旋律播放器，是很多初学者接触定时器PWM的第一个小项目。这个项目看起来简单，就是把频率不同的方波喂给蜂鸣器，但真正动手做的时候，会遇到选型、驱动电路、定时器计算、播放节奏控制等一堆问题。这篇文章把我从零到跑通《小星星》的完整过程整理出来，包括硬件连接、参数计算、代码实现和一些常见的坑，想用STM32玩蜂鸣器或者想理解PWM输出的朋友可以直接照着做，不需要额外买模块，手头有开发板和几根杜邦线就能跑起来。

1. 方案设计：用无源蜂鸣器做旋律播放器的核心思路

1.1 蜂鸣器分两类，选型错了直接没法用

蜂鸣器看着长得都差不多，黑色的圆柱体，两个引脚，但内部结构完全不同，分为有源蜂鸣器（active buzzer）和无源蜂鸣器（passive buzzer）。这里的“源”指的是震荡源，不是电源。有源蜂鸣器内部自带振荡电路，只要给它通上直流电，它自己就会发出固定频率的声音，通常用来做报警提示，听到的就是单调的“嘀嘀嘀”。无源蜂鸣器内部没有振荡电路，需要外部给它一个方波信号，靠方波频率变化产生不同音调的声音。

想播放旋律，必须用无源蜂鸣器。如果你手里是有源蜂鸣器，通电后只会响一个音，怎么改代码都没用。区分方法很简单：看引脚那面有没有电路板露出来，有源蜂鸣器通常有黑胶封装的振荡芯片在里面；还可以用万用表测电阻，无源蜂鸣器直流电阻通常在8Ω到16Ω左右，有源蜂鸣器电阻值高很多。最靠谱的办法还是拿个1.5V电池碰一下两个引脚，无源蜂鸣器只会“咔”一声，有源蜂鸣器会持续响。这个小测试不伤蜂鸣器，可以放心试。

另外要注意，市面上还有电磁式和压电式两种无源蜂鸣器，电磁式的音色更柔和，适合做音乐播放，但驱动电流稍大；压电式的音色偏尖锐，驱动电流小，直接接GPIO有时候能响但声音很小。我的经验是，新手买常见的3.3V或5V电磁式无源蜂鸣器最省事，价格两三块钱，效果也够用。

1.2 从“响”到“唱”，本质是控制方波频率

人耳听到的音高，取决于声波的频率。弹钢琴时按下不同的键，琴弦振动的频率不同，发出的音调就不同。蜂鸣器播放旋律，原理上就是让蜂鸣器振动膜片的频率跟随音符变化。标准音乐里，中音A（也就是la）的频率是440Hz，高八度的A是880Hz，频率翻倍，音高就高一个八度。

STM32要产生一个频率可变的方波，最直接的方式是使用定时器的PWM输出模式。PWM就是让引脚按照固定的周期输出高电平和低电平，高电平时间占整个周期的比例叫占空比。对蜂鸣器来说，方波的频率决定了音高，占空比影响响度和音色。通常把占空比设为50%，也就是高低电平各占一半，方波对称，音色最干净。

所以整个项目的核心逻辑就变得非常清晰：给每个音符查出一张频率表，让定时器输出对应频率的PWM方波，持续一段时间表示节拍，然后换下一个音符。音乐播放器本质上就是一个“按乐谱播放频率序列”的程序。

1.3 为什么优先用定时器PWM而不是GPIO软件翻转

有些人会想，既然只是输出方波，我直接在GPIO上翻转高低电平不就行了？写一个延时函数，输出一段高电平再输出一段低电平，循环起来也能产生方波。这种思路在低频率下确实能用，但有两个明显的问题。

首先是精度问题。软件翻转方波依赖延时函数，而延时函数本身受中断影响很大，比如系统滴答中断、串口中断一来，延时就被打断，方波的周期就会抖动，播放出来的音调忽高忽低，非常难听。其次是CPU占用问题。在软件翻转的过程中，CPU全程忙着翻转GPIO和跑延时，什么事情都干不了。如果你还想着同时点亮OLED、处理按键、跑串口，程序结构就会变得非常糟糕。

定时器PWM完全不同，它由硬件自动产生方波，CPU只需要设置好重装值（ARR）和比较值（CCR），引脚就会按照设定的频率自行翻转，不占CPU时间。改变频率只需重新计算并写入重装值，这一个操作就能切换音高，干净利落。这也是嵌入式里“能用硬件外设就不要用软件模拟”的一个典型例子。

2. 硬件准备与驱动电路：别让蜂鸣器把MCU拉垮

2.1 元器件清单与接线方案

我在这个项目里用的是最常见的STM32F103C8T6蓝色开发板，配合一块3.3V电磁式无源蜂鸣器。其他型号的STM32也没问题，只要确认定时器资源够用就行，比如STM32F407或者G071系列操作方式都一样，区别只在于CubeMX配置时的时钟树不同。

手头需要的元器件非常少，核心就四样：

• STM32开发板一块，我用的STM32F103C8T6
• 无源蜂鸣器一个，注意不是有源蜂鸣器
• 三极管一个，推荐S8050或SS8550，NPN型
• 电阻若干，1kΩ和10kΩ各一个

可选元件里，电容可以加一个100nF的陶瓷电容并在蜂鸣器两端，用于滤掉高频干扰，让声音更纯净。10kΩ电阻是基极下拉电阻，防止MCU上电瞬间GPIO悬空导致蜂鸣器误响，实际使用中如果对启动瞬间的“咔哒”声不敏感，不接也能工作。

接线原理分两部分。第一部分是MCU控制三极管基极，GPIO输出PWM信号到三极管基极；第二部分是三极管驱动蜂鸣器，蜂鸣器正极接电源，负极接三极管集电极，三极管发射极接地。

2.2 三极管驱动电路与参数计算

为什么不直接把蜂鸣器接在GPIO和GND之间？这要从电流能力说起。STM32的GPIO在推挽输出模式下，最大灌电流和拉电流大约是20mA，但这个电流对驱动蜂鸣器来说很勉强。电磁式蜂鸣器启动瞬间需要较大电流，如果直接由GPIO供电，电压会被拉低，PWM波形变形，声音发闷，严重的还会影响MCU稳定性。加上蜂鸣器是感性负载，关断瞬间会产生反向电动势，这个尖峰电压对GPIO引脚有损伤风险。

用一个NPN三极管做开关放大就能解决这两个问题。三极管的基极由GPIO控制，集电极驱动蜂鸣器，电源电流直接从VCC经过蜂鸣器再经过三极管到GND，不经过MCU引脚。基极串联一个1kΩ限流电阻，限制GPIO输出的基极电流，防止过流。

基极电流的计算很简单。GPIO输出高电平约3.3V，三极管基极-发射极导通压降约0.7V，串联1kΩ电阻后基极电流大概是：

I_B = (3.3V - 0.7V) / 1000Ω = 2.6mA

S8050的放大倍数hFE通常在100到200之间，饱和导通时要求集电极电流除以基极电流小于放大倍数。蜂鸣器工作电流一般在30mA到80mA，这里以50mA估算，I_C / I_B = 50 / 2.6 ≈ 19，远小于100，三极管能可靠进入饱和状态，管压降大约0.2V到0.3V，蜂鸣器能获得接近电源电压的供电，声音最大化。

注意：基极电阻不能选太大。有些教程建议用10kΩ，那样基极电流只有0.26mA，放大倍数低的三极管可能无法完全饱和，蜂鸣器工作在放大区，内阻变大，声音小且发热明显。我做实验对比过，1kΩ比10kΩ的声音明显更响更清脆。10kΩ电阻在这里当作下拉电阻用，不是限流电阻。

2.3 有个细节：PWM输出引脚要选对

STM32的定时器PWM输出不是任意引脚都可以，每个定时器通道有固定的引脚映射关系。比如我用的TIM2通道1，在F103上默认映射到PA0；如果再做一个TIM2通道2，映射到PA1。这个要看芯片数据手册或者参考CubeMX里的引脚配置图。

选引脚时有两点容易踩坑。第一，确认引脚没有被板载外设占用，比如很多开发板上的PA0同时接到了按键、LED或者板载串口，接了蜂鸣器后可能会互相干扰。第二，拿到开发板后先用CubeMX图形化界面配置一遍引脚，它会自动帮我们检查冲突，比自己死磕数据手册省心很多。

我最终用的连接方案是：

• PA0（TIM2_CH1）接三极管基极的1kΩ电阻
• 蜂鸣器正极接3.3V电源
• 蜂鸣器负极接三极管集电极
• 三极管发射极接GND
• 基极与GND之间接10kΩ下拉电阻

如果使用5V供电的蜂鸣器，蜂鸣器正极接5V即可，但要注意三极管的耐压和基极电阻，5V对3.3V GPIO控制没有影响，因为三极管只受基极电流控制，与集电极电源电压无关。

3. 音符频率计算与STM32定时器配置

3.1 十二平均律与音符频率表

音乐里的音高按照十二平均律划分，每个八度包含12个半音。国际标准音A4（钢琴中央组第49个键）的频率是440Hz，其他音符的频率可以用公式计算：

f = 440 × 2^((n-69)/12)

其中n是MIDI音符编号。C4编号60，D4编号62，E4编号64，F4编号65，G4编号67，A4编号69，B4编号71，C5编号72。如果不想每次自己计算，也可以直接记住一段近似频率表，播放简单的儿歌完全够用：

人耳对音高差异的感知不是线性的，低频段能分辨出很小的频率差，高频段对误差相对不敏感。在播放儿歌这种场景下，频率误差不超过1%听起来就没有明显走调，所以直接用整数近似频率完全没问题。

3.2 定时器分频与重装值计算，这里是最核心的数学

STM32的PWM频率由定时器时钟、预分频器（PSC）和自动重装值（ARR）共同决定。公式是：

PWM频率 = 定时器时钟频率 / ((PSC + 1) × (ARR + 1))

我的STM32F103C8T6工作在72MHz主频，TIM2属于APB1总线上的定时器。当APB1预分频为1时，定时器时钟就等于72MHz；当APB1预分频为2时，定时器时钟反而会通过倍频器变为72MHz。总之一句话：F103的定时器时钟就是72MHz，不用额外计算。

为了让计算方便，我通常把PSC设置成71，这样定时器计数频率就是72MHz / 72 = 1MHz，也就是每计一个数用时1微秒。重装值ARR和PWM频率的关系变成：

PWM频率 = 1MHz / (ARR + 1)

反过来，给定一个音符频率f，需要设置的ARR是：

ARR = 1,000,000 / f - 1

以发射A4（440Hz）为例：

ARR = 1,000,000 / 440 - 1 = 2272.7 - 1 ≈ 2272

代入验证一下实际输出频率：

PWM频率 = 1,000,000 / (2272 + 1) ≈ 440.1Hz

误差约0.1Hz，完全可以忽略。再看C5（523Hz）：

ARR = 1,000,000 / 523 - 1 ≈ 1911

实际输出频率 = 1,000,000 / 1912 ≈ 522.9Hz，同样非常准确。

注意：这里有个新手特别容易犯的错误。在CubeMX里配置定时器时，PSC和ARR默认都填0，如果你直接把ARR写成2272，但没有把PSC改为71，那么实际PWM频率就是72MHz / 2273 ≈ 31.6kHz，这已经超出人耳听力范围，蜂鸣器要么不响，要么发出极其尖锐的嘶嘶声。配置PSC和ARR时，两个值都必须通过计算确认。

3.3 CubeMX配置与HAL库定时器初始化

我用CubeMX生成工程，步骤如下：

先在Pinout视图里把PA0配置为TIM2_CH1，然后打开TIM2界面，选择Clock Source为Internal Clock，配置PSC为71，ARR随便填一个初始值比如999，最后在PWM Generation Channel CH1里开启PWM输出。Initial Pulse设成0，这样程序启动时不会立刻有输出。

时钟配置很关键，确认HCLK为72MHz，APB1 Prescaler为1或者2都没关系，关键是最后在Clock Configuration界面里确认APB1 Timer Clocks是72MHz。如果是其他系列的芯片，比如G0系列主频64MHz，计算时就要替换成64MHz，其他逻辑完全一样。

生成的初始化代码里，MX_TIM2_Init()会看到类似这样的参数：

static void MX_TIM2_Init(void) { TIM_ClockConfigTypeDef sClockSourceConfig = {0}; TIM_MasterConfigTypeDef sMasterConfig = {0}; TIM_OC_InitTypeDef sConfigOC = {0}; htim2.Instance = TIM2; htim2.Init.Prescaler = 71; htim2.Init.CounterMode = TIM_COUNTERMODE_UP; htim2.Init.Period = 999; htim2.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1; htim2.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_ENABLE; if (HAL_TIM_PWM_Init(&htim2) != HAL_OK) { Error_Handler(); } // ... 其余代码省略 }

然后在main函数里启动PWM输出：

HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1);

初始化代码本身不难，难的是理解每个参数的含义。Prescaler是预分频器，CounterMode是向上计数模式，Period就是ARR，AutoReloadPreload设为ENABLE表示ARR修改后会在下一次计数溢出时生效，这个设置很重要，它可以避免在播放过程中修改ARR导致输出一个不完整的异常波形。

4. 旋律播放的实现：从驱动封装到歌曲数据

4.1 驱动层封装：SetTone和StopTone

定时器初始化好后，接下来要封装两个底层函数，一个用来设置某个音符对应的频率，一个用来停止发声。把底层操作封装成函数是一个好习惯，后面换一个定时器或者换一个平台，只需要改这两个函数，上层的音乐播放逻辑完全不用动。

设置频率的函数只需要改两个寄存器值，一个是ARR、一个是CCR：

void SetTone(uint16_t frequency) { if (frequency == 0) { StopTone(); return; } uint32_t arr = 1000000/ frequency - 1; uint32_t ccr = arr / 2; // 占空比50% __HAL_TIM_SET_AUTORELOAD(&htim2, arr); __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, ccr); } void StopTone(void) { __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, 0); }

这里有个非常重要的细节：修改ARR之后，CCR也就是比较值必须同步更新。如果只改ARR不改CCR，占空比会变得随机，比如ARR从2272改成1911后CCR还是1136，那么占空比变成了1136/1912 ≈ 59%，波形不再对称，音色会变差。把CCR设成arr/2，保证任何频率下都是50%占空比。

另一个容易被忽略的是修改ARR时用到的高位函数。HAL库提供__HAL_TIM_SET_AUTORELOAD宏来设置ARR，但如果你用的是老版本的标准库，对应的寄存器操作是TIMx->ARR = arr。这两种方式效果一样，但HAL库的宏做了寄存器同步，用起来更安全。

StopTone函数把比较值设为0，等于强制引脚一直输出低电平，蜂鸣器就安静了。这里不建议用HAL_TIM_PWM_Stop去停止定时器，因为停止后再启动会有额外开销，不如直接清零CCR来得干脆。

4.2 歌曲数据怎么存：音符+时值结构体数组

音乐播放程序的核心数据结构，是一个音符数组。每个音符需要两个信息：音高（频率）和时值（持续多久）。在C语言里，用结构体数组来存：

typedef struct { uint16_t freq; uint8_t beat; } Note; #define NOTE_C4 262 #define NOTE_D4 294 #define NOTE_E4 330 #define NOTE_F4 349 #define NOTE_G4 392 #define NOTE_A4 440 #define NOTE_B4 494 #define NOTE_C5 523 #define NOTE_REST 0

这里的beat表示节拍数。比如一首歌每分钟120拍，每拍就是500ms。如果某个音符持续一拍，beat=1；持续两拍，beat=2；半拍就是beat=0.5。但结构体里的beat用了uint8_t无符号整数，不能表示小数，所以我习惯把一拍拆成两个半拍，用1表示半拍、2表示一拍，这样所有时长都是整数，程序里换算时再除以2。

《小星星》的简谱是：

1 1 5 5 6 6 5 - | 4 4 3 3 2 2 1 -

对应到C大调，就是C C G G A A G | F F E E D D C。每个音符唱一拍，短线表示这个音符延长一拍半，为了简单先全部按一拍处理。歌曲数组这样写：

const Note melody[] = { {NOTE_C4, 2}, {NOTE_C4, 2}, {NOTE_G4, 2}, {NOTE_G4, 2}, {NOTE_A4, 2}, {NOTE_A4, 2}, {NOTE_G4, 4}, {NOTE_F4, 2}, {NOTE_F4, 2}, {NOTE_E4, 2}, {NOTE_E4, 2}, {NOTE_D4, 2}, {NOTE_D4, 2}, {NOTE_C4, 4}, };

这里的2表示一拍，4表示两拍。看到这里你可能会发现，节拍不仅影响音符持续多久，还决定了一首歌的呼吸感。两个音符之间如果没有间隔，音乐会显得很“糊”，所以播放时每个音符之后最好加一个非常短的静音间隔，模拟人弹琴时抬手指的感觉，时间一般是20ms到30ms。

4.3 完整播放逻辑：用阻塞延时还是状态机

先写一个最简单的播放函数，思路是遍历数组，每遇到一个音符就调用SetTone，然后用HAL_Delay阻塞等待对应的时长，再调用StopTone，进入下一个音符：

void PlayMelody(const Note *melody, uint16_t length) { for (uint16_t i = 0; i < length; i++) { if (melody[i].freq == NOTE_REST) { StopTone(); } else { SetTone(melody[i].freq); } HAL_Delay(melody[i].beat * 250); StopTone(); HAL_Delay(20); } StopTone(); }

这里把一拍定义为500ms，所以beat=2对应500ms的延时，beat=4对应1000ms，math上是 beat * 250。20ms是音符间隔。

这个写法最简单，能直接跑起来，但有一个明显的问题：整个程序会被阻塞住，播放期间什么都不能干。如果你只是想验证蜂鸣器能放出音乐，这样完全没问题；如果你打算做一个小作品，比如“按键控制音乐播放”“播放时OLED显示曲名”，那就要用状态机思路。

状态机播放的核心思想是：定时器每1ms产生一次中断，在中断里检查当前音符是否播放完成，完成就切换到下一个音符。主循环里只负责读按键、刷新屏幕等任务。这种写法复杂一些，但对入门阶段来说，先跑通阻塞版本、理解原理，再升级成状态机，是更平滑的学习路径。

4.4 实例：完整地跑一遍《小星星》

整个工程的核心代码汇总如下，我直接把main.c里修改的部分贴出来：

#include "main.h" TIM_HandleTypeDef htim2; // 音符频率定义 #define NOTE_C4 262 #define NOTE_D4 294 #define NOTE_E4 330 #define NOTE_F4 349 #define NOTE_G4 392 #define NOTE_A4 440 #define NOTE_B4 494 #define NOTE_C5 523 #define NOTE_REST 0 typedef struct { uint16_t freq; uint8_t beat; } Note; const Note melody[] = { {NOTE_C4, 2}, {NOTE_C4, 2}, {NOTE_G4, 2}, {NOTE_G4, 2}, {NOTE_A4, 2}, {NOTE_A4, 2}, {NOTE_G4, 4}, {NOTE_F4, 2}, {NOTE_F4, 2}, {NOTE_E4, 2}, {NOTE_E4, 2}, {NOTE_D4, 2}, {NOTE_D4, 2}, {NOTE_C4, 4}, }; void SetTone(uint16_t frequency) { uint32_t arr = 1000000 / frequency - 1; __HAL_TIM_SET_AUTORELOAD(&htim2, arr); __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, arr / 2); } void StopTone(void) { __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, 0); } void PlayMelody(const Note *melody, uint16_t length) { for (uint16_t i = 0; i < length; i++) { if (melody[i].freq == NOTE_REST) { StopTone(); } else { SetTone(melody[i].freq); } HAL_Delay(melody[i].beat * 250); StopTone(); HAL_Delay(20); } StopTone(); } int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_TIM2_Init(); HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1); while (1) { PlayMelody(melody, sizeof(melody) / sizeof(melody[0])); HAL_Delay(2000); } }

这段代码里，SetTone函数有一处值得注意的逻辑：我没有像之前封装的函数那样把frequency==0的情况放在这里处理，而是在播放函数里提前判断了。这样可以让SetTone专注做频率设置，播放逻辑里统一管理休止符，职责更清晰。

编译下载到板子里，上电后应该能连续播放两遍《小星星》，中间间隔2秒。第一次听到自己写的代码放出完整的曲子，那种成就感是看多少教程都体会不到的。

5. 常见问题与排查技巧实录

5.1 蜂鸣器完全不响，先排除这几个低级原因

最容易出问题的往往不是代码，而是硬件连接。先看蜂鸣器正负极，有源蜂鸣器长脚是正极、短脚是负极，但无源蜂鸣器两个引脚功能一样，怎么接都行，关键是确认它接到了三极管的集电极和电源之间，而不是直接接到GPIO。

再看三极管的引脚顺序。S8050的封装通常是E、B、C三根引脚，从左到右排列，不同厂家略有差异。我遇到过两次插反三极管的情况，现象是蜂鸣器毫无反应，或者声音特别小，万用表一量发现GPIO的3.3V根本就没到达基极。插上之前拿万用表蜂鸣档测一下三极管的各脚导通关系，可以省下半小时排查时间。

然后是代码层面。确认有没有真的启动了PWM输出。很多人配置好定时器后忘了调用HAL_TIM_PWM_Start，GPIO一直处于低电平，蜂鸣器肯定不会响。另外检查GPIO初始化：如果PA0被配置成了模拟输入或者推挽输出而不是复用功能，PWM信号根本送不出去。

最后，手头有示波器是最方便的，把探头夹在PA0引脚上，播放时应该能看到清晰的方波。没有示波器也可以拿万用表测平均电压，播放时PA0应该测到大约1.65V左右的平均电压，如果一直0V或者3.3V，说明PWM没有正确输出。

5.2 声音沙哑或音量很小，可能是驱动电路的问题

播放时声音沙哑，首先要怀疑三极管没有完全饱和导通。基极电阻太大是常见原因。有人用过10kΩ做限流电阻，声音特别闷，换1kΩ立刻改观。还有一个容易被忽略的因素：蜂鸣器电压和开发板电压不匹配。如果你用的是5V蜂鸣器，但蜂鸣器正极接到了3.3V，音量会明显偏小且声音发闷，因为压电片或电磁线圈的振动幅度不够。检查供电电压是否满足蜂鸣器规格。

如果蜂鸣器音量整体偏小，但声音是准的，可以试试把占空比从50%改成40%或者60%。压电式蜂鸣器对占空比比较敏感，有些型号在50%占空比下声音反而不大，稍微降低一些会明显变响。当然最直接的办法还是换一个灵敏度更高的蜂鸣器，或者提高供电电压。

声音沙哑还有一个隐蔽的原因：PWM频率设置错误。如果PSC配错了，实际输出的频率不是音符对应的频率而是几十千赫兹的高频信号，蜂鸣器只能发出尖锐的咝咝声，或者是叠加了非常难听的拍频。这种情况用示波器一看波形频率就明白了。

5.3 播放一段后程序卡死，问题通常出在中断和延时

阻塞版播放程序里最典型的卡死场景是：在定时器更新中断或者串口中断里调用了HAL_Delay。HAL_Delay的实现依赖SysTick中断，如果SysTick的中断优先级低于当前正在响应的中断，HAL_Delay里的while循环永远等不到SysTick触发，程序就挂死了。这个问题的排查思路不是在中断里找原因，而是检查代码结构——不要在中断服务函数里调用任何阻塞延时函数。

另一个卡死原因是定时器中断标志没清除。如果你开启了更新中断，在中断回调里没有调用HAL_TIM_IRQHandler或者没有清除更新标志位，中断会反复触发，主循环根本跑不到播放函数的下一行。用HAL库的时候记得在回调函数里先判断中断源，再处理业务逻辑，最后让HAL库自带的中断处理函数去清标志位，不要自己手动清。

还有一个经常遇到的怪问题：程序刚开始播放第一遍正常，第二遍就卡住或者乱码。这通常是因为歌曲数组越界或者数组长度计算错误。我上面代码里用的是sizeof(melody) / sizeof(melody[0])，这个写法是安全的。但如果有人手动写死长度15，而数组实际只有14个元素，播放完最后一个音符后访问了数组外的内存，读出来的频率值是个随机数，频率极高或者为0，就会导致程序行为异常。

5.4 想调音量怎么办：占空比就是音量旋钮

PWM的占空比直接影响蜂鸣器的响度。占空比50%时，方波正负对称，蜂鸣器振动幅度大，声音最响。把占空比调小，比如20%或者30%，蜂鸣器每个周期内通电时间变短，振动幅度减弱，声音自然变小。这是我推荐的首选调音量方式，因为不需要改硬件，改一行代码就能实现。

但要注意压电式蜂鸣器和电磁式蜂鸣器对占空比的响应不一样。压电式蜂鸣器需要一定的能量才能驱动压电陶瓷片发生形变，占空比过低，比如低于10%，可能直接不发声。电磁式蜂鸣器的情况好一些，但占空比太低时线圈电流上升时间不够，声音也会变得很弱。我的经验是，如果想调音量，从50%往下降到30%左右是比较安全的范围，太低容易失效。

还有一点，如果你想边播放音乐边做LED灯效，可以在播放函数里同步控制其他GPIO。但请注意，LED直接亮灭和PWM频率没有直接关系，我试过把LED接到同一个PWM引脚上，结果PWM频率太高，LED看起来就像半亮状态，完全看不出呼吸效果，想要LED闪烁效果还是用单独的延时或者定时器控制比较靠谱。

6. 一些进阶玩法

6.1 GPIO翻转法：不占用定时器PWM通道的备选方案

如果你的项目里定时器PWM通道都已经被LED调光、舵机控制占满了，还有一个没用PWM外设的方案：GPIO软件翻转 + 定时器中断。原理是让定时器周期等于音符频率的一半，在更新中断里翻转GPIO，这样产生方波。

具体做法是设置定时器的ARR使更新中断频率等于2倍目标音频，中断里写一句HAL_GPIO_TogglePin。这种方法的优点是不占用PWM输出通道，一个定时器可以同时控制多个GPIO引脚，缺点是频率精度受中断响应时间影响，而且如果中断服务函数里还有其他耗时操作，波形会变形。我的建议是，如果只是临时验证某个音符能响，这个方法很合适；想认真做一个音乐播放器，还是用PWM外设更可靠。

6.2 用DMA+TIM实现完全后台播放

阻塞版播放会占用CPU，状态机版播放也要在每次进中断时切换音符。能不能彻底不用CPU参与，让蜂鸣器自己把整首歌播完？可以，用DMA配合定时器就能实现。

思路是，把整首歌每个音符对应的ARR值排成一个数组，然后用DMA定时把数组里的值逐个搬运到定时器的ARR寄存器。每次搬运的间隔由一个固定的基础节拍定时器触发。这样CPU只需要初始化DMA传输，然后就可以去干别的事情，整首歌播完之后DMA会产生传输完成中断，再决定下一步动作。

这个玩法相对复杂，代码量比本文的例子多不少，但如果你以后想做多功能的作品，比如电子门铃同时显示天气播报，这套机制能大大提升程序的可维护性。我建议先把本文的状态机版本玩熟练了，再往这个方向扩展。

6.3 播放和弦的尝试与限制

蜂鸣器本质上是一个单音设备，一颗蜂鸣器只能发出一个频率的声音，很多新手问能不能用一颗蜂鸣器播放和弦。答案是能，但实现方式比较特殊：让不同频率的方波快速交替出现，利用人耳的听觉暂留效应，听起来像是同时发声。这个叫“扫频”或者“arpeggio分解和弦”，音色上更接近吉他的琶音而不是钢琴的和弦。

真正的多音同时播放，需要增加蜂鸣器的数量，每颗蜂鸣器由一个独立的定时器通道驱动。这种方案适合做一个多声部音乐盒，但成本和代码复杂度都会上升。对于入门项目，先把单音旋律做到音准、节奏稳，已经完全够用了。

我个人在实际制作中的体会是，这个项目的代码量不大，但知识密度很高。定时器、PWM、分频计算、硬件驱动、数据结构设计全部浓缩在里面，做完一遍收获很大。如果你刚开始接触STM32，建议先照着本文的步骤把硬件搭起来，然后修改歌曲数组，把《小星星》换成任何你喜欢的曲子。等你能熟练改曲子了，再试着把阻塞播放改成状态机播放，这一步对你理解嵌入式程序的架构设计会有很大帮助。