内容介绍

摘要

本项目面向“关键词唤醒与命令词识别”入门级任务，在MAX32690评估套件上实现一套完整的离线语音命令系统。系统通过板载MAX9867音频编解码器从J5线性输入接口采集电脑播放的语音，使用I 2S与DMA连续获得48 kHz双声道数据，在微控制器端完成单声道合并、3:1抽取、直流分量去除、动态门限语音活动检测（VAD）、Log-Mel特征提取以及轻量级多层感知机（MLP）推理。系统支持“开灯”“关灯”“前进”“停止”四个命令词，识别结果同步输出到板载TFT、LED、UART串口和Bluetooth Low Energy（BLE）Notify通道，所有计算与决策均在MAX32690本地完成，不依赖网络或云端服务。为了使测试可复现，项目构建了4类、每类20条、共80条的多音色TTS测试集，并开发基于Python本地HTTP服务、Web Audio和Web Bluetooth的电脑测试台。上位机可选择并播放语音、连接名为Periph的开发板、接收带事件号和置信度的BLE通知，并将期望类别与实际类别自动对应。针对初始版本存在的漏识别、静音误触发以及延迟通知串入后续测试等问题，项目依次完成真实硬件特征回灌、VAD状态机约束、双阈值判决、事件号/测试号关联和隐藏层宽度比较。最终真实模拟音频链路验证中80条样本全部正确，四类均达到20/20，最低置信度为89%；120秒静音监听未出现接受或拒绝事件。固件占用Flash 419,928 B（12.38%）和SRAM 97,836 B（9.33%），保留了充分资源余量。实验表明，该方案能够在资源受限的嵌入式平台上同时兼顾识别准确性、实时性、可复现测试和多通道交互，满足题目对3–5个离线关键词、500 ms以内响应以及外设控制/BLE输出的要求。关键词：MAX32690；离线关键词识别；MAX9867；Log-Mel；MLP；Bluetooth Low Energy；嵌入式机器学习

1 选择完成的任务

1.1 所选题目

本项目选择电子森林活动中的入门级题目2：关键词唤醒与命令词识别。题目要求使用板载音频输入接口或外接PDM麦克风，实现3–5个预设关键词的离线识别，识别响应延迟控制在500 ms以内，并控制LED、电机或发送BLE控制指令。结合MAX32690官方套件的板载资源，本项目最终选择“开灯”“关灯”“前进”“停止”四个中文命令词，使用MAX9867与J5 LINE_IN采音，以板载LED、 TFT、UART和BLE作为结果出口。实现范围既覆盖题目的全部强制指标，也增加了手机BLE回环、电脑网页上位机、事件关联和全量自动测试等便于验收的功能。

1.2 任务背景

关键词唤醒（Keyword Spotting, KWS）是在连续音频中检测少量预设词的技术。与完整语音识别相比，KWS的词表更小、延迟要求更严格，同时经常运行在功耗、存储空间和计算能力受限的终端。典型应用包括智能灯具的“开灯/关灯”、小车的“前进/停止”、耳机唤醒词以及工业设备的免接触控制。小型神经网络已经被证明能够在有限算力平台上实现有效的关键词识别[? ]，而其工程难点不仅是离线分类器本身，还包括稳定的音频采集、环境噪声抑制、实时分段、结果去重和控制链路。本项目以MAX32690评估套件为核心。该器件包含120 MHz Arm CortexM4F、 3.25 MB片上Flash、 1 MB SRAM、 I 2S、 DMA及Bluetooth 5.2 Low Energy无线电，资源规模适合实现轻量级音频推理与无线反馈。评估板同时集成MAX9867超低功耗立体声音频编解码器，支持8–48 kHz ADC/DAC、立体声线性输入、耳机输出和I 2S数字音频接口，可以构成“模拟输入、数字采集、本地推理”的完整链路。

1.3 需求分解

根据题目要求和实际演示条件，将系统目标拆分为表 1中的六项。这里将“响应延迟”定义为一个命令词有效语音结束到板端给出识别事件的时间，而audio=420 ms等日志字段表示VAD截取的有效语音窗口长度，不等同于推理耗时。

表 1 项目需求及对应验收方法

1.4 最终功能边界

系统不做连续中文句子识别，也不依赖操作系统级语音API。其输入是自然停顿分隔的短命令，输出是四个离散类别或REJECTED。上位机仅承担测试音频播放、BLE显示和记录整理，不参与板端分类。因此即使电脑端网页关闭，开发板仍然能够通过J5接收音频，并在TFT、LED和串口上独立给出结果。

图 1 系统最终验证指标摘要

2 项目描述：系统整体架构

2.1 端到端架构

