基于STM32与VS1053的公交车载语音报站系统设计

简介：基于STM32与ISD语音芯片的公交车智能报站系统完整工程资源，面向嵌入式学习者、电子竞赛参赛者及车载语音播报开发工程师，涵盖STM32驱动、ISD语音存储播放、GPS定位联动、音频功放与电源管理等核心模块。压缩包共222个文件，包括C源码、头文件、Keil工程配置文件（uvprojx/uvoptx）、编译生成的axf/hex固件、链接脚本sct、调试配置文件及备份资料等，整体约8.45MB，可直接用Keil打开工程并烧录至开发板验证。工程文件层级清晰，从外设初始化到语音播报触发逻辑均有完整代码，并保留了开发过程中的备份与映射文件，便于对照分析版本差异。系统设计还涉及用户交互按键、紧急广播等扩展功能，可帮助读者快速掌握嵌入式语音报站系统的软硬件协同思路。目前已有306人学习下载，适合作为课程设计参考、竞赛方案模板或实际项目开发起点。

1. 公交车报站系统：为什么我放弃了 51 和安卓方案，回到了 STM32 语音

做公交车报站，我第一次用 51 加一个 MP3 模块，在实验室里一切正常，上实车就翻车：司机手动按键和语音不同步、站都过了还在播报，乘客说车厢里像有个话痨。后来我把整个系统换成 STM32 语音方案——主控用 STM32F103，站名音频预录成 WAV 存在 SD 卡，VS1053 负责解码，功放直接推车内喇叭。这套做法胜在离线、实时、逻辑全在自己手里。线路固定的公交车、校车和景区接驳车都能用这套骨架，学生做毕设或者工程师做产品原型，照着改就行。这次拆的就是我手头的报站工程（代号 1111），从硬件选型到实车避坑一次讲完。

2. 硬件选型与核心电路：VS1053、SD 卡和功放是怎么分工的

在实车上跑过一次之后，我对“报站系统”的定义就变了：它首先是一套能在发动机点火、电瓶电压乱跳、喇叭线满车厢穿行的环境里正常工作的系统，然后才谈得上语音清楚。我把 1111 工程的硬件拆成主控、存储、功放三块单独选型，再拼到一起。这样出问题时排查边界很清楚，不会一上来就怀疑整体。

2.1 主控与语音解码：F103 系列够用吗

主控选 STM32F103C8T6，理由很直白：Cortex-M3 内核，主频 72MHz，20KB SRAM、64KB Flash，三路 USART、两路 SPI、12 位 ADC、若干定时器，报站场景根本用不满。C8T6 是 LQFP48 封装，两层板就能布，成本可控，资料也最好找。我见过有人用 F407 甚至 F429 做报站，功能上完全没问题，但功耗和布板面积都亏了。报站系统没有图像处理、没有大量浮点运算，F103 这个级别就是甜点。

语音解码有三种常见走法，我放在一起对比过：

固定线路场景我选 VS1053 + 预录 WAV。原因有三个：站名是固定的，预录音质最自然，不用在跑车时做 TTS 合成；VS1053 硬件解码不占主控时间，主循环腾得出手去管 GPS、按键和状态机；VS1053 自带模拟输出，接 PAM8403 功放非常顺。最初我在实验板上用 DAC 直出，听感还行，上车后旁边马达一带动，播报直接被噪声盖掉，换 VS1053 之后音频解码不再依赖主控时序，噪声问题简单了许多。

2.2 语音存储：SD 卡与 SPI Flash 的取舍

语音文件放哪是个容量问题。一条 40 站的线路，进站和出站各一段，每段 8 秒，16kHz 16bit 单声道 WAV 每秒约 31KB，一段就是 250KB，整条线路大约 20MB。microSD 卡轻松放下，SPI Flash 用 W25Q64 只有 8MB，装不下这套 16bit WAV 方案，除非压成 MP3 或降到 8kHz 8bit。我最后选了 microSD + SPI 模式 + FatFS，理由很简单：更新音频不用拆机，拔卡插电脑改完插回去就行。

SD 卡这里有个实际教训：STM32F103C8T6 没有 SDIO 外设，只能走 SPI 模式。SPI 模式初始化阶段对时钟非常敏感，必须在低速下完成上电握手，等卡返回空闲状态后再切高速时钟。这个细节直接决定十次上电成功几次，我后面排查章节还会单独展开。

2.3 功放与电源地线：底噪和爆音都出在这

功放选 PAM8403，D 类，3W×2，供电范围 2.5V 到 5.5V，效率高不发热。LM386 我也试过，静态电流大，跑一两个小时散热片烫手，公交车上没法这么用。音量电位器放在 VS1053 输出和 PAM8403 输入之间，用 20kΩ 对数式电位器，旋到中段时人声清晰度最好。

