简介：基于STM32微控制器的孤立词语音识别项目，面向嵌入式系统开发者、物联网方向学生及语音识别入门者，演示了在单片机资源受限环境下完成关键词指令控制的基本路径。资源共165个文件，以53个C源文件与50个头文件为核心，另含13个音频样本、编译下载配置、日志与备份等，压缩包整体约2.03MB，下载和部署都较为轻量。项目覆盖音频采集、预处理、特征提取、模型匹配与识别反馈等步骤，涉及MFCC特征和HMM等经典算法，对理解嵌入式端的语音信号处理很有帮助。已有331人学习浏览，适合希望结合ARM Cortex-M、C语言动手实践，或准备在IoT设备中加入语音交互能力的开发者参考。读者可对照源码理清从麦克风输入到识别结果输出的完整数据流，也可在此基础上进一步训练模型以适配更多指令词。
1. 把孤立词识别塞进STM32，先别急着跑代码
第一次拿到这份stm32-speech-recognition-master工程时，我以为是某个开发板厂商的 Demo，打开才发现是一套基于 STM32F103 的完整孤立词语音识别实现。所谓孤立词识别，就是识别“开灯”“关灯”“前进”这种独立词汇，而不是连续对话流。这类方案在智能家居、车载语音按键、安防门禁里很常见，核心价值在于不依赖云端、不依赖 WiFi，一颗几块钱的单片机加一个 MIC 电路就能完成关键词检测。
有意思的是，这套工程的源码结构带着明显的“从 MATLAB 原型移植过来”的痕迹——speech_recog.asv、teat.asv、STM32_Voice.asv这些 ASV 后缀文件是 MATLAB 编辑器自动保存的备份，语音识别_uvproj.bak是 Keil 工程备份。也就是说，作者先在 PC 端用 MATLAB 验证了识别算法，再把定点化后的代码移植到 STM32 上跑。这条开发路径本身就很值得学习：嵌入式语音识别的难点不是算法本身，而是精度、算力、内存三者之间的平衡。
适合谁看？如果你在做 STM32 项目，想给设备加一个离线语音控制能力，或者你在学语音识别但不想碰 Linux 和树莓派，这份工程能帮你把“音频采集 → 预处理 → 特征提取 → 模板匹配”整条链路串起来。接下来我从文件结构、采集链路、特征匹配、工程排错四个维度拆解这套代码，最后一章给出两个可以直接抄的二次开发技巧。
2. 工程文件架构与音频采集链路：ASV、BAK 和 ADC 的关系
2.1 先读懂这套工程的“出身”
拿到压缩包后，别急着双击uvproj文件，先把根目录下的文件过一遍。.asv后缀的文件是 MATLAB Editor 的自动保存备份，.bak后缀是 Keil 在编译前对原工程配置做的快照。speech_recog.asv和teat.asv这两个文件说明作者在 PC 端做了大量算法仿真，真正烧进单片机的只是 Matlab 原型中能够在定点 MCU 上跑起来的那一部分。
after-compile.bat是 Keil MDK 的后编译脚本，常见做法是在编译完成后把生成的 hex/bin 文件拷贝到指定目录，或者调用 Python 脚本做固件签名、deepsleep 模式切换、固件合并。这个文件的存在说明作者有批量生产或频繁烧录调试的习惯。建议你打开看一眼具体内容，能直接反推作者的工作流。
2.2 STM32 的音频采集链路：从 MIC 到 SRAM
语音识别的前端是音频采集。这套工程基于 STM32F103，它内部集成了 3 个 12 位 ADC，采样率最高可以跑到 1 MHz 左右。但音频采样不需要这么高的速率，语音识别常用的采样率是 8 kHz 或 16 kHz，8 kHz 采样率下 12 位精度足够覆盖语音的动态范围。
采集链路的典型配置如下：
// ADC1 初始化 - 使用定时器触发采样，保证采样间隔一致 void Audio_ADC_Init(uint32_t sample_rate) { ADC_InitTypeDef ADC_InitStructure; TIM_TimeBaseInitTypeDef TIM_TimeBaseStructure; // 使能 ADC1 和定时器2 的时钟 RCC_APB2PeriphClockCmd(RCC_APB2Periph_ADC1, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE); // 此处以 8kHz 采样率计算定时器分频，72MHz 主频 // 72MHz / (prescaler+1) / (period+1) = 8000 TIM_TimeBaseStructure.TIM_Prescaler = 71; // 分频到 1MHz TIM_TimeBaseStructure.TIM_Period = 124; // 1MHz / 125 = 8kHz TIM_TimeBaseStructure.TIM_ClockDivision = 0; TIM_TimeBaseInit(TIM2, &TIM_TimeBaseStructure); // 关键：ADC 采样由 TIM2 的 TRGO 事件触发 TIM_SelectOutputTrigger(TIM2, TIM_TRGOSource_Update); ADC_InitStructure.ADC_Mode = ADC_Mode_Independent; ADC_InitStructure.ADC_ExternalTrigConv = ADC_ExternalTrigConv_T2_TRGO; ADC_InitStructure.ADC_ExternalTrigConvState = ENABLE; ADC_Init(ADC1, &ADC_InitStructure); ADC_Cmd(ADC1, ENABLE); TIM_Cmd(TIM2, ENABLE); }这段代码的核心思路是用定时器触发 ADC 采样，而不是用 while 循环轮询。原因很简单：语音信号是时域连续信号，采样间隔必须严格均匀，否则后续的分帧、加窗和特征提取都会引入相位失真。用定时器硬件触发，CPU 可以在采样间隙处理其他任务，比如刷新 LED 或者扫描按键。
实际用这套配置时，注意 MCU 主频和分频系数的关系。如果换了外部晶振，比如从 8 MHz 换成 12 MHz，72 MHz 主频会变化，定时器分频参数要重新计算，否则采样率偏移会导致模板匹配失败。很多人在移植时遇到“在 A 板子上能识别，换 B 板子就不行”，大概率是采样率漂移造成的。
2.3 音频数据的存储策略：环形缓冲区与 DMA
ADC 连续采样会产生持续的数据流，如果每采一个样本就进一次中断，CPU 会被大量打断。常见做法是 DMA + 环形缓冲区配合。STM32F103 的 ADC1 支持 DMA 请求，可以把转换结果直接搬运到内存，半传输和全传输各触发一次中断。
// 双缓冲区：前半部分填满中断一次，后半部分填满中断一次 #define AUDIO_BUF_SIZE 512 volatile uint16_t audio_buf[AUDIO_BUF_SIZE]; void Audio_DMA_Init(void) { DMA_InitTypeDef DMA_InitStructure; RCC_AHBPeriphClockCmd(RCC_AHBPeriph_DMA1, ENABLE); DMA_InitStructure.DMA_PeripheralBaseAddr = (uint32_t)&ADC1->DR; // 外设地址固定 DMA_InitStructure.DMA_MemoryBaseAddr = (uint32_t)audio_buf; // 内存地址 DMA_InitStructure.DMA_DIR = DMA_DIR_PeripheralSRC; // 外设到内存 DMA_InitStructure.DMA_BufferSize = AUDIO_BUF_SIZE; DMA_InitStructure.DMA_PeripheralInc = DMA_PeripheralInc_Disable; DMA_InitStructure.DMA_MemoryInc = DMA_MemoryInc_Enable; // 内存地址递增 DMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_HalfWord; DMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_HalfWord; DMA_InitStructure.DMA_Mode = DMA_Mode_Circular; // 循环模式 DMA_InitStructure.DMA_Priority = DMA_Priority_High; DMA_Init(DMA1_Channel1, &DMA_InitStructure); // 使能 DMA 传输完成中断 DMA_ITConfig(DMA1_Channel1, DMA_IT_TC, ENABLE); }这个缓冲区大小 512 点，在 8 kHz 采样率下对应 64 ms 的音频长度。孤立词一般持续 300 ms 到 1 秒，所以端点检测算法会判断“语音开始”和“语音结束”，把有效段截取出来。AUDIO_BUF_SIZE的选择影响检测延迟和内存占用，F103 的 SRAM 只有 20 KB（型号不同有差异），缓冲区太大程序会溢出，太小则容易丢数据。
3. 孤立词特征提取与模板匹配：MFCC 之外的选择
3.1 预处理：预加重、分帧、加窗与端点检测
原始语音信号采集进来之后，不能直接去做匹配。首先是预加重，用一个一阶高通滤波器提升高频分量，因为语音信号的高频能量通常较低，而高频部分包含大量辅音信息。常见系数是 0.97 左右：
// 预加重：y[n] = x[n] - 0.97 * x[n-1] void PreEmphasis(int16_t *data, uint32_t len) { for (uint32_t i = len - 1; i >= 1; i--) { data[i] = data[i] - 0.97f * data[i-1]; } }然后是分帧和加窗。语音信号是短时平稳的，10 ms 到 30 ms 的片段内频谱特征相对稳定，所以把长信号切成帧，每帧 20 ms 左右，帧移 10 ms 保证帧与帧之间有重叠。每一帧乘一个汉明窗，消除帧边界处的频谱泄漏。
端点检测（VAD）是孤立词识别里最影响体验的一环。用短时能量和过零率双门限法，先设定一个较高的能量阈值检测语音起点，再设定一个较低阈值向前回溯，避免把词首的弱辅音切掉。
// 双门限端点检测：返回语音段的起止帧索引 void VoiceActivityDetect(int16_t *data, uint32_t len, uint32_t *start, uint32_t *end) { // 分帧，每帧 160 点（20ms @ 8kHz），帧移 80 点 // frame_energy = sum(x[i]^2) / frame_len // frame_zcr = sum(|x[i]| - |x[i-1]| > 0 ? 1 : 0) 的一半 // 语音段的条件：能量高于低门限 且 （能量高于高门限 或 过零率高于门限） // 实际工程中，这里会根据连续 N 帧满足条件才判定语音开始/结束 // N 通常取 3~5，防止突发噪声误触发 }端点检测的参数需要根据实际环境调整。安静办公室和工厂车间的底噪差异很大，固定阈值必然出问题。工程里一般会加一个环境噪声估计的模块，在系统启动后前 1 秒采集背景噪声，动态抬高或压低门限。
3.2 特征选择：MFCC 与 DTW 的组合逻辑
几十年来孤立词识别最主流的特征一直是 MFCC（梅尔频率倒谱系数）。它模拟人耳对不同频率的非线性感知特性，把频谱映射到 Mel 刻度上，再做 DCT 压缩。每帧提取 12 到 13 维 MFCC 系数，加上一阶差分特征，就能比较完整的描述这一帧的语音内容。
但在 MCU 上算 MFCC 需要面对两个问题：浮点运算能力和内存。STM32F103 没有硬件 FPU，所有浮点运算都要编译器用软浮点模拟。MFCC 内部要算 FFT、Mel 滤波器组、log、DCT，运算量相当可观。内存方面，一帧 512 点的 FFT 需要两个 512 点的浮点数组，加上滤波器组系数、DCT 矩阵，SRAM 可能直接告急。
工程里采用的方案是简化版 MFCC + 定点化。把 FFT 换成定点版本，滤波器组输出做定点缩放，DCT 矩阵预先计算好存到 Flash，运行时只做乘加。这样精度损失有限，但运算速度能提升到可以接受的水平。
匹配阶段用的是 DTW（动态时间规整）。孤立词识别的核心难点是同一个人说同一个词，每次的语速都不可能完全一致。DTW 通过动态规划对齐两个特征序列的时间轴，找到最小累积距离。DTW 最大优势是不需要训练模型，每个词只要录几遍模板存起来，匹配时算距离就行，非常适合 MCU 场景。
// DTW 距离计算（简化版）：local_dist[i][j] 为欧氏距离 // 累积距离 D[i][j] = local_dist[i][j] + min(D[i-1][j], D[i][j-1], D[i-1][j-1]) // 边界条件：D[0][0] = local_dist[0][0] // 约束：i 和 j 的偏差不超过 MAX_WARP_WINDOW，防止过度扭曲 float DTW_Distance(float *feat1, uint32_t len1, float *feat2, uint32_t len2) { // 分配两个长度为 len2+1 的数组，滚动更新累积距离 // 只计算 |i-j| < MAX_WARP_WINDOW 的区域，减少无效计算 // 归一化：最终距离除以 (len1 + len2)，确保不同长度序列之间可比 }注意这里说的“模板”不是训练出的模型，而是提前录制并提取好特征序列的关键词样本。你可能需要录 5 到 10 遍同一个词作为模板，取距离最小值为匹配结果。
3.3 模板训练流程：在 MATLAB 里完成，在 MCU 上验证
这套工程的模板是离线生成的。建议的流程是：录好语音 → MATLAB 里做同样的预加重、分帧、MFCC 提取 → 把特征序列导出成 C 数组 → 烧进 STM32 的 Flash。这个过程相当于把“训练”放到了 PC 上，MCU 上只做“识别”，极大降低了对 MCU 算力的要求。
有个容易踩的坑：MATLAB 里的浮点 MFCC 和 MCU 上的定点 MFCC 计算出的特征会有细微差异。如果直接用 MATLAB 提取的特征做模板，MCU 端提取的特征做匹配，两者叠加的系统误差有时会让 DTW 距离偏大。解决方法是把 MATLAB 脚本改成与 MCU 完全相同的定点计算，或者用 MCU 提取的特征作为模板入库。
4. 从 .bak 到能烧录：工程恢复与常见报错排错路径
4.1 Keil 工程修复：.bak 文件的正确打开方式
语音识别_uvproj.bak是 Keil 5 工程的备份。直接双击大概率打不开，因为 Keil 识别的是.uvprojx后缀。处理方法很简单：
# 在项目根目录下执行 cp 语音识别_uvproj.bak 语音识别.uvprojx cp 语音识别_uvopt.bak 语音识别.uvoptx然后双击新的.uvprojx文件。提示找不到芯片时，检查 Keil 是否安装了 STM32F1 系列器件包。打开工程后如果提示找不到某个头文件，很可能是分组里的文件路径是绝对路径，换电脑后失效。在 Options for Target → C/C++ → Include Paths 里重新指定源码目录即可。
4.2 编译烧录：Flash 下载算法与启动文件
F103 的程序区从0x08000000开始，Keil 默认会设置正确的 Flash 起始地址。下载时如果报No ULINK Device found或者Cannot access target，先确认三件事：调试器选的是 ST-Link 还是 J-Link、接线是否正确（SWDIO、SWCLK、GND、3V3）、目标板供电是否正常。
工程里出现的stm32f10x_flash.c和stm32f10x_tim.c是标准外设库的一部分。如果你重新建工程，注意 F103 的标准外设库版本要和编译器的 C99 模式兼容，Keil 5 里需要在 C/C++ 选项卡勾选C99 Mode。
4.3 硬件排查：麦克风电路与信号幅度
代码层面全对，但识别率极低，大概率问题出在模拟前端。STM32 ADC 的输入范围是 0 到 3.3V，而驻极体麦克风输出的是叠加在直流偏置上的交流小信号，幅度只有几十毫伏。必须经过放大电路把信号抬升到 ADC 能分辨的范围。
常见电路是 MIC → 隔直电容 → 偏置电阻 → 运放放大（如 LM358、MAX9814）→ ADC 输入。重点是让静态工作点稳定在 1.65V 附近，这样交流信号能在 0 到 3.3V 之间摆动。如果信号幅度过小，ADC 采样出来的波形是一条直线，预处理和特征提取全部失效。
// 检查 ADC 采集到的信号是否正常 // 正常语音信号的标准差应大于设定的环境噪声阈值 uint32_t CalcSignalStd(uint16_t *samples, uint32_t len) { uint32_t sum = 0, sum_sq = 0; for (uint32_t i = 0; i < len; i++) { sum += samples[i]; sum_sq += (uint32_t)samples[i] * samples[i]; } // 近似计算方差 = E[x^2] - (E[x])^2 // 判断标准差低于阈值则静音，让用户重录 }4.4 运行期崩溃：HardFault 的常规排查
MCU 在跑识别算法时突然进入HardFault_Handler，优先检查三个点。第一，DTW 的累积距离数组是否越界，特别是滚动数组的索引计算在边界条件处是否溢出；第二，FFT 的旋转因子表是否放在 Flash 而不是 SRAM，F103 的 SRAM 有限，大数组放栈里会溢出；第三，ADC 的 DMA 中断优先级和算法主循环是否存在资源竞争，如果算法在算 DTW 时 DMA 中断把某个共享缓冲区覆盖了，数据就会被破坏。
提示：工程里如果同时使用了 FreeRTOS，DMA 中断服务函数里不能直接调用可能阻塞的 API，应该使用
xQueueSendFromISR这类带 FromISR 后缀的接口。
5. 二次开发的三个落地技巧：改词库、加命令、换硬件
5.1 技巧一：用脚本批量生成 C 语言特征模板
手工把 MATLAB 计算出的 MFCC 特征一个个复制成 C 数组效率太低，而且容易出错。更好的做法是写一个脚本自动读取特征文件并生成头文件：
# 提取MFCC特征并生成C头文件 import numpy as np def mfcc_to_c_array(mfcc_feat, word_name): """把MFCC特征矩阵转成C语言二维数组定义""" frames, dims = mfcc_feat.shape header = f'/* {word_name} 模板，{frames}帧 x {dims}维 */\n' header += f'const float template_{word_name}[{frames}][{dims}] = {{\n' for i in range(frames): row = ', '.join([f'{v:.4f}f' for v in mfcc_feat[i]]) header += f' {{{row}}},\n' header += '};\n\n' return header这个脚本的意义在于把“新词入库”的流程标准化了。你要是想加一个“暂停”指令，只需要录几遍音频，跑一遍特征提取，脚本自动生成模板数组，然后在识别引擎的匹配列表里加一个对应关系，重新编译即可。模板存放在 Flash 里，F103 的 Flash 够几百个词的模板。
5.2 技巧二：多说几遍取均值，降低模板偶发性
孤立词模板的质量直接决定识别率。同一个词录五遍，每一遍的 DTW 距离都会因为发音差异而不同。常见做法是录制时对同一个词采集多次，把特征序列做时间轴归一化后取逐维均值，生成一个“平均模板”。这样做的代价是模板数量没法做到一音一模板，但能显著提升关键指令的稳定性。
另一种做法是多个模板投票：同一词录三遍作为三个独立模板，识别时分别计算距离，取最小距离对应的模板结果。三种模板的结果一致则输出，不一致则判为“无法识别”。这种做法对麦克风位置变化、环境噪声波动都有更强的鲁棒性，代价是匹配时间翻三倍。
5.3 技巧三：识别结果的动作映射与状态机集成
孤立词识别最终要落到动作上。工程里 STM32 作为主控，识别到“开灯”之后要拉高 GPIO、通过串口发指令控制外部设备，或者走 Modbus 协议与变频器通讯。常见对接方式是建立一个简陋的“意图映射表”：
// 识别结果到动作的映射表 // 前端用状态机控制识别流程，空闲时等待关键词，识别成功后执行动作再回到空闲 typedef struct { uint8_t command_id; // 命令字 void (*action)(void); // 动作回调 } CommandEntry; // 例：识别到"开灯" -> 执行 Light_On // 识别到"关灯" -> 执行 Light_Off // 如果识别结果为"未知"，保持上一个状态不变，并给出语音提示把识别引擎和业务动作解耦，后续换掉识别算法或者更换设备类型时，功能代码几乎不用动。这个映射表的思路在处理 Modbus 通讯、电机驱动等外设控制时非常实用，识别结果不直接操作硬件，而是通过回调交给任务层处理，方便排查问题。
同时要注意识别到结果后的去抖动。用户说了一次“开灯”，系统连续识别出多次“开灯”，导致灯反复开关。常见做法是在执行完动作后进入一个 2 到 3 秒的锁定窗口，窗口期内忽略所有识别结果，配合 LED 指示灯提示用户“指令已生效”。这种细节才是嵌入式语音识别产品能落地和只能跑 Demo 的区别所在。
本文还有配套的精品资源，点击获取