系统由测试音源、模拟音频链路、板端实时识别和多通道结果输出四部分组成。电脑端从80条TTS语音中选择文件并通过耳机/声卡输出； 3.5mm双公头线将信号送入J5 LINE IN；MAX9867完成模数转换，MAX32690通过I 2S与DMA获取PCM数据；随后依次执行重采样、VAD、特征提取、MLP推理和阈值判决。通过判决的命令会同步更新LED、TFT、UART和BLE。真实硬件链路如图 2所示。

图 2 从TTS音频到多通道结果的真实硬件测试链路

2.2 方案选择

项目早期比较过模板匹配、传统分类器和神经网络三类方案。直接波形模板匹配实现简单，但对说话速度、音色、模拟链路增益和起止位置非常敏感；基于手工统计量的分类器资源小，却难以表达四个近长度词语之间的频谱差异；小型MLP能够以固定矩阵乘法完成推理，并可借助数据增强覆盖一定的音色和增益变化。因此最终采用“Log-Mel固定前端+单隐藏层MLP”的结构。相比卷积网络，该结构更容易在本项目有限数据集上训练、导出和逐项核对，也使固件中的权重布局与PC端训练脚本保持直观一致。

2.3 系统数据流与控制流

数据流以10 ms为一个处理块。DMA回调只负责交付新音频块，主循环消费音频并维护VAD状态；当一段语音结束时，识别模块计算特征并推理，随后生成一个单调递增的事件号。输出层读取统一的结果结构体，保证UART、BLE、TFT和LED使用同一类别与置信度。BLE协议额外携带网页测试号，使迟到通知不会错误地匹配到下一条测试样本。

图 3 工程源码模块及其关系

3 硬件平台简介

3.1 MAX32690核心资源

MAX32690的Cortex-M4F支持单精度浮点运算，能够直接执行频谱、对数和全连接网络计算。芯片提供16通道DMA、I 2S、UART、I 2C和集成BLE无线电。本项目的主要资源分配如下：

I 2C用于配置MAX9867寄存器，JP9连接SDA，JP10连接SCL；
I 2S和DMA用于连续接收48 kHz双声道PCM；
UART通过CN2映射为电脑COM6，参数为115200、8-N-1；
BLE使用J1连接2.4 GHz鞭状天线；
板载TFT显示类别、概率及状态，板载LED表示命令动作；
DAPLink经SWD完成CFS下载与调试，CN2可同时承担供电和串口输出。

3.2 MAX9867音频接口

MAX9867提供立体声线性输入、ADC、数字滤波和I 2S/TDM兼容总线。项目将电脑声卡输出接入J5 LINE IN，并将编解码器设置为48 kHz、 16位、双声道采集。早期的 “耳机回环” 程序用于确认模拟输入、 I 2S接收和J6 HD_PHONE输出链路，排除线路、采样率和时钟配置问题；链路稳定后再叠加KWS与BLE功能。该分阶段方法避免在识别异常时同时怀疑硬件、驱动和模型。

3.3 实物连接

图 14为最终实验接线：上方J5连接电脑音频输出，J1安装2.4 GHz天线，CN2通过Micro-USB连接电脑并提供串口/电源，DAPLink排线连接SWD接口。TFT已经显示识别到的STOP及概率，说明音频、推理和显示链路同时工作。为满足总结报告对实物展示的要求，完整开发板照片与各接口说明统一放在第 10节，并与CodeFusion Studio烧录截图、网页测试台截图共同构成可核验的演示证据。

表 2 最终演示连接检查表

4 方案框图与设计思路

4.1 分层设计方案

本项目没有把“采音、识别、显示和蓝牙”写成一个不可拆分的大程序，而是按照输入层、信号处理层、推理决策层、事件层和输出层进行分层。系统框图见图 2，软件模块关系见图 3。输入层只负责稳定取得PCM；信号处理层只负责把不同长度、不同增益的语音变换为统一特征；推理决策层只输出类别概率和是否接受；事件层为每次结果分配唯一编号；输出层才驱动TFT、LED、UART和BLE。这样的边界使各模块能够独立验证，也使后来定位音频卡顿、静音误触发和BLE迟到事件时不必同时修改全部代码。

表 3 总体方案的功能分层与验证出口

4.2 核心设计取舍

第一，识别必须真正离线运行，因此电脑只承担测试音源和结果观察，不参与特征计算或分类。第二，测试必须经过真实模拟链路，因此不能只用Python读取WAV后直接送入模型；声卡、连接线、MAX9867、I 2S和板端重采样都必须进入验证范围。第三，实时性优先采用连续DMA和非阻塞状态机，而不是在一次识别过程中停止采样。第四，准确率优化优先解决训练域与硬件域差异，不通过简单降低阈值换取表面召回率。第五，多通道输出共用一份事件对象，避免TFT、UART和BLE各自重新判断而产生结果不一致。