电源链路我按 12V/24V 电瓶通用来设计：电瓶 → XL4015 降压到 5V → AMS1117 降到 3.3V 给 MCU。选 XL4015 是因为它的输入范围是 8V 到 36V，电瓶启动瞬间被拉低到 9V 时，输出 5V 还能撑住；LM2596 虽然输入上限高，但压差要求大，启动跌落时 5V 容易先崩。电源输入端要并 TVS 管和 470uF 电解电容，吸收点火线圈的尖峰。

地线处理是最容易被忽略的一环。VS1053 的模拟地、PAM8403 的功放地、STM32 的数字地不能直接铺成一个平面，正确做法是在功放输入端附近用 0Ω 电阻或磁珠单点汇合，避免音频地环路。我第一次装车没注意，喇叭里有明显的哼声，跟油门踏板还有关系，后来才查出是 DC-DC 的开关纹波顺着地平面灌进了功放。从那以后，凡是带音频的项目，地线布局我都按这个规则来。

3. 语音数据准备与格式转换：从 GBK 站名表到能播的 WAV 文件

硬件定完之后，真正花时间的反而是把运营方的站名表变成一套能直接播的内容。这个阶段最容易出两种问题：编码乱码和响度不统一。前者让屏幕上的站名没法看，后者让车载喇叭里音量忽大忽小。下面按数据准备的顺序，把编码转换、音频参数、文件命名一条条说清楚。

3.1 站名文本编码：GBK 转 UTF-8 的场景

从公交运营拿到的站名表基本都是 GBK 编码的 CSV 文件，而 STM32 端的 FatFS 读取和日志输出统一用 UTF-8。两边不统一，最直接的后果就是 LCD 上站名乱码、日志对不上号。我一般先在 PC 上把站名表和播报文案统一转成 UTF-8 无 BOM，这样 STM32 端不需要跑转码，省掉一大块 Flash 和 RAM。转换脚本用 Python 几行就够：

# -*- coding: utf-8 -*- import csv def convert_station_table(src='stations_gbk.csv', dst='stations_utf8.txt'): with open(src, 'r', encoding='gbk', errors='ignore') as fin: reader = csv.reader(fin) with open(dst, 'w', encoding='utf-8', newline='') as fout: for row in reader: # 统一括号、去掉首尾空格，TTS 读起来才正常 clean = [cell.strip().replace('（', '(').replace('）', ')') for cell in row] fout.write('\t'.join(clean) + '\n') if __name__ == '__main__': convert_station_table()

逻辑说明：源文件用 gbk 读出，目标用 utf-8 写出，errors='ignore'是兜底，运营给的表格里偶尔混入生僻字，跳过总比中断好。newline=''是为了避免 Windows 下 csv 模块在行尾多打一个回车。清洗那行把中文括号换成英文括号，是因为部分 TTS 引擎遇到全角括号会直接读“括号”“括号”，换成英文括号后读音就正常了。

这步做完了，STM32 端拿到的就是干净、统一、可直接显示的 UTF-8 文本。整个过程在 PC 侧完成，板上不用放任何转码表。

3.2 离线语音包与音频参数：为什么是 16kHz 16bit 单声道

站名文本准备好之后，用离线语音包生成播报音频。现在离线语音包下载渠道很多，挑一个发音自然的合成引擎，把每一站的进站、出站文案批量跑一遍，输出 MP3 再统一转 WAV。不要图省事直接抓在线合成接口，一是授权上说不清，二是线路一改就要重新联网生成，维护很麻烦。

批量转码我用 ffmpeg 一条命令搞定：

ffmpeg -i raw_station_01.mp3 -ar 16000 -ac 1 -sample_fmt s16 \ -af loudnorm=I=-16:TP=-1.5:LRA=11 \ /mnt/voice/z_in_01.wav

参数说明：-ar 16000重采样到 16kHz；-ac 1转单声道；-sample_fmt s16输出 16bit PCM；loudnorm做响度归一化，I=-16 是整体响度目标，TP=-1.5 限制峰值防止削顶，LRA=11 控制动态范围。这组参数是我试了几版后固定下来的。TTS 生成的音频之间响度差异很大，不归一化的话，同一个音量档位下有的站听得清、有的站直接炸耳朵。

音频参数对最终效果影响很大，我的固定配置如下：

3.3 SD 卡目录结构与文件命名规则

文件命名直接决定 STM32 端代码好不好写。我的习惯是固定前缀加两位站号再加方向后缀，全部用小写 ASCII 文件名：

