1. 项目初衷让吃灰的板子不只是闪灯手头这块 STM32F103C8T6 蓝色核心板严格来说已经不是 2012 年的初代版本但芯片型号和当年的老板子一模一样Cortex-M3 内核、72MHz 主频、20KB RAM、64KB Flash。这些年它一直被压在工具盒最底层偶尔拿出来点亮一个 LED再刷个流水灯然后就继续吃灰。直到最近大家都在聊 AI coding我也跟着用 AI 生成过网页、写过 Python 脚本、拼过 SQL 查询突然想起一个问题AI 编程的边界到底在哪它能不能驱动一块 2012 年的老板子让它不只是闪灯而是开口唱歌这个念头其实有点反直觉。大家提起 AI coding默认就是写业务逻辑、搭网站、补注释很少人会想到让它去操作寄存器、翻转 GPIO、配置定时器输出 PWM。但恰恰是嵌入式这种资源受限、时序敏感、很容易翻车的场景最能检验一个 AI 编程工具到底是真的懂硬件还是只会背模板。于是我给自己定了一个小目标用 AI 辅助生成代码让 STM32F103C8T6 通过 PWM 驱动一个无源蜂鸣器播放《小星星》。整篇博文会从方案选型、环境准备、AI 代码生成、实测踩坑到问题排查完整记录这个过程如果你想复现照着做就能听到声音。适合那些刚接触 AI coding、手里恰好有块老 STM32 板子或者想试试“AI 写嵌入式代码靠不靠谱”的朋友。先说结论AI 确实能写这段代码而且写得比我手写快得多但中间有两三个坑AI 第一次生成的版本直接没声是人工 review 才救回来的。这个过程中真正的难点不是“让 AI 写代码”而是“怎么把需求描述得足够精确以及怎么判断它写得对不对”。下面一点一点拆开讲。2. 方案选型为什么是 PWM 加无源蜂鸣器2.1 三种“开口唱歌”的实现路线要让开发板发出旋律业内最常见的做法有三条路PWM 驱动无源蜂鸣器、外接 DAC 播放 WAV 文件、用 I2S 接音频解码芯片播放高质量音乐。三条路都能响但复杂度完全不是一个量级。PWM 方案的核心思路是用定时器产生一个固定频率的方波频率决定了音高控制这个方波的持续时间和间隔就形成了节奏。蜂鸣器只要是无源的就会响应这个频率振动发出声音。这个方案对硬件要求极低一块板子、一个蜂鸣器、两根杜邦线就够而且它用到的是定时器、GPIO 复用、PWM 比较输出这三样嵌入式基础功能非常适合作为 AI coding 的验证项目。外接 DAC 播放 WAV 的路线要复杂不少。STM32F103C8T6 本身没有 DAC需要外挂一个 SPI 接口的 DAC 芯片或模块把 WAV 音频文件的采样点按采样率逐个送给 DAC才能还原音频波形。这条路涉及 SPI 通信、DMA 传输、音频数据的存储组织工程量大得多。I2S 路线就更重了一般要上 CS4344 之类的音频解码芯片代码量会从几十行膨胀到几百行。如果我的目标是“让板子说话”PWM 是性价比最高的选择。如果目标是“让板子成为能放无损音乐的播放器”那才值得去碰 I2S。所以我最终选 PWM因为它能把问题控制在“AI 能生成、我能 review、新手能复现”的范围内。2.2 PWM 发声与音符频率的关系很多人以为蜂鸣器像喇叭一样给个高电平就会响。其实无源蜂鸣器内部没有振荡源必须外部不断给它一个脉冲信号它才会振动发声。脉冲的频率就是声音的基频频率越高听起来音调也越高。十二平均律是音乐里最常用的频率体系相邻半音之间频率比值为 2 的 1/12 次方。基准音 A4 是 440Hz那么其他音就可以用freq 440 x 2^((n-69)/12)计算出来n 是 MIDI 音符编号。不过实际写代码时没人会现场算这个通常直接预置一张常用音符频率表音符频率(Hz)音符频率(Hz)C4262G4392D4294A4440E4330B4494F4349C5523表中 C4 表示中央 C频率 262Hz它正上方的高音 C5 是 523Hz正好是翻倍的关系这个规律在写定时器参数时可以直接利用。STM32F103C8T6 的定时器时钟来自 APB1经过倍频后最高到 72MHz。要让定时器输出目标频率需要做两步先用预分频器把 72MHz 降到一个合适的计数基准频率再设置自动重装载值让计数周期正好等于目标频率的倒数。以 1MHz 计数基准来算很简单预分频系数设 71则72MHz / 72 1MHz这时候定时器从 0 数到 ARR 再归零输出 PWM 的频率就是1MHz / (ARR 1)。要发 262Hz 的 C4ARR 就是1000000 / 262 - 1 ≈ 3815要发 523Hz 的 C5ARR 就是 1911。差值很大所以每个音符都要重新设置 ARR 值不能偷懒写死。比较寄存器决定占空比也就是方波高电平占一个周期的比例。占空比越低蜂鸣器得到的有效能量越少声音就越小声但太高又容易让蜂鸣器饱和产生失真。实际听下来 50% 左右的占空比最清晰这也是后面代码里把比较值设成 ARR 一半的原因。3. 开发环境与 AI 工具准备3.1 硬件接线与材料清单这次涉及的硬件很简单我列一下清单STM32F103C8T6 核心板一块、无源蜂鸣器一个、面包板一块、杜邦线若干、ST-Link 下载器一个USB-TTL 串口下载也可以但老手都会建议备一个 ST-Link调试方便太多。注意蜂鸣器必须买无源的也就是外观通常是黑色圆柱体、上面没有丝印标注“有源”的型号用万用表电阻档去测无源蜂鸣器测出来有一定电阻值有源蜂鸣器通常测不出稳定电阻。接线方面我把蜂鸣器正极接 PA0负极接 GND中间串了一个 100 欧姆限流电阻。PA0 是 TIM2_CH1 的复用引脚这样配置定时器输出 PWM 时不用改 IO 映射。虽然 GPIO 直接驱动小蜂鸣器也能响但稳妥起见最好加一个 NPN 三极管和上拉电阻做驱动电路因为 GPIO 的灌电流限制在 25mA 左右直接驱动大音量蜂鸣器有隐患。不过对于《小星星》这种轻负载串电阻直驱是没问题的。3.2 工具链选择标准外设库还是 HAL 库代码风格我选择了 STM32 标准外设库SPL而不是 HAL 库。原因有三第一2012 年前后的老板子教程大多数基于标准外设库网上现成的参考代码和讨论最多第二AI 训练语料里标准外设库的代码量非常大生成结果会更贴近可用代码第三标准外设库是直接操作寄存器封装后的 API逻辑链路更短出问题时容易反向追踪。编译环境用 Keil MDK5选择 ARM Compiler 5 编译器。顺手在 Keil 的 Pack Installer 里装好 STM32F1 系列器件支持包然后把芯片型号选成 STM32F103C8。这里有个容易忽略的点如果电脑已经装了 Keil 默认的 AC6 编译器部分老的标准外设库代码在 AC6 下会报一堆类型不匹配的警告甚至错误直接改成 AC5 最省心。创建一个空工程后需要手动添加启动文件startup_stm32f10x_md.s以及标准外设库里的stm32f10x_gpio.c、stm32f10x_tim.c、stm32f10x_rcc.c这几个源文件。3.3 AI 辅助工具怎么选我平时在 VS Code 里用 AI 编程插件比如 Fitten Code、通义灵码这类对话式助手都可以核心逻辑是先在对话窗口生成并迭代代码再把确认过的代码复制到 Keil 工程里编译。为什么不直接在 Keil 里装 AI 插件主要是 Keil 的插件生态不如 VS Code 丰富而且在编辑器里管代码迁移更顺手。还有一个很重要的习惯让 AI 生成代码后再让它为你逐行解释每段代码对应的寄存器级别操作。这个环节不是为了看它解释得多漂亮而是为了检验它生成的内容是否和芯片手册一致。AI 在自然语言上很流畅但涉及具体引脚映射、时钟使能、外设枚举值时经常一本正经地编造。如果它解释到RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE)时说得准确那这一行代码大概率没问题如果它含糊其辞说“使能了定时器时钟”那就得回头查芯片手册了。4. AI 生成播放代码的核心环节4.1 需求描述必须精确到引脚级同样的项目不同写法给 AI得到的代码质量天差地别。这是我试过的最无效 prompt“写一个 STM32 蜂鸣器播放小星星的代码”。AI 会给你一个看起来很完整、但引脚和库函数全凭猜的版本编译大概率过不了甚至可能把 PA0 当成普通 GPIO 来拉高拉低根本没有 PWM 波形。有效的需求描述要遵循“芯片型号 外设资源 时钟来源 引脚映射 行为目标 输出格式”的结构。举个例子我最终发给 AI 的 prompt 是这样的使用 STM32F103C8T6 和标准外设库用 TIM2_CH1 的 PWM 模式驱动 PA0 引脚上的无源蜂鸣器播放《小星星》前两行旋律。要求TIM2 预分频系数 71计数时钟 1MHz每个音符通过改变 ARR 值改变频率比较值设为 ARR 的一半提供TIM2_PWM_Init初始化和Play_Note(uint16_t freq, uint16_t duration_ms)播放函数音符频率用整型常量定义避免浮点运算旋律以二维数组{频率, 时长}的形式存放请给出完整可编译的 main 函数注释用中文。这个 prompt 看起来啰嗦但其实每一条都是必要的约束预分频系数直接告诉它定时器参数避免它自己瞎算音符频率用整型常量是为了在嵌入式上避免浮点库开销二维数组的结构是为了让后续修改歌曲内容时不用改逻辑代码。AI 拿到这些信息后生成的第一版就已经非常接近可用状态。这说明一个问题AI coding 的能力上限很大程度上取决于提问者描述需求的精确度。这和我们平时带新人写代码是一样的需求说得越清楚交付物质量越高。4.2 第一次生成代码能编译但没声音AI 第一次生成的代码确实可以编译通过烧录后蜂鸣器却一声不吭。我当时以为是蜂鸣器坏了换一个还是不响用万用表量 PA0 电压纹丝不动这才意识到问题出在代码逻辑上。回看 AI 生成的代码它把 PA0 初始化成了GPIO_Mode_Out_PP普通推挽输出然后通过不断调用GPIO_SetBits和GPIO_ResetBits制造方波。这个思路从原理上说得通但普通 GPIO 翻转完全依赖 CPU 干预而且翻转频率受循环里各种判断影响达不到稳定输出。正确做法是把 PA0 配成GPIO_Mode_AF_PP复用推挽输出由定时器硬件接管引脚输出。这其实是个很经典的嵌入式新手误区觉得 GPIO 可以输出方波就足够了忽略了 PWM 要靠外设生成而不是软件模拟。AI 之所以会这样写大概率是因为它在生成时没有区分“普通 IO 翻转”和“定时器 PWM 输出”这两种完全不同的实现机制。把它生成代码里的 GPIO 初始化改成GPIO_Mode_AF_PP同时把输出逻辑改为设置定时器比较寄存器声音立刻就出来了。这里强烈建议大家不要跳过 AI 生成代码的人工 review 环节尤其是时钟使能部分。AI 生成的代码里曾经漏掉了RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO, ENABLE)AFIO 时钟不使能引脚复用功能就无法正常工作。对于新手来说挨个对照参考手册去查每一句RCC配置是最好的一课。4.3 完整可用的播放代码参考经过人工修正后的最终版本核心结构可以整理成三部分定时器 PWM 初始化、音符频率设置、播放旋律。完整代码如下。#include stm32f10x.h #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 // 旋律{音符频率, 时长毫秒}0 表示休止符 const uint16_t score[][2] { {NOTE_C4, 400}, {NOTE_C4, 400}, {NOTE_G4, 400}, {NOTE_G4, 400}, {NOTE_A4, 400}, {NOTE_A4, 400}, {NOTE_G4, 800}, {NOTE_F4, 400}, {NOTE_F4, 400}, {NOTE_E4, 400}, {NOTE_E4, 400}, {NOTE_D4, 400}, {NOTE_D4, 400}, {NOTE_C4, 800} }; void TIM2_PWM_Init(void) { GPIO_InitTypeDef gpio; TIM_TimeBaseInitTypeDef tim; TIM_OCInitTypeDef oc; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_AFIO, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE); gpio.GPIO_Pin GPIO_Pin_0; gpio.GPIO_Mode GPIO_Mode_AF_PP; gpio.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOA, gpio); tim.TIM_Prescaler 71; tim.TIM_CounterMode TIM_CounterMode_Up; tim.TIM_Period 999; tim.TIM_ClockDivision 0; TIM_TimeBaseInit(TIM2, tim); oc.TIM_OCMode TIM_OCMode_PWM1; oc.TIM_OutputState TIM_OutputState_Enable; oc.TIM_Pulse 500; oc.TIM_OCPolarity TIM_OCPolarity_High; TIM_OC1Init(TIM2, oc); TIM_OC1PreloadConfig(TIM2, TIM_OCPreload_Enable); TIM_Cmd(TIM2, ENABLE); } void Set_Freq(uint16_t freq) { if (freq 0) { TIM_SetCompare1(TIM2, 0); return; } uint16_t arr 1000000 / freq - 1; TIM_SetAutoreload(TIM2, arr); TIM_SetCompare1(TIM2, arr / 2); } void Delay_Ms(uint32_t ms) { for (uint32_t i 0; i ms; i) { for (uint32_t j 0; j 7200; j) { __NOP(); } } } int main(void) { TIM2_PWM_Init(); uint8_t i; uint16_t score_len sizeof(score) / sizeof(score[0]); while (1) { for (i 0; i score_len; i) { Set_Freq(score[i][0]); Delay_Ms(score[i][1]); } Delay_Ms(1000); } }代码里的Set_Freq函数每次根据目标频率计算 ARR 值这是整个程序最核心的换算arr 1000000 / freq - 1。要注意 ARR 是 16 位寄存器最高能表示 65535对应最低频率大约 15Hz完全覆盖人耳能听到的 20Hz 到 20kHz 范围。TIM_SetCompare1设置为arr / 2即 50% 占空比声音最清晰。休止符的处理方式是直接将比较值清零这样 PWM 输出保持低电平蜂鸣器自然不响。Delay_Ms函数我用了一个简单的空循环累加在 72MHz 主频下每个循环大约 1ms这个精度对播放音乐来说完全够用。如果想更严谨可以改成 SysTick 精确延时但对于一个小玩具项目空循环的可读性更强而且不会被中断抢占导致节奏错乱。4.4 人工检查清单烧录前必须过一遍AI 生成代码后我建议在烧录前逐项检查下面几个点这些都是 AI 在嵌入式代码上最容易出错的地方检查项检查方法常见错误引脚复用模式确认目标引脚是GPIO_Mode_AF_PP被 AI 配成GPIO_Mode_Out_PP无 PWM 输出外设时钟逐个核对 RCC 使能的外设与代码使用的外设一致漏使能 AFIO 或 TIM2 时钟定时器预分频确认TIM_Prescaler与计数时钟关系正确忘了减 1实际频率偏 1/72比较寄存器对比 ARR 的一半逻辑占空比写成 0 或 65535触摸中断确认主循环存在AI 可能只给初始化没有循环程序跑完就死无源还是无源硬件确认蜂鸣器无源拿有源蜂鸣器当无源用怎么调都不出旋律这六项检查看起来简单但正是 AI coding 在嵌入式领域最需要人工介入的地方。大语言模型擅长的是从语料库中拼接出高度可能的代码序列而嵌入式代码的关键恰好在于“当前这颗芯片的特定外设配置是否正确”这是拼概率拼不出来的得靠人对芯片手册的理解去兜底。我的建议是不把 AI 当“自动写代码机”而是当“结对编程的实习生”它负责产出初稿你负责指出错误并解释原因。这个流程走下来AI 生成代码的质量会越调越好。5. 实测记录从无声到《小星星》5.1 第一次上电PA0 毫无反应烧录后按下复位键蜂鸣器一片寂静。我当时第一反应是蜂鸣器接反了因为蜂鸣器有正负极之分很多初学者的第一反应都是换方向。检查后发现接线没问题于是用万用表量 PA0 对地电压居然稳定在 0V这说明代码根本没让定时器输出东西。再检查定时器状态寄存器和 GPIO 配置发现 AI 生成的GPIO_InitStructure.GPIO_Mode选的是普通推挽输出而不是复用推挽所以 PA0 被 GPIO 外设接管了定时器输出信号过不去。改成GPIO_Mode_AF_PP后万用表能测到 PA0 在 0 到 3.3V 之间跳动了蜂鸣器立刻出声。这个坑非常典型很多从 Arduino 转过来的朋友会觉得“GPIO 翻转一下不就有了吗”但 STM32 的 PWM 输出必须通过复用功能把外设信号连接到引脚上这也是它比 Arduino 更底层、更需要看手册的地方。AI 在生成代码时很容易在这个环节偷懒因为普通 GPIO 模式在代码里看起来更“直观”也是训练语料里最常见的写法。5.2 节奏不对短音和长音的区别第一次听到声音后其实还不像《小星星》更像一段持续嗡嗡的电子音因为音符时长全部一样没有长短音交替听不出来旋律的起伏。播放音乐不光要控制音高还要控制音长。乐谱里四分音符和二分音符的时值要区分开尾音要适当延长。我把旋律数组从{频率, 时长}压成{频率, 节拍}的表示方式用节拍数乘以基础单位时长来计算。比如设置基础时长为 200ms四分音符就是 400ms二分音符就是 800ms。AI 生成的代码里数组里的时长写的一律是 400听起来完全没有层次。我在 prompt 里明确要求“用节拍数组”并在数组里让NOTE_G4, 800表示二分音符这才像模像样地听出了《小星星》的轮廓。还遇到一个细节整体的速度偏快。当时基础时长定成了 100ms整首歌 15 秒放完像是开了倍速。后来把基础时长调到 200ms播放速度就自然多了。这个参数完全靠耳朵判断没有绝对标准音乐节奏的主观感受就是要自己反复试。5.3 占空比与音量的关系在调试音量的时候我踩了一个别人常年的坑以为占空比越大声音越大于是把比较值设成了 ARR 的 90%结果声音不仅没变大反而变得沉闷刺耳。原因是蜂鸣器的发声原理是振膜的机械振动占空比过大会让振膜在单个周期内因持续高电平而产生非线性失真。50% 占空比的方波信号最接近理想交变信号振膜振动最充分声音最清脆。如果想让音量变小可以调低比较值但不要试图调高到 90% 以上输出效果反而会劣化。另外一个容易忽略的点是电源稳定性。蜂鸣器发声瞬间电流会跳动如果开发板用 USB 口供电且线材过细声音会有明显劣化。我给板子换了一根粗的 USB 线或者直接用 ST-Link 的 3.3V 供电声音稳定性明显改善。遇到蜂鸣器发颤的情况先查电源再查占空比。6. 常见问题排查速查表整个项目跑完后我把过程中遇到和预判到的常见问题整理成了下面这张表新手朋友可以直接对照排查。现象可能原因排查与解决完全无声蜂鸣器是有源型无源蜂鸣器才可以用外部 PWM 驱动变调有源蜂鸣器只会通电就响换硬件完全无声GPIO 没有配成复用模式检查GPIO_Mode_AF_PP不要用GPIO_Mode_Out_PP完全无声定时器时钟没使能检查 RCC 里是否有RCC_APB1Periph_TIM2完全无声比较值设成 0休止符才把比较值设为 0正常音符要设成arr/2声音沙哑占空比过大调回 50% 左右避免超过 80%声音很弱占空比过小比较值至少设置为 ARR 的 20% 以上声音发颤电源供电不足换粗 USB 线或改用 ST-Link 供电节奏不对延时函数精度偏差太大改用 SysTick 延时或用逻辑分析仪量波形编译报错标准外设库缺少源文件把stm32f10x_gpio.cstm32f10x_tim.cstm32f10x_rcc.c全部加入工程编译报错编译器版本不兼容在 Keil 里切换到 ARM Compiler 5重复播放只有第一句数组越界或循环变量类型错误检查score_len计算和循环变量是否为无符号类型这条表里最后两个问题最容易被忽视。数组越界在 C 语言里是典型的“编译能过但运行炸掉”问题AI 生成代码时偶尔会把数组长度算错或者用int8_t去遍历一个超过 127 个元素的数组。换成uint8_t并计算sizeof是稳妥做法。编译器版本问题则更隐蔽老标准外设库代码在新编译器下会出现大量警告虽然不一定导致功能错误但会掩盖真正重要的报错信息换用 AC5 后编译输出干净很多。7. 项目扩展与 AI coding 的一点心得7.1 从《小星星》到更多玩法这个项目跑通之后往上扩展的空间其实非常大。《小星星》只是单一音轨如果想播放更丰富的旋律可以把音符表扩展成真正 MIDI 编号数组让 AI 生成任意一段乐谱数据还可以加上“模式切换按键”单击播放一首、双击播放另一首。更有趣的方向是给板子加上温度传感器当温度超过阈值时播放一段警报旋律这样它就从一个玩具变成了一个能“用声音反馈状态”的实用小设备。如果想挑战更难的可以让 AI 生成 I2S 驱动代码配合一个便宜的音频解码芯片播放 WAV 文件那就是从蜂鸣器音乐升级到真正的音频播放了。不过这个跨度比较大建议先把 PWM 方案吃透再去想 I2S。我在实际测试中还试过让 AI 同时控制两块板子一块负责主旋律、一块负责和声利用 USART 做同步信号效果很有成就感但这个项目需要两块开发板和更多调试时间不太适合新手一次到位。7.2 AI 写嵌入式代码与写业务代码的区别用 AI 写嵌入式代码和写 Web 代码体验差别很明显。写 Web 或脚本时AI 生成的代码即使有 bug你只要跑一下测试就能立刻发现迭代速度非常快。但嵌入式代码出了问题往往是硬件不响应而硬件不响应可能由引脚配错、时钟没开、外设没复位、编译器优化过头等十几个原因引起排查链路长得多。这让“人工 review 前置”变得比代码生成更重要也让我对 AI coding 有了新的理解AI 真正的价值是大幅提高初稿质量和信息搜集速度而不是替代工程师的判断。用了几天 AI 辅助编写嵌入式代码后我最大的收获反而不是代码本身而是学会了如何把需求拆解成机器能理解的最小单元。之前写嵌入式代码我习惯一边看手册一边试寄存器现在我会先在脑子里想清楚这个外设用什么引脚、什么时钟源、什么模式然后把这些信息全部塞进 prompt。这样的思维方式迁移到任何领域都管用需求的精确度决定了交付的质量。最终这块 2012 年的老板子终于开口唱歌了而我个人对这种“AI 生成加人工审查”的开发节奏也越来越得心应手手上的老芯片也从吃灰板变成了随时可以拿出来验证新思路的试验台。最后再分享一个小技巧如果你也想在类似项目里用 AI 帮忙完成第一版后一定马上问它一句话——“你用了哪些寄存器能不能直接给我一份寄存器版本的代码”这一问基本能暴露 AI 对底层细节的真实理解程度也能帮你把这些最枯燥的硬件知识重新捡起来。我每次这么追问之后再看手头的芯片手册都觉得它们没那么难啃了。
1. 项目初衷让吃灰的板子不只是闪灯手头这块 STM32F103C8T6 蓝色核心板严格来说已经不是 2012 年的初代版本但芯片型号和当年的老板子一模一样Cortex-M3 内核、72MHz 主频、20KB RAM、64KB Flash。这些年它一直被压在工具盒最底层偶尔拿出来点亮一个 LED再刷个流水灯然后就继续吃灰。直到最近大家都在聊 AI coding我也跟着用 AI 生成过网页、写过 Python 脚本、拼过 SQL 查询突然想起一个问题AI 编程的边界到底在哪它能不能驱动一块 2012 年的老板子让它不只是闪灯而是开口唱歌这个念头其实有点反直觉。大家提起 AI coding默认就是写业务逻辑、搭网站、补注释很少人会想到让它去操作寄存器、翻转 GPIO、配置定时器输出 PWM。但恰恰是嵌入式这种资源受限、时序敏感、很容易翻车的场景最能检验一个 AI 编程工具到底是真的懂硬件还是只会背模板。于是我给自己定了一个小目标用 AI 辅助生成代码让 STM32F103C8T6 通过 PWM 驱动一个无源蜂鸣器播放《小星星》。整篇博文会从方案选型、环境准备、AI 代码生成、实测踩坑到问题排查完整记录这个过程如果你想复现照着做就能听到声音。适合那些刚接触 AI coding、手里恰好有块老 STM32 板子或者想试试“AI 写嵌入式代码靠不靠谱”的朋友。先说结论AI 确实能写这段代码而且写得比我手写快得多但中间有两三个坑AI 第一次生成的版本直接没声是人工 review 才救回来的。这个过程中真正的难点不是“让 AI 写代码”而是“怎么把需求描述得足够精确以及怎么判断它写得对不对”。下面一点一点拆开讲。2. 方案选型为什么是 PWM 加无源蜂鸣器2.1 三种“开口唱歌”的实现路线要让开发板发出旋律业内最常见的做法有三条路PWM 驱动无源蜂鸣器、外接 DAC 播放 WAV 文件、用 I2S 接音频解码芯片播放高质量音乐。三条路都能响但复杂度完全不是一个量级。PWM 方案的核心思路是用定时器产生一个固定频率的方波频率决定了音高控制这个方波的持续时间和间隔就形成了节奏。蜂鸣器只要是无源的就会响应这个频率振动发出声音。这个方案对硬件要求极低一块板子、一个蜂鸣器、两根杜邦线就够而且它用到的是定时器、GPIO 复用、PWM 比较输出这三样嵌入式基础功能非常适合作为 AI coding 的验证项目。外接 DAC 播放 WAV 的路线要复杂不少。STM32F103C8T6 本身没有 DAC需要外挂一个 SPI 接口的 DAC 芯片或模块把 WAV 音频文件的采样点按采样率逐个送给 DAC才能还原音频波形。这条路涉及 SPI 通信、DMA 传输、音频数据的存储组织工程量大得多。I2S 路线就更重了一般要上 CS4344 之类的音频解码芯片代码量会从几十行膨胀到几百行。如果我的目标是“让板子说话”PWM 是性价比最高的选择。如果目标是“让板子成为能放无损音乐的播放器”那才值得去碰 I2S。所以我最终选 PWM因为它能把问题控制在“AI 能生成、我能 review、新手能复现”的范围内。2.2 PWM 发声与音符频率的关系很多人以为蜂鸣器像喇叭一样给个高电平就会响。其实无源蜂鸣器内部没有振荡源必须外部不断给它一个脉冲信号它才会振动发声。脉冲的频率就是声音的基频频率越高听起来音调也越高。十二平均律是音乐里最常用的频率体系相邻半音之间频率比值为 2 的 1/12 次方。基准音 A4 是 440Hz那么其他音就可以用freq 440 x 2^((n-69)/12)计算出来n 是 MIDI 音符编号。不过实际写代码时没人会现场算这个通常直接预置一张常用音符频率表音符频率(Hz)音符频率(Hz)C4262G4392D4294A4440E4330B4494F4349C5523表中 C4 表示中央 C频率 262Hz它正上方的高音 C5 是 523Hz正好是翻倍的关系这个规律在写定时器参数时可以直接利用。STM32F103C8T6 的定时器时钟来自 APB1经过倍频后最高到 72MHz。要让定时器输出目标频率需要做两步先用预分频器把 72MHz 降到一个合适的计数基准频率再设置自动重装载值让计数周期正好等于目标频率的倒数。以 1MHz 计数基准来算很简单预分频系数设 71则72MHz / 72 1MHz这时候定时器从 0 数到 ARR 再归零输出 PWM 的频率就是1MHz / (ARR 1)。要发 262Hz 的 C4ARR 就是1000000 / 262 - 1 ≈ 3815要发 523Hz 的 C5ARR 就是 1911。差值很大所以每个音符都要重新设置 ARR 值不能偷懒写死。比较寄存器决定占空比也就是方波高电平占一个周期的比例。占空比越低蜂鸣器得到的有效能量越少声音就越小声但太高又容易让蜂鸣器饱和产生失真。实际听下来 50% 左右的占空比最清晰这也是后面代码里把比较值设成 ARR 一半的原因。3. 开发环境与 AI 工具准备3.1 硬件接线与材料清单这次涉及的硬件很简单我列一下清单STM32F103C8T6 核心板一块、无源蜂鸣器一个、面包板一块、杜邦线若干、ST-Link 下载器一个USB-TTL 串口下载也可以但老手都会建议备一个 ST-Link调试方便太多。注意蜂鸣器必须买无源的也就是外观通常是黑色圆柱体、上面没有丝印标注“有源”的型号用万用表电阻档去测无源蜂鸣器测出来有一定电阻值有源蜂鸣器通常测不出稳定电阻。接线方面我把蜂鸣器正极接 PA0负极接 GND中间串了一个 100 欧姆限流电阻。PA0 是 TIM2_CH1 的复用引脚这样配置定时器输出 PWM 时不用改 IO 映射。虽然 GPIO 直接驱动小蜂鸣器也能响但稳妥起见最好加一个 NPN 三极管和上拉电阻做驱动电路因为 GPIO 的灌电流限制在 25mA 左右直接驱动大音量蜂鸣器有隐患。不过对于《小星星》这种轻负载串电阻直驱是没问题的。3.2 工具链选择标准外设库还是 HAL 库代码风格我选择了 STM32 标准外设库SPL而不是 HAL 库。原因有三第一2012 年前后的老板子教程大多数基于标准外设库网上现成的参考代码和讨论最多第二AI 训练语料里标准外设库的代码量非常大生成结果会更贴近可用代码第三标准外设库是直接操作寄存器封装后的 API逻辑链路更短出问题时容易反向追踪。编译环境用 Keil MDK5选择 ARM Compiler 5 编译器。顺手在 Keil 的 Pack Installer 里装好 STM32F1 系列器件支持包然后把芯片型号选成 STM32F103C8。这里有个容易忽略的点如果电脑已经装了 Keil 默认的 AC6 编译器部分老的标准外设库代码在 AC6 下会报一堆类型不匹配的警告甚至错误直接改成 AC5 最省心。创建一个空工程后需要手动添加启动文件startup_stm32f10x_md.s以及标准外设库里的stm32f10x_gpio.c、stm32f10x_tim.c、stm32f10x_rcc.c这几个源文件。3.3 AI 辅助工具怎么选我平时在 VS Code 里用 AI 编程插件比如 Fitten Code、通义灵码这类对话式助手都可以核心逻辑是先在对话窗口生成并迭代代码再把确认过的代码复制到 Keil 工程里编译。为什么不直接在 Keil 里装 AI 插件主要是 Keil 的插件生态不如 VS Code 丰富而且在编辑器里管代码迁移更顺手。还有一个很重要的习惯让 AI 生成代码后再让它为你逐行解释每段代码对应的寄存器级别操作。这个环节不是为了看它解释得多漂亮而是为了检验它生成的内容是否和芯片手册一致。AI 在自然语言上很流畅但涉及具体引脚映射、时钟使能、外设枚举值时经常一本正经地编造。如果它解释到RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE)时说得准确那这一行代码大概率没问题如果它含糊其辞说“使能了定时器时钟”那就得回头查芯片手册了。4. AI 生成播放代码的核心环节4.1 需求描述必须精确到引脚级同样的项目不同写法给 AI得到的代码质量天差地别。这是我试过的最无效 prompt“写一个 STM32 蜂鸣器播放小星星的代码”。AI 会给你一个看起来很完整、但引脚和库函数全凭猜的版本编译大概率过不了甚至可能把 PA0 当成普通 GPIO 来拉高拉低根本没有 PWM 波形。有效的需求描述要遵循“芯片型号 外设资源 时钟来源 引脚映射 行为目标 输出格式”的结构。举个例子我最终发给 AI 的 prompt 是这样的使用 STM32F103C8T6 和标准外设库用 TIM2_CH1 的 PWM 模式驱动 PA0 引脚上的无源蜂鸣器播放《小星星》前两行旋律。要求TIM2 预分频系数 71计数时钟 1MHz每个音符通过改变 ARR 值改变频率比较值设为 ARR 的一半提供TIM2_PWM_Init初始化和Play_Note(uint16_t freq, uint16_t duration_ms)播放函数音符频率用整型常量定义避免浮点运算旋律以二维数组{频率, 时长}的形式存放请给出完整可编译的 main 函数注释用中文。这个 prompt 看起来啰嗦但其实每一条都是必要的约束预分频系数直接告诉它定时器参数避免它自己瞎算音符频率用整型常量是为了在嵌入式上避免浮点库开销二维数组的结构是为了让后续修改歌曲内容时不用改逻辑代码。AI 拿到这些信息后生成的第一版就已经非常接近可用状态。这说明一个问题AI coding 的能力上限很大程度上取决于提问者描述需求的精确度。这和我们平时带新人写代码是一样的需求说得越清楚交付物质量越高。4.2 第一次生成代码能编译但没声音AI 第一次生成的代码确实可以编译通过烧录后蜂鸣器却一声不吭。我当时以为是蜂鸣器坏了换一个还是不响用万用表量 PA0 电压纹丝不动这才意识到问题出在代码逻辑上。回看 AI 生成的代码它把 PA0 初始化成了GPIO_Mode_Out_PP普通推挽输出然后通过不断调用GPIO_SetBits和GPIO_ResetBits制造方波。这个思路从原理上说得通但普通 GPIO 翻转完全依赖 CPU 干预而且翻转频率受循环里各种判断影响达不到稳定输出。正确做法是把 PA0 配成GPIO_Mode_AF_PP复用推挽输出由定时器硬件接管引脚输出。这其实是个很经典的嵌入式新手误区觉得 GPIO 可以输出方波就足够了忽略了 PWM 要靠外设生成而不是软件模拟。AI 之所以会这样写大概率是因为它在生成时没有区分“普通 IO 翻转”和“定时器 PWM 输出”这两种完全不同的实现机制。把它生成代码里的 GPIO 初始化改成GPIO_Mode_AF_PP同时把输出逻辑改为设置定时器比较寄存器声音立刻就出来了。这里强烈建议大家不要跳过 AI 生成代码的人工 review 环节尤其是时钟使能部分。AI 生成的代码里曾经漏掉了RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO, ENABLE)AFIO 时钟不使能引脚复用功能就无法正常工作。对于新手来说挨个对照参考手册去查每一句RCC配置是最好的一课。4.3 完整可用的播放代码参考经过人工修正后的最终版本核心结构可以整理成三部分定时器 PWM 初始化、音符频率设置、播放旋律。完整代码如下。#include stm32f10x.h #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 // 旋律{音符频率, 时长毫秒}0 表示休止符 const uint16_t score[][2] { {NOTE_C4, 400}, {NOTE_C4, 400}, {NOTE_G4, 400}, {NOTE_G4, 400}, {NOTE_A4, 400}, {NOTE_A4, 400}, {NOTE_G4, 800}, {NOTE_F4, 400}, {NOTE_F4, 400}, {NOTE_E4, 400}, {NOTE_E4, 400}, {NOTE_D4, 400}, {NOTE_D4, 400}, {NOTE_C4, 800} }; void TIM2_PWM_Init(void) { GPIO_InitTypeDef gpio; TIM_TimeBaseInitTypeDef tim; TIM_OCInitTypeDef oc; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_AFIO, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE); gpio.GPIO_Pin GPIO_Pin_0; gpio.GPIO_Mode GPIO_Mode_AF_PP; gpio.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOA, gpio); tim.TIM_Prescaler 71; tim.TIM_CounterMode TIM_CounterMode_Up; tim.TIM_Period 999; tim.TIM_ClockDivision 0; TIM_TimeBaseInit(TIM2, tim); oc.TIM_OCMode TIM_OCMode_PWM1; oc.TIM_OutputState TIM_OutputState_Enable; oc.TIM_Pulse 500; oc.TIM_OCPolarity TIM_OCPolarity_High; TIM_OC1Init(TIM2, oc); TIM_OC1PreloadConfig(TIM2, TIM_OCPreload_Enable); TIM_Cmd(TIM2, ENABLE); } void Set_Freq(uint16_t freq) { if (freq 0) { TIM_SetCompare1(TIM2, 0); return; } uint16_t arr 1000000 / freq - 1; TIM_SetAutoreload(TIM2, arr); TIM_SetCompare1(TIM2, arr / 2); } void Delay_Ms(uint32_t ms) { for (uint32_t i 0; i ms; i) { for (uint32_t j 0; j 7200; j) { __NOP(); } } } int main(void) { TIM2_PWM_Init(); uint8_t i; uint16_t score_len sizeof(score) / sizeof(score[0]); while (1) { for (i 0; i score_len; i) { Set_Freq(score[i][0]); Delay_Ms(score[i][1]); } Delay_Ms(1000); } }代码里的Set_Freq函数每次根据目标频率计算 ARR 值这是整个程序最核心的换算arr 1000000 / freq - 1。要注意 ARR 是 16 位寄存器最高能表示 65535对应最低频率大约 15Hz完全覆盖人耳能听到的 20Hz 到 20kHz 范围。TIM_SetCompare1设置为arr / 2即 50% 占空比声音最清晰。休止符的处理方式是直接将比较值清零这样 PWM 输出保持低电平蜂鸣器自然不响。Delay_Ms函数我用了一个简单的空循环累加在 72MHz 主频下每个循环大约 1ms这个精度对播放音乐来说完全够用。如果想更严谨可以改成 SysTick 精确延时但对于一个小玩具项目空循环的可读性更强而且不会被中断抢占导致节奏错乱。4.4 人工检查清单烧录前必须过一遍AI 生成代码后我建议在烧录前逐项检查下面几个点这些都是 AI 在嵌入式代码上最容易出错的地方检查项检查方法常见错误引脚复用模式确认目标引脚是GPIO_Mode_AF_PP被 AI 配成GPIO_Mode_Out_PP无 PWM 输出外设时钟逐个核对 RCC 使能的外设与代码使用的外设一致漏使能 AFIO 或 TIM2 时钟定时器预分频确认TIM_Prescaler与计数时钟关系正确忘了减 1实际频率偏 1/72比较寄存器对比 ARR 的一半逻辑占空比写成 0 或 65535触摸中断确认主循环存在AI 可能只给初始化没有循环程序跑完就死无源还是无源硬件确认蜂鸣器无源拿有源蜂鸣器当无源用怎么调都不出旋律这六项检查看起来简单但正是 AI coding 在嵌入式领域最需要人工介入的地方。大语言模型擅长的是从语料库中拼接出高度可能的代码序列而嵌入式代码的关键恰好在于“当前这颗芯片的特定外设配置是否正确”这是拼概率拼不出来的得靠人对芯片手册的理解去兜底。我的建议是不把 AI 当“自动写代码机”而是当“结对编程的实习生”它负责产出初稿你负责指出错误并解释原因。这个流程走下来AI 生成代码的质量会越调越好。5. 实测记录从无声到《小星星》5.1 第一次上电PA0 毫无反应烧录后按下复位键蜂鸣器一片寂静。我当时第一反应是蜂鸣器接反了因为蜂鸣器有正负极之分很多初学者的第一反应都是换方向。检查后发现接线没问题于是用万用表量 PA0 对地电压居然稳定在 0V这说明代码根本没让定时器输出东西。再检查定时器状态寄存器和 GPIO 配置发现 AI 生成的GPIO_InitStructure.GPIO_Mode选的是普通推挽输出而不是复用推挽所以 PA0 被 GPIO 外设接管了定时器输出信号过不去。改成GPIO_Mode_AF_PP后万用表能测到 PA0 在 0 到 3.3V 之间跳动了蜂鸣器立刻出声。这个坑非常典型很多从 Arduino 转过来的朋友会觉得“GPIO 翻转一下不就有了吗”但 STM32 的 PWM 输出必须通过复用功能把外设信号连接到引脚上这也是它比 Arduino 更底层、更需要看手册的地方。AI 在生成代码时很容易在这个环节偷懒因为普通 GPIO 模式在代码里看起来更“直观”也是训练语料里最常见的写法。5.2 节奏不对短音和长音的区别第一次听到声音后其实还不像《小星星》更像一段持续嗡嗡的电子音因为音符时长全部一样没有长短音交替听不出来旋律的起伏。播放音乐不光要控制音高还要控制音长。乐谱里四分音符和二分音符的时值要区分开尾音要适当延长。我把旋律数组从{频率, 时长}压成{频率, 节拍}的表示方式用节拍数乘以基础单位时长来计算。比如设置基础时长为 200ms四分音符就是 400ms二分音符就是 800ms。AI 生成的代码里数组里的时长写的一律是 400听起来完全没有层次。我在 prompt 里明确要求“用节拍数组”并在数组里让NOTE_G4, 800表示二分音符这才像模像样地听出了《小星星》的轮廓。还遇到一个细节整体的速度偏快。当时基础时长定成了 100ms整首歌 15 秒放完像是开了倍速。后来把基础时长调到 200ms播放速度就自然多了。这个参数完全靠耳朵判断没有绝对标准音乐节奏的主观感受就是要自己反复试。5.3 占空比与音量的关系在调试音量的时候我踩了一个别人常年的坑以为占空比越大声音越大于是把比较值设成了 ARR 的 90%结果声音不仅没变大反而变得沉闷刺耳。原因是蜂鸣器的发声原理是振膜的机械振动占空比过大会让振膜在单个周期内因持续高电平而产生非线性失真。50% 占空比的方波信号最接近理想交变信号振膜振动最充分声音最清脆。如果想让音量变小可以调低比较值但不要试图调高到 90% 以上输出效果反而会劣化。另外一个容易忽略的点是电源稳定性。蜂鸣器发声瞬间电流会跳动如果开发板用 USB 口供电且线材过细声音会有明显劣化。我给板子换了一根粗的 USB 线或者直接用 ST-Link 的 3.3V 供电声音稳定性明显改善。遇到蜂鸣器发颤的情况先查电源再查占空比。6. 常见问题排查速查表整个项目跑完后我把过程中遇到和预判到的常见问题整理成了下面这张表新手朋友可以直接对照排查。现象可能原因排查与解决完全无声蜂鸣器是有源型无源蜂鸣器才可以用外部 PWM 驱动变调有源蜂鸣器只会通电就响换硬件完全无声GPIO 没有配成复用模式检查GPIO_Mode_AF_PP不要用GPIO_Mode_Out_PP完全无声定时器时钟没使能检查 RCC 里是否有RCC_APB1Periph_TIM2完全无声比较值设成 0休止符才把比较值设为 0正常音符要设成arr/2声音沙哑占空比过大调回 50% 左右避免超过 80%声音很弱占空比过小比较值至少设置为 ARR 的 20% 以上声音发颤电源供电不足换粗 USB 线或改用 ST-Link 供电节奏不对延时函数精度偏差太大改用 SysTick 延时或用逻辑分析仪量波形编译报错标准外设库缺少源文件把stm32f10x_gpio.cstm32f10x_tim.cstm32f10x_rcc.c全部加入工程编译报错编译器版本不兼容在 Keil 里切换到 ARM Compiler 5重复播放只有第一句数组越界或循环变量类型错误检查score_len计算和循环变量是否为无符号类型这条表里最后两个问题最容易被忽视。数组越界在 C 语言里是典型的“编译能过但运行炸掉”问题AI 生成代码时偶尔会把数组长度算错或者用int8_t去遍历一个超过 127 个元素的数组。换成uint8_t并计算sizeof是稳妥做法。编译器版本问题则更隐蔽老标准外设库代码在新编译器下会出现大量警告虽然不一定导致功能错误但会掩盖真正重要的报错信息换用 AC5 后编译输出干净很多。7. 项目扩展与 AI coding 的一点心得7.1 从《小星星》到更多玩法这个项目跑通之后往上扩展的空间其实非常大。《小星星》只是单一音轨如果想播放更丰富的旋律可以把音符表扩展成真正 MIDI 编号数组让 AI 生成任意一段乐谱数据还可以加上“模式切换按键”单击播放一首、双击播放另一首。更有趣的方向是给板子加上温度传感器当温度超过阈值时播放一段警报旋律这样它就从一个玩具变成了一个能“用声音反馈状态”的实用小设备。如果想挑战更难的可以让 AI 生成 I2S 驱动代码配合一个便宜的音频解码芯片播放 WAV 文件那就是从蜂鸣器音乐升级到真正的音频播放了。不过这个跨度比较大建议先把 PWM 方案吃透再去想 I2S。我在实际测试中还试过让 AI 同时控制两块板子一块负责主旋律、一块负责和声利用 USART 做同步信号效果很有成就感但这个项目需要两块开发板和更多调试时间不太适合新手一次到位。7.2 AI 写嵌入式代码与写业务代码的区别用 AI 写嵌入式代码和写 Web 代码体验差别很明显。写 Web 或脚本时AI 生成的代码即使有 bug你只要跑一下测试就能立刻发现迭代速度非常快。但嵌入式代码出了问题往往是硬件不响应而硬件不响应可能由引脚配错、时钟没开、外设没复位、编译器优化过头等十几个原因引起排查链路长得多。这让“人工 review 前置”变得比代码生成更重要也让我对 AI coding 有了新的理解AI 真正的价值是大幅提高初稿质量和信息搜集速度而不是替代工程师的判断。用了几天 AI 辅助编写嵌入式代码后我最大的收获反而不是代码本身而是学会了如何把需求拆解成机器能理解的最小单元。之前写嵌入式代码我习惯一边看手册一边试寄存器现在我会先在脑子里想清楚这个外设用什么引脚、什么时钟源、什么模式然后把这些信息全部塞进 prompt。这样的思维方式迁移到任何领域都管用需求的精确度决定了交付的质量。最终这块 2012 年的老板子终于开口唱歌了而我个人对这种“AI 生成加人工审查”的开发节奏也越来越得心应手手上的老芯片也从吃灰板变成了随时可以拿出来验证新思路的试验台。最后再分享一个小技巧如果你也想在类似项目里用 AI 帮忙完成第一版后一定马上问它一句话——“你用了哪些寄存器能不能直接给我一份寄存器版本的代码”这一问基本能暴露 AI 对底层细节的真实理解程度也能帮你把这些最枯燥的硬件知识重新捡起来。我每次这么追问之后再看手头的芯片手册都觉得它们没那么难啃了。