从算法复杂度看，384维Log-Mel加单隐藏层MLP比波形模板匹配更能适应音色、增益和语速差异，又比大型卷积网络更容易在本项目80条测试语音和微控制器资源范围内训练、解释与部署。最终Flash和SRAM占用都低于13%，说明所选方案不仅能够运行，而且为增加真人语音、未知词负样本、简单电机控制或量化模型保留了空间。

5 原理图与PCB设计说明

5.1 原理图功能链路

本作品直接使用MAX32690官方评估套件，没有另行设计或投板自制PCB，因此报告不虚构自制原理图、Gerber或PCB版图。硬件设计工作主要是依据官方评估板原理图确认已有器件之间的连接，并在跳线、接口和软件外设复用层面完成系统配置。核心信号链为：J5 LINE IN的左右模拟声道进入MAX9867ADC；MAX32690通过I 2C配置MAX9867寄存器，通过I 2S接收数字音频；CN2提供USB供电和UART桥接； DAPLink通过SWD下载固件； BLE射频信号由J1 SMA与2.4 GHz天线辐射；识别结果则由板载TFT和LED直接显示。

表 4 基于官方评估板原理图确认的关键网络

5.2 未进行自制PCB的原因与边界

题目允许使用官方套件完成入门级关键词识别，且评估板已经集成MCU、音频编解码器、显示屏、 LED、调试接口、电源和射频匹配网络。重复设计PCB不仅会引入电源完整性、高速数字音频、模拟地噪声和2.4 GHz射频阻抗等额外风险，也不会直接提升本题的核心评价指标。因此项目把精力集中在真实音频链路、离线算法、实时固件和可复现测试上。若后续制作专用控制板，原理图应至少保留模拟/数字地分区、MAX9867电源去耦、I 2S等长与串扰控制、50 Ω射频走线、天线净空以及SWD/UART测试点；PCB部分则需在投板后重新进行音频底噪、射频距离和EMC验证。

6 音频采集与预处理

6.1 DMA连续采集与重采样

音频入口为48 kHz双声道PCM。对第n个双声道采样 $L [n]$ 和 $R [n]$ ，先计算单声道样本

$x [n] = \frac{L [ n ] + R [ n ]}{2} .$

然后按3:1抽取到16 kHz，使1秒音频由48,000个单声道采样降为16,000个。每160个16 kHz样本组成10 ms处理块。选择16 kHz是因为四个中文命令的主要语音信息集中在8 kHz以下，同时可以显著降低FFT、Mel滤波和缓存开销。

为防止声卡直流偏置影响能量门限，每块先计算均值

$μ = \frac{1}{N} \sum_{n = 0}^{N - 1} x [n], \overset{x}{^} [n] = x [n] - μ .$

实际程序在整数域完成双声道平均和块均值去除，在特征计算阶段转换为浮点数。

6.2 动态门限VAD

单纯使用固定峰值门限会产生两个问题：音量较低时漏检，安静环境中的线路毛刺又可能误触发。项目使用随背景更新的噪声基线Enoise，以块峰值/平均绝对幅度为主要判据。起始门限和结束门限分别为

$T_{s t a r t} = max (200, 5 E_{n o i se}),$

$T_{e n d} = max (180, 2.5 E_{n o i se}) .$

连续3个10 ms块超过Tstart才进入录音状态；语音结束后保留100 ms预卷数据，避免切掉声母。一个有效窗口还必须满足峰值不低于max(300, 6Enoise)、至少6个活跃块、总采样数不少于3,200。超过11,200个采样（700 ms）的窗口视为异常拼接并拒绝，24,000个采样（1.5 s）是硬上限。

图 4 板端音频预处理和关键词识别流水线

6.3 静音误触发治理

最初的VAD只要出现短时峰值就可能形成语音窗口，15秒静音监听曾接受2次伪命令。最终版本增加连续起音、有效活跃块、峰值/噪声比、最长有效窗口和双阈值分类约束。120秒静音监听结果为KWS事件0次、接受0次、拒绝0次，说明线路背景不再进入分类阶段。对“无声音也识别”的问题，优先在VAD入口阻断比单纯抬高分类置信度更合理，因为后者可能同时降低真实关键词召回率。

图 5 静音误触发优化前后对比

7 特征提取与神经网络模型

7.1 Log-Mel特征

Mel频率尺度通过

$m (f) = 2595 lo g_{10} (1 + \frac{f}{700})$

近似人耳对频率的非线性感知。项目对VAD窗口执行预加重、分帧、窗函数、实FFT、功率谱、Mel三角滤波和对数压缩。每条语音最终得到24个时间帧、每帧16个Mel频带，即24 × 16 = 384维特征。为减小不同音量和模拟链路增益造成的整体偏移，每个频带还执行均值/尺度归一化。经典语音特征研究表明，频谱包络及其感知尺度表示能够有效表达语音差异。