命名上不要用中文文件名，FatFS 默认没开中文文件名支持，就算开了，8.3 短文件名规则也会让“人民广场站_进站.wav”变成不可读的乱码。用短 ASCII 名，STM32 端用fopen("0:/voice/z_in_01.wav", "rb")直接找文件，代码简单，排查也方便。

提示：Windows 记事本保存 UTF-8 时默认带 BOM，STM32 解析时会把 BOM 当字符读进去导致乱码。保存配置文件时编码栏务必选“UTF-8”，不要选“UTF-8 with BOM”。

4. 报站逻辑与触发方式：GPS、轮轴脉冲与按键的三层兜底

资源文件就绪后，报站逻辑就成了主战场。设计上我不喜欢把 GPS 解析、按键响应、音频播放全塞进一个大循环，那样加一个功能就要动一次全局逻辑。1111 工程的做法是：触发方式固定成三种来源，统一汇到一个状态机上，再由状态机决定下一步播放什么。

4.1 触发方案对比：GPS、轮轴脉冲和人工按键

报站触发方式我列过一张对比表：

1111 工程用的是 GPS 主触发加按键兜底。轮轴脉冲其实也能做，STM32 定时器输入捕获可以直接数脉冲频率，换算车速和累计里程，但市区固定线路没必要为报站单独装传感器。GPS 模块一般输出 NMEA 到串口，波特率 9600，每秒一条 $GPRMC 帧。解析经纬度时先要把 ddmm.mmmm 的度分格式转成十进制小数，这是最容易写错的一步，我见过有人直接拿度分当小数算距离，结果偏差几百米。

4.2 状态机设计：进站、报站、离站的声音节奏

报站最忌讳的是播报和车辆动作不同步。我用一个四状态状态机，把进站、报站、停站、离站串起来，每个状态只有明确的进入条件和离开条件：

typedef enum { ST_IDLE, /* 未到站 */ ST_ARRIVING, /* 已触发，正在播提示音 */ ST_ANNOUNCE_IN, /* 正在播“XX路 到了” */ ST_STOP, /* 停站开门 */ ST_ANNOUNCE_OUT /* 正在播“下一站 XX” */ } bus_state_t; void bus_fsm_run(float dist_to_stop, int key_pressed) { switch (g_state) { case ST_IDLE: if (key_pressed || dist_to_stop < 80.0f) { play_tone(TONE_ATTENTION); g_state = ST_ARRIVING; } break; case ST_ARRIVING: if (audio_is_idle()) { play_voice(VOICE_IN, g_cur_station); g_state = ST_ANNOUNCE_IN; } break; case ST_ANNOUNCE_IN: if (audio_is_idle()) { set_door_signal(1); g_state = ST_STOP; } break; case ST_STOP: if (key_pressed && audio_is_idle()) { play_voice(VOICE_OUT, g_cur_station); g_state = ST_ANNOUNCE_OUT; } break; case ST_ANNOUNCE_OUT: if (audio_is_idle()) g_state = ST_IDLE; break; } }

逻辑说明：key_pressed同时承担“手动触发进站”和“司机确认出站”两个作用；dist_to_stop由 GPS 坐标与站点坐标的球面距离算出来。音频播完用audio_is_idle()作为状态迁移信号，不引入额外定时器，避免音频和状态机各走各的时间基准。

这套状态机看着简单，实际上解决了实车上最大的毛病：声音还没播完就被下一次触发打断。所有触发都是先改状态位，播完当前音频才动下一步，司机连按三次按键也不会乱。距离阈值 80 米是我根据 GPS 精度和车速调出来的，车速 30km/h 时 80 米大约提前十秒触发，正好够播完一段提示音。

4.3 串口解析与播放调度：主循环怎么安排

GPS 数据是串口流，不能在主循环里直接阻塞读。我用一个环形缓冲区接收中断数据，再在主循环里按行解析。串口中断只做一件事：把字节放进环形缓冲：

#define RING_SIZE 256 static uint8_t g_ring[RING_SIZE]; static volatile uint16_t g_head = 0, g_tail = 0; void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_RXNE) != RESET) { uint16_t next = (g_head + 1) % RING_SIZE; if (next != g_tail) { g_ring[g_head] = USART_ReceiveData(USART1); g_head = next; } else { USART_ReceiveData(USART1); /* 缓冲区满则丢弃 */ } } }

环形缓冲的好处是中断里不解析 NMEA，只负责存字节，主循环每 100ms 调一次gps_parse_line()，从中抽以$开头、以换行结尾的完整帧，再判断是不是 $GPRMC。解析出来的经纬度是度分格式，必须转成小数。转换规则很直接：