特征计算使用CMSIS-DSP的基础数学与变换能力。CMSIS-DSP为CortexM/A处理器提供经过优化的常用信号处理函数[? ]，减少自行实现FFT和向量运算的风险。本工程启用版本1.16.2，并在最终构建日志中保留版本信息。

7.2 MLP结构与推理

模型为单隐藏层多层感知机：输入384维，隐藏层64个ReLU单元，输出4个Softmax概率。其计算为

$h = max (0, W_{1} x + b_{1}), z = W_{2} h + b_{2}, p_{i} = \frac{e ^{z_{i} - z_{ma x}}}{\sum _{j} e ^{z_{j} - z_{ma x}}} .$

其中减去zmax用于提高Softmax数值稳定性。参数总量为384×64+64+64×4+4 = 24, 900，按32位浮点存储约97.3 kB，与MAX32690片上Flash/SRAM能力相匹配。神经网络的训练、激活函数和Softmax原理可参考文献。

图 6 384–64–4轻量级MLP网络结构

7.3 双阈值判决

仅检查最大概率会在两个类别都很接近时产生不可靠输出，因此采用“绝对置信度+第一、第二名差值”双阈值：

$accept = (p_{(1)} \geq 0.72) \land (p_{(1)} - p_{(2)} \geq 0.20) .$

不满足条件则输出REJECTED，不会触发LED动作。最终80条测试的最低置信度为89%，明显高于72%门限，说明门限并非通过牺牲边界样本强行获得100%准确率，而是与最终模型保留了至少17个百分点的安全余量。

7.4 训练数据与增强

测试集包含 “开灯、关灯、前进、停止” 各20条，共80条语音，覆盖Xiaoxiao、Xiaoyi、Yunjian、Yunxi、Xiaobei、Xiaoni、Yunxia和Yunyang等音色。训练阶段在原始语音上施加增益、轻微时移、噪声和速度扰动，同时将前两轮真实硬件测试中导出的384维特征回灌训练。这样模型不仅学习数字音频文件，也学习电脑声卡、3.5 mm线缆、MAX9867 ADC、重采样及定点预处理共同造成的域偏移。

图 7 四类关键词样本和TTS音色构成

7.4 训练数据与增强

分别训练32、48、64单元的MLP后，PC留出集均可获得160/160正确，硬件原始特征也均达到99/99，但最低胜出概率差异明显。64单元模型在PC留出集和板端真实特征上的最低胜出概率分别为88.62%和93.54%，均高于另外两种规模，因此最终选择64单元。选择依据不是只看平均准确率，而是关注最困难样本与决策边界的距离。

图 8 不同MLP隐藏层宽度的稳定性比较

8 软件流程、调试工具与关键代码说明

8.1 软件总体流程

板端软件从上电开始依次初始化时钟、 UART、 TFT、 LED、 I 2C、MAX9867、 I 2S/DMA和BLE协议栈，随后进入非阻塞主循环。主循环的最高优先级是及时消费DMA音频块；BLE协议事件、显示刷新和串口报告均以短任务方式穿插运行。当VAD判定一段语音结束后，才进行Log-Mel与MLP推理，并把接受或拒绝结果封装为统一事件。完整流程如图 9所示。

图 9 MAX32690板端软件初始化、采集、识别与输出流程图

8.2 开发与调试软件

工程使用CodeFusion Studio 2.2.1、 VS Code中的CFS扩展和MAX32xxx/MAX78xxx MSDK完成编译、链接、DAPLink下载与校验。日常操作通过命令面板选择CFS: Flash，终端依次输出工程配置、CMSIS-DSP版本、Flash/SRAM占用、Programming、Verify和Verified OK。串口调试使用VS Code串口监视器观察COM6，设置为115200、8-N-1。算法训练与结果统计使用工程内Python脚本；网页上位机通过本地HTTP服务加载音频并调用Web Bluetooth，手机端则用nRF Connect核验GATT服务、Write和Notify。

为了使整个工程复制到另一台电脑的任意路径后仍能工作，构建和烧录脚本不再写死F:Software cfs 2.2.1。

脚本优先读取系统注册表和CFS环境变量定位工具链；当工程路径包含中文或空格时，自动建立临时ASCII联接目录再调用MSDK；网页启动脚本优先复用CFS自带Python。该处理把“本机能够运行”提升为“只复制工程目录即可复现”，也是最终提交工程的重要组成部分。

8.3 工程结构