static float convert_dm_to_decimal(float dm_value) { int degrees = (int)(dm_value / 100); float minutes = dm_value - degrees * 100; return degrees + minutes / 60.0f; }

比如 3112.3456，度是 31，分是 12.3456，转换后是 31 + 12.3456 / 60 ≈ 31.2058。N/S/E/W 的正负号要单独处理，我在解析函数里直接把南纬和西经取负，省得后面每个距离公式都判断一次。

播放调度上，VS1053 用 SPI 写音频数据，我在主循环里留一个高优先级片段专门检查 DREQ 引脚，只要 VS1053 请求数据就填充，填满就回状态机。SD 卡读取不放在这个片段里，而是提前把下一段音频读进一个双缓冲区，播放当前段时预读下一段，这样中间不会出现卡顿。

5. 避坑排查手册：实车调试中的五个典型故障

下面这五条是我在 1111 工程实车调试中真实碰到的问题，每条按现象、原因、解决三个环节记录。每一条都花过至少一个下午，有的甚至查了两三天。能留给后来人的经验，全在这五条里。

5.1 故障一：报站到一半突然哑声

现象：车辆正常行驶，播报前两三秒声音正常，然后突然断开，状态机停在“正在播放”的位置，只有断电重启才能恢复。

排查过程：一开始怀疑功放过热，摸 PAM8403 芯片温度正常；后来怀疑 VS1053 坏了，换新片仍然复现。最后用逻辑分析仪抓 SPI 总线，发现播放期间另一路外设任务和 VS1053 在抢同一个 SPI，数据断流超过 VS1053 缓冲区极限，解码器进入停机状态。表面像功放故障，实际是主控侧已经停止喂数据。

原因：SPI 总线被共用，没有互斥保护。播放音频时，另一个外设中途插了一脚片选，VS1053 拿不到连续数据流，直接停机。

解决：给 SPI 总线加互斥，播放音频期间禁止其他外设占用同一个 SPI 的片选。同时把 VS1053 的数据填充放到主循环最高优先级，SD 卡读取任务降级到低优先级。改完连续跑了一周，没有再出现哑声。

5.2 故障二：功放自激啸叫

现象：音量电位器超过 60% 时，喇叭出现持续高频啸叫，电流表读数明显波动，而且啸叫频率跟着发动机转速走，转速一高声音更尖。

排查过程：先怀疑是麦克风回授，把麦克风拔掉啸叫仍在；再用示波器看 PAM8403 电源引脚，发现上面叠加了明显的开关纹波，频率和 DC-DC 开关频率一致。对照 PAM8403 手册里的参考电路，发现我的去耦电容离芯片供电脚太远，输出电感的选型也不对。

原因：PAM8403 电源去耦不到位，DC-DC 纹波直接串进功放电源，高音量下形成振荡；输出滤波电感和电容的谐振点落在音频范围内，把振荡放大成了啸叫。

解决：在 PAM8403 供电脚贴 100nF 陶瓷电容和 100uF 电解电容，输出端换用 D 类功放官方推荐的电感磁珠组合，信号线改成双绞并远离电源线。这个故障之后我养成了一个习惯：功放部分的布局永远按手册给出的参考电路来，不自己发挥。

5.3 故障三：SD 卡初始化偶尔失败

现象：十次上电有两三次系统找不到 SD 卡，换另一张卡概率明显降低，看起来像玄学。

排查过程：在初始化代码里加打印，发现失败都发生在发 CMD0 之后没有等到空闲响应。用示波器量 SPI 时钟，发现初始化时我把 SPI 分频设成了 4，时钟超过 10MHz，远高于 SD 卡 SPI 模式规范要求的 400kHz。换新卡时卡内部上电快，侥幸通过；换老卡时上电慢，CMD0 直接被忽略。

原因：SD 卡 SPI 模式初始化时序要求在 400kHz 以下，我在系统时钟初始化完就用高速 SPI 去发命令，加上部分卡上电延迟长，握手失败。

解决：初始化阶段强制把 SPI 分频系数设为 256，STM32F103 主频 72MHz 时 SPI 时钟约 281kHz，符合规范。等卡返回空闲状态、ACMD41 握手成功后再切到分频 4。之后我在上电流程里固定走一遍sd_init_low_speed()，兼容性明显变好。

5.4 故障四：站名在调试屏上乱码

现象：stations.txt 在 PC 上打开完全正常，同一份文件放到 STM32 端解析后，第一个站名开头出现两个奇怪字符，后面所有站名整体错位。