工程基于CodeFusion Studio 2.2.1和MAX32xxx/MAX78xxx MSDK构建。核心文件如表 5所示。模型权重以C头文件形式固化到Flash，开机后直接初始化音频、显示和BLE，因此断电重启后无需重新烧录，也不需要电脑运行Python模型。

表 5 固件与上位机核心文件

8.4 非阻塞主循环

固件避免在音频处理中使用长时间延时。DMA持续填充缓冲区，主循环轮询可用块并调用KWS状态机；BLE栈事件、显示刷新和串口输出穿插执行。识别完成后只生成一份结构化结果，由各输出通道复制消费。这样不会出现“串口是一个类别、BLE是另一个类别”的竞争条件，也避免显示刷新反向阻塞采样。

8.5 统一事件模型

每次VAD形成并完成判决的语音都分配事件号$E$；网页每次播放分配测试号$T$。板端UART打印完整可读日志，BLE发送紧凑帧。例如E87;T12;D;P99表示第87个识别事件、网页第12次测试、命令D（停止）、概率99%。拒绝事件使用命令码R。事件号使板端和上位机可逐条对应，测试号使网页不必“无限等待”前一条结果。

图 10 BLE Notify紧凑帧格式

8.6 关键状态机伪代码

音频分段与结果发布的核心逻辑（简化）

for (;;) {
    if (audio_block_ready()) {
        pcm48_stereo = audio_get_dma_block();
        pcm16_mono = remove_dc_and_decimate(pcm48_stereo, 3);
        event = kws_process_10ms(pcm16_mono);

        if (event.ready) {
            event.id = ++recognition_event_id;
            uart_report(event);
            tft_show(event);
            led_apply(event);
            ble_notify(event, current_test_id);
        }
    }
    ble_stack_process();
    display_process();
}

9 BLE通信与电脑上位机

9.1 GATT服务设计

BLE设备广播名称为Periph，实验地址为00:18:80:00:96:A0。自定义服务UUIDe0262760‑08c2‑11e1‑9073‑0e8ac72e1001，特征UUID为e0262760‑08c2‑11e1‑9073‑0e8ac72e0001，特征支持Notify、Write和Write Without Response。GATT/ATT是Bluetooth Low Energy数据交换的核心机制，协议行为遵循Bluetooth核心规范。

写入路径用于手机或电脑向开发板发送文本，示例hello在串口表现为0x68 0x65 0x6C 0x6C 0x6F；板端随后通过同一特征Notify回传，实现双向回环。识别模式复用Notify通道发送命令事件，不再发送冗长调试字符串，从而适配默认20字节ATT通知载荷。

9.2 手机端验证

nRF Connect for Mobile 用于扫描、连接、发现服务、向特征写入并订阅通知。手机日志中先出现 Data written ... "hello"，紧接着出现 Notification received ... "hello"，证明 “手机写入、板端接收、板端 Notify、手机接收” 的双向链路已经打通。

图 11 nRF Connect手机端写入与Notify回环日志

9.3 电脑网页测试台

电脑上位机采用 Python 标准 HTTP 服务器提供本地页面，浏览器通过 Web Bluetooth API 连接开发板。Web Bluetooth 规定网页在安全上下文和用户手势下请求 BLE 设备，因此连接按钮必须由用户点击。页面同时调用 HTML5 Audio 播放 TTS，维护测试编号、期望类别、实际 BLE 事件、置信度、结果和响应时间。

测试台包含以下功能：

按关键词筛选 20 条语音并随机选择；
独立播放当前音频或连续测试全部音频；
调节网页播放音量，最终测试固定为 60%；
连接 / 断开 Periph 并订阅 Notify；
解析事件号、测试号、类别和概率，自动判断正确 / 错误 / 拒绝；
清空测试记录，保留运行日志；
对无对应测试的异步通知只记录日志，不污染后续结果。

图 12 MAX32690关键词与BLE电脑测试台真实运行界面

图 13 电脑端BLE双向回环功能验证

10 实物演示与现象说明

10.1 开发板实物与接线现象

图14是最终演示状态的开发板实物照片。可以看到MAX32690EVKIT、外接DAPLink、J1上的2.4 GHz鞭状天线、CN2 USB连接、J5音频线以及板载TFT。TFT显示STOP和概率，说明照片记录的不是单纯上电状态，而是音频采集、关键词推理和本地显示已经联动的运行状态。演示时播放“开灯”“关灯”“前进”“停止”，TFT文本、LED动作、COM6日志和BLE通知应给出相同类别；拒绝事件只报告而不执行控制动作。

、

图 14 MAX32690开发板实物、音频线、BLE天线、DAPLink与TFT识别结果

10.2 CodeFusion Studio编译与烧录截图

图15给出CodeFusion Studio中执行CFS: Flash后的软件界面记录。日志显示项目正确加载project.mk、启用CMSIS‑DSP 1.16.2，链接后Flash占用419,928 B、SRAM占用97,836 B，随后完成Programming和Verify并得到Verified OK。此截图同时证明固件可编译、可烧录、可校验，并已写入片上Flash；开发板重新上电后会自动启动当前关键词识别与BLE程序。

图 15 CodeFusion Studio执行CFS: Flash的编译、烧录、校验与资源截图

除上述整理后的日志图外，图16进一步给出了实际CodeFusion Studio/VS Code工作区及终端截图。终端依次出现Programming Started、Programming Finished、Verify Started、Verified OK和目标复位信息，能够作为工程现场编译、下载与校验成功的原始软件证据。

图 16 CodeFusion Studio中CFS: Flash下载、校验和复位的真实界面截图

10.3 串口监视器与TFT同步输出

图17展示了工程源代码、CFS任务和COM6串口监视器同时打开的真实开发界面。串口以115200波特率持续输出事件编号、测试编号、识别类别、置信度、音频窗口与拒绝信息，便于将板端原始结果与BLE上位机记录逐条核对。图18则给出板载TFT的实拍结果，屏幕显示FORWARD和97%置信度，证明同一次识别结果能够在开发板本地直接呈现，而不依赖电脑网页显示。

图 17 CodeFusion Studio/VS Code工程代码与COM6串口监视器真实截图

图 18 板载TFT显示FORWARD命令、97%置信度与推理计时的实拍结果

10.4 电脑上位机演示现象

电脑网页测试台的真实运行界面已在图 12中给出。页面可按类别选择80条TTS语音、将播放音量固定为60%、连接Periph、订阅Notify并显示事件号、测试号、类别和概率。测试记录中的期望类别和BLE实测类别按测试号关联，迟到或无关联事件仅进入日志，不会无限影响后续记录。由此，演示者既能单条展示某个命令，也能连续遍历某一类或全部80条样本。

10.5 测试原则

PC端直接把WAV/MP3送入模型只能验证算法，无法覆盖声卡、音频线、MAX9867、I²S、VAD和板端预处理。最终测试坚持真实模拟链路：浏览器播放TTS，声音经电脑DAC和J5进入开发板，结果再经BLE返回浏览器。这样一次测试同时覆盖输入、识别和输出链路。

为了避免人为挑选“容易成功”的样本，最终验证遍历四个目录中的全部80条语音。每条测试先产生T编号并播放，网页只接受具有匹配测试号的新事件；超时、拒绝和错误均单独计数。串口同时保存原始KWS日志，CSV保存期望类别、实际类别、置信度、边际、语音窗口、事件号及原始行，便于离线复核。

10.6 测试环境与步骤

使用CFS: Flash编译、下载，确认终端出现Verified OK；
CN2连接电脑，打开COM6串口监视器，设置115200波特率；
J1连接2.4 GHz天线，J5连接电脑耳机输出；
启动pc_app本地服务器，在Edge/Chrome打开测试页面；
点击“选择并连接Periph”，确认Notify已启用；
将网页音量固定为60%，依次播放全部80条语音；
导出CSV，并进行120秒静音监听和BLE/UART事件一致性检查。

10.7 评价指标

设总样本数为N，正确、错误和拒绝数分别为Nc, Nw, Nr，则

$Accuracy = \frac{N _{c}}{N} \times 100%,$

$RejectRate = \frac{N _{r}}{N} \times 100%,$

$FalseClassRate = \frac{N _{w}}{N} \times 100%.$

此外记录各类最低置信度、VAD窗口分布、静音误触发次数、Flash/SRAM占用以及BLE通知到达时间。由于网页计时起点为音频播放结束，若板端通知在文件结束前已经到达，则响应显示为0 ms；这表示“结果早于播放结束到达”，并不是推理耗时绝对为零。

图 19 全量自动化测试日志摘要

11 遇到的难点及解决办法

11.1 从61/80到80/80

初始模型在真实模拟链路上得到61条正确、15条拒绝、4条误分类。PC文件测试表现较好而板端表现明显下降，说明主要矛盾是训练域与硬件域不一致，而不是简单“模型太小”。第一轮优化导出真实硬件的384维特征，加入训练并调整预处理一致性，结果提升到78条正确、2条拒绝、0条误分类。第二轮比较隐藏层规模、增加硬件特征重复权重并收紧VAD异常窗口后，最终达到80/80。

图 20 模型与真实链路协同优化过程

11.2 漏识别与拒绝

中间版本中部分“前进”语音出现59%和70%置信度，被72%阈值正确拒绝。分析串口导出的特征后发现，同一数字音频经过模拟链路会产生增益变化、频响偏移和起止边界差异。优化没有简单降低门限，因为降低门限会增加静音误触发；而是将真实硬件特征加入训练，提高困难样本本身的胜出概率。最终“前进”最低置信度升至93%。