排查过程：用十六进制查看器打开 SD 卡里的 stations.txt，发现文件头多了三个字节 EF BB BF。这三个字节是 Windows 记事本保存 UTF-8 时自动加上的 BOM，STM32 解析时把它当成了站名第一个字符。

原因：UTF-8 带 BOM 文件。记事本另存为时默认写 BOM，STM32 端 FatFS 不会自动跳过，于是一个站的错位导致整份配置解析失败。

解决：所有配置文件统一用 UTF-8 无 BOM 保存；STM32 端读取文件头时检测 BOM，如果存在就直接跳过前三个字节再开始解析：

/* 检测并跳过 UTF-8 BOM */ uint8_t tmp[3]; f_read(f, tmp, 3, &br); if (tmp[0] != 0xEF || tmp[1] != 0xBB || tmp[2] != 0xBF) { f_lseek(f, 0); /* 没有 BOM 就回到文件头 */ }

这个坑只踩过一次，但每次换电脑编辑配置文件时都有可能复发，所以我在 PC 端和 STM32 端都做了防护。

5.5 故障五：车辆点火瞬间系统复位

现象：公交车每次发动机点火，报站器屏幕都会闪一下重启，行驶中反倒是正常的。

排查过程：先用示波器抓 3.3V 电源轨，点火瞬间电压跌到 2.2V 左右，MCU 供电不足直接复位。再抓复位引脚，发现点火线圈的高频脉冲通过线缆耦合到复位引脚上，形成一串毛刺。两件事同时发生，复位难以避免。

原因：电瓶启动瞬间电压被起动机拉低，DC-DC 输出跟随跌落，3.3V 供电崩溃；同时点火线圈的高频脉冲耦合到复位引脚，让 MCU 复位。

解决：电源输入端加 TVS 管和 470uF 电解电容，DC-DC 换成输入范围更宽的 XL4015，复位引脚对地并联 100nF 电容、上拉电阻增大到 10kΩ，滤掉短脉冲。装车后做点火测试，连续二十次启动没有一次复位。

6. 进阶：音量自适应与报站日志验证

6.1 用 ADC 检测环境噪音并自动调整音量

实车音量是个很烦人的问题。白天嘈杂，喇叭声音调小了后排听不到；夜间安静，音量一高又吓人一跳。司机不可能一路转电位器，所以我在 1111 工程里加了一个简单方案：用板载驻极体麦克风采样环境噪音，通过 VS1053 的 SCI_VOL 寄存器动态调整输出音量。VS1053 的 0x0B 寄存器控制音量，高位字节是左声道、低位字节是右声道，0 为最大，每加 1 衰减 0.5dB。麦克风信号先经过一级运放放大，再进 STM32 的 ADC 通道采样，取一段窗口的 RMS 值作为噪音估计。

STM32 ADC 切换通道这里有实际教训：多通道顺序采样必须开 DMA 扫描模式，否则在中断里手动换通道，读到的第一个值还是上一个通道的残留。每次切换后要丢掉前四个样本再参与计算，我习惯采三十二个样本，去掉前四个，剩下的算 RMS。把 RMS 换算成 dB 后，按档位映射到音量寄存器：

uint8_t vol = VOL_HIGH; /* 基础音量，运行时按噪音换算 */ if (rms_db > 60) vol = VOL_HIGH; /* 嘈杂，开大 */ else if (rms_db > 45) vol = VOL_HIGH - 6; /* 中等，微调 */ else vol = VOL_HIGH - 12; /* 安静，收小 */ vs1053_write_vol(vol, vol);

这样写的好处是逻辑全在主循环里，不需要额外线程。播报开始前把音量设好，播放过程中不调整，避免音量跳变产生的爆破声。实测下来，同一段音频在白天和夜间的听感差别小了很多。

6.2 把报站事件写入 Flash，事后复盘

另一个让我受益很多的做法是写报站日志。每触发一次报站，就把时间戳、站号、触发来源——GPS 还是按键——写入内部 Flash 的日志区，循环覆盖保存最近 200 条。回场后通过串口导出，和当天录音对比。录音我用手机放仪表台，回来用语音转文本工具把录音转成文字，和站名表逐条比，哪一站漏报、哪一站错报一目了然。GPS 漂移、按键误触、配置文件写错，三种原因在时间线上完全对得上。

这次 1111 工程前后改了四版固件，最大的教训是：报站系统的坑很少出在算法上，大部分出在电源、地线和编码。从那以后我每次装车都强制走一遍验证流程——反复断电上电十次、把 SD 卡换成不同品牌各跑一遍、实车播报录下来和站名表逐条比对。希望帮到你。

本文还有配套的精品资源，点击获取