11.3 延迟事件污染

早期网页用“当前最老的等待项”接收下一个BLE结果。若某次没有返回，后续通知就会被错误配给前一次测试，造成数十秒的虚假响应时间并持续影响后续记录。解决方案是在板端和网页之间传递$(E/T)$编号，页面只更新匹配$T$的行，未关联事件仅进入运行日志。该修改使BLE显示与串口逐事件一致，也取消了阻塞式无限等待。

11.4 音频卡顿与模块隔离

叠加BLE、显示和大量串口输出时，早期音频回环出现卡顿。通过临时编译“纯音频回环”程序，确认MAX9867、I 2S时钟和DMA配置本身稳定；随后将输出改为事件驱动、缩短BLE帧并减少高频显示刷新，恢复连续采集。该过程说明在嵌入式实时系统中，模块隔离测试比一次性叠加所有功能更易定位问题。

12 最终实验结果

12.1 分类准确率与混淆矩阵

最终CSV共80行，四类各20行，Status全部为CORRECT。混淆矩阵仅主对角线非零，开灯、关灯、前进、停止各20条均正确，准确率为100%，拒绝率和误分类率均为0。

图 21 最终80条真实链路测试混淆矩阵

图 22 四类关键词最终逐类别正确率

12.2 置信度分布

80条样本的最低置信度为89%，绝大多数为95%–100%。各类最低值分别为：关灯89%、开灯92%、前进93%、停止95%。图 23中所有点均显著高于72%接受门限；箱线图显示各类中位数接近99%，没有类别整体偏低。

图 23 最终80条真实链路测试置信度序列

图 24 各关键词置信度分布

12.3 语音窗口与响应时间

各类VAD窗口统计见表 6。平均窗口为438–484 ms，最大为600 ms，均未触及700 ms异常拼接保护。该窗口包含命令发音和VAD边界，是模型输入长度，不是分类计算耗时。网页记录中结果经常在音频文件播放结束前到达，因此显示0 ms；可见的非零记录包括16 ms、33 ms、244 ms、253 ms和347 ms，均小于500 ms。UART中的infer=0 ms来自毫秒级计时分辨率，说明单次MLP推理不足一个系统毫秒刻度，不能据此宣称绝对零耗时。

表 6 最终80条测试逐类结果

图 25 最终测试中各类VAD语音窗口分布

12.4 串口、BLE、显示与LED一致性

串口完整日志包含事件号、测试号、类别、置信度、 margin、 audio、infer和overffow；BLE紧凑帧携带相同事件号、测试号、类别和概率；TFT显示命令和概率，LED执行对应动作。测试中网页、UART和TFT的类别一致。串口日志摘要如图 26，其E87/T12与BLE帧示例完全对应。

图 26 系统启动与关键词识别串口日志摘要

12.5 资源占用与烧录验证

最终固件Flash占用419,928 B/3,312 KB （12.38%）， SRAM占用97,836 B/1,024 KB （9.33%）。即使后续增加一至两个关键词、小规模提升隐藏层或增加控制逻辑，仍有明显空间。 CFS下载过程依次出现Programming Finished和Verified OK，复位后固件从片上Flash自动启动。

图 27 最终固件Flash与SRAM占用

13 需求符合性、局限与改进方向

13.1 需求符合性

表 7 题目要求符合性检查

13.2 现有局限

尽管当前数据集获得100%真实链路准确率，仍需正确理解结果边界：

测试语音来自TTS，多音色可以覆盖发音差异，但不能完全代表真实人声、方言和远场混响；
线性输入链路比开放空间麦克风更稳定，若改用PDM麦克风，需要重新采集噪声和真实硬件特征；
当前四类词表固定，增加新词必须重新训练并导出权重；
响应测试依赖浏览器事件和BLE到达时间，若要形成更严谨的性能论文，应使用GPIO翻转和逻辑分析仪测量端点；
当前模型以浮点权重存储，尚未使用INT8量化，虽然资源充足，但仍有进一步降低功耗的空间。

13.3 后续改进

后续可以从三方面演进。第一，数据方面加入不同性别、语速、口音和环境噪声下的真人录音，并单独建立未知词与纯噪声负样本；第二，算法方面可比较深度可分离卷积网络、量化感知训练和PCEN等更稳健前端；第三，系统方面可将LIGHT ON/OFF映射到继电器，将FORWARD/STOP映射到电机驱动，同时保留BLE远程监督。由于当前Flash和SRAM占用均低于13%，这些扩展不会立即受存储空间限制。

14 本次活动心得体会与意见建议

14.1 从“能运行”到“可验证”的体会

本次活动最直接的收获，是认识到嵌入式人工智能项目的完成标准不能停留在“模型在电脑上准确”或“开发板偶尔输出正确结果”。真正可提交的系统必须同时满足硬件链路稳定、算法输入一致、输出可观测、测试可重复和工程可移植。项目早期先点亮LED、再打通串口和TFT，随后分别完成BLE回环与纯音频回环，这些看似基础的步骤为后续复杂系统建立了可信的参照。如果一开始就把音频、模型、显示和无线全部叠加，面对卡顿或误识别将很难判断故障位于哪一层。

第二个体会是，真实硬件数据比单纯扩大网络更重要。初始模型在PC文件上表现很好，但经过电脑DAC、音频线、MAX9867 ADC和板端预处理后出现拒绝与误分，说明训练域和部署域并不相同。把板端导出的真实384维特征回灌训练后，困难样本的概率明显提高，最终在不降低72%置信度阈值和20%边际阈值的前提下达到80/80。这一过程比盲目增加模型层数更节省资源，也更容易解释。

第三个体会是，通信协议中的“可关联性”与识别准确率同样重要。若BLE只发送类别而没有事件号和测试号，一次迟到通知就可能被上位机错配给下一条音频，从而产生几十秒的假延迟和连锁错误。加入$(E/T)$编号后，UART、BLE和网页能够逐事件核对，未关联通知也不会阻塞测试。由此可见，可靠演示依赖的不只是分类器，还依赖数据协议、状态机和日志设计。

14.2 对后续参赛者的建议

建议后续项目按“基础外设、单链路、完整链路、自动化测试”的顺序推进。首先保留一个最小LED/串口程序验证下载链路；其次分别准备BLE回环和音频回环固件；第三，在加入模型前保存一段真实PCM或特征用于与Python逐点比较；最后再搭建能够遍历全部样本、记录事件号和导出CSV的上位机。对于关键词模型，应同时准备静音、线路噪声和未知词负样本，并把VAD误触发率与分类准确率分开评价，不能只观察几次成功演示。

在报告撰写方面，建议每个关键结论都对应原始证据：硬件连接用实物照片，编译烧录用CodeFusion Studio截图，识别过程用串口与BLE日志，准确率用全量测试CSV和混淆矩阵，资源占用用链接器结果。响应延迟应明确起止点；audio=是有效语音窗口而不是推理耗时，infer=0 ms也只是系统毫秒计时分辨率下的结果。把定义写清楚，比给出一个没有测量边界的漂亮数值更可靠。

14.3 对活动组织与平台资料的建议

本次活动提供官方套件和开放题目，使参赛者可以覆盖音频、机器学习、BLE与人机交互的完整链路。若后续活动进一步完善资料，可增加三类内容：其一，给出评估板各USB接口、跳线和音频接口的面向初学者接线图，减少把CN1、CN2、DAPLink和音频跳线混淆的时间；其二，提供一份可直接编译的MAX9867 I²S/DMA最小例程以及串口、显示共存说明；其三，明确响应延迟建议测量端点，并提供统一结果表模板。这样既能保持题目的开放性，也能让参与者把更多时间投入算法与系统优化。

14.4 个人总结

整个项目从一块未运行用户程序的开发板起步，最终形成了可烧录、可独立启动、可离线识别、可通过四种通道反馈、可由手机和电脑核验、可批量测试并可复制到任意路径的完整工程。过程中最有价值的不是某一个库函数或某一次参数调整，而是形成了“先隔离链路、再记录证据、用真实数据闭环、最后自动化复现”的工程方法。这套方法同样适用于传感器融合、电机控制、边缘视觉和其他嵌入式智能项目。

15 总结

本项目从一块尚未运行用户程序的MAX32690官方套件出发，依次完成DAPLink下载、LED与串口基础测试、TFT显示、BLE双向回环、MAX9867音频回环、离线关键词模型训练以及四通道结果输出。最终系统实现4个中文命令词的板端离线识别，并以统一事件同时驱动TFT、LED、UART和BLE。

工程工作的关键不只是得到一个PC端准确的模型，而是打通真实模拟音频链路，并通过可观测、可关联、可复现的测试闭环持续优化。80条TTS经电脑声卡和J5输入后全部正确，最低置信度89%；120秒静音零事件；网页可逐条对应BLE与UART；Flash和SRAM仍保留大部分空间。由此可见，384维Log‑Mel与384‑64‑4 MLP在MAX32690上具有良好的资源效率，动态VAD、双阈值判决和硬件特征回灌对真实链路稳定性至关重要。项目已经满足题目对离线识别、关键词数量、响应速度和外设/BLE控制的核心要求，并具备进一步扩展真人语音、电机控制和量化模型的基础。