首页/资讯中心/详情

基于XIAO nRF52840 Sense的嵌入式语音识别：从TensorFlow Lite Micro到自定义关键词模型实战

基于XIAO nRF52840 Sense的嵌入式语音识别：从TensorFlow Lite Micro到自定义关键词模型实战
📅 发布时间：2026/8/3 15:18:23

1. 项目缘起：为什么选择XIAO nRF52840 Sense做语音识别？

最近在捣鼓一些需要离线语音交互的小玩意儿，比如智能开关、语音控制的桌面摆件，或者是一些需要低功耗语音唤醒的设备。这类项目最头疼的就是选型：用传统的ESP32加麦克风模块吧，功耗和体积总得妥协；用专门的语音识别芯片吧，开发灵活性和成本又成了问题。就在我纠结的时候，Seeed Studio的XIAO nRF52840 Sense这块小板子进入了我的视线。

这块板子很有意思，它集成了Nordic的nRF52840这颗蓝牙5.0/低功耗主控，自带64MHz的Cortex-M4F内核，内存有256KB RAM和1MB Flash，性能对于嵌入式应用来说相当充裕。更关键的是，它“Sense”的后缀名不虚传：板载了数字麦克风（PDM）、6轴IMU、光照传感器，甚至还有一个用于充电管理的芯片。这意味着，你拿到手的就是一个完整的、电池友好的传感与交互核心，特别适合我这种想快速验证语音想法，又不想在硬件连接上花费太多时间的人。

那么，在这块板子上做语音识别，到底意味着什么？它解决的痛点非常明确：实现低功耗、离线的关键词唤醒或简单命令识别。你不需要一直连接云端服务器，不用担心网络延迟或隐私泄露，设备“听到”特定的词（比如“小爱同学”、“Hey Siri”或者自定义的“开灯”、“关风扇”）后，就能立刻在本地做出反应。这对于智能家居、穿戴设备、工业控制等对实时性和可靠性要求高的场景，价值巨大。

当然，它也有它的边界。指望它像手机上的语音助手一样理解长句、进行复杂对话，那是不现实的。它的核心能力在于对几个到几十个预先定义好的、短小的语音命令进行高准确率的识别。这恰恰是很多实际项目中最需要的功能。接下来，我就结合自己的踩坑经验，详细拆解如何在XIAO nRF52840 Sense上一步步实现这个功能。

2. 开发环境搭建与核心库解析

工欲善其事，必先利其器。在XIAO nRF52840 Sense上玩转语音，第一步不是写代码，而是把环境和工具链搞清楚。这里主要有两条路：使用Arduino IDE（搭配Seeed的nRF52核心）或者使用PlatformIO。我个人更推荐PlatformIO，因为它对库依赖和项目管理更友好，但为了照顾不同习惯的开发者，我会把两种方式的关键点都讲清楚。

2.1 硬件连接与麦克风驱动确认

虽然XIAO nRF52840 Sense板载了麦克风，但在软件上驱动它，需要确认正确的引脚映射和配置。板载麦克风通常连接在特定的PDM（脉冲密度调制）接口上，对于nRF52840，这通常是PDM_CLK和PDM_DIN引脚。

在Arduino环境下，Seeed提供的板支持包（Board Support Package, BSP）已经帮你做好了映射。你只需要在代码中包含正确的库（例如PDM.h）并初始化即可。一个简单的测试代码可以验证麦克风是否工作：

#include <PDM.h> // 设置PDM缓冲区 short sampleBuffer[256]; volatile int samplesRead; void setup() { Serial.begin(115200); while (!Serial); // 配置PDM PDM.onReceive(onPDMdata); PDM.setBufferSize(256); // 初始化PDM麦克风 if (!PDM.begin(1, 16000)) { // 1个通道，16kHz采样率 Serial.println("Failed to start PDM!"); while (1); } } void loop() { if (samplesRead) { // 简单打印一些采样值，确认数据在变化 for (int i = 0; i < samplesRead; i++) { Serial.println(sampleBuffer[i]); } samplesRead = 0; } delay(100); } // PDM数据就绪回调函数 void onPDMdata() { // 查询可读的字节数，并转换为16位样本数 int bytesAvailable = PDM.available(); PDM.read(sampleBuffer, bytesAvailable); samplesRead = bytesAvailable / 2; // 每个样本16位，即2字节 }

把这段代码烧录进去，打开串口监视器，如果能看到不断变化的数字（通常在-几百到+几百之间波动），对着板子说话时数值变化幅度明显增大，那就说明麦克风硬件和基础驱动是OK的。这是所有后续工作的基石。

注意：PDM.begin()里的采样率参数至关重要。16kHz是语音识别的一个常用采样率，它能覆盖大部分人声音频的主要频率成分（通常认为在8kHz以内），同时数据量又不会太大。盲目提高采样率（如32kHz）不仅会增加计算负担，对识别精度提升也有限，甚至可能引入更多高频噪声。

2.2 语音识别库的选择：TensorFlow Lite for Microcontrollers

要实现本地识别，我们需要一个能在微控制器上跑的机器学习推理框架。目前社区里最成熟、资源最丰富的选择无疑是TensorFlow Lite for Microcontrollers (TFLite Micro)。它本质上是TensorFlow Lite的一个子集，专门为资源受限的嵌入式设备（RAM在KB级别）优化。

为什么是TFLite Micro而不是其他？

  1. 生态强大：Google主导，有大量的预训练模型、工具链和社区案例。特别是其“Micro Speech”示例，几乎是嵌入式关键词识别的“Hello World”。
  2. 跨平台：模型训练可以在强大的PC或云端完成（使用TensorFlow），然后转换成.tflite格式，最后部署到nRF52840上运行。这种工作流非常清晰。
  3. nRF52840支持良好：得益于Cortex-M4F内核和足够的RAM/Flash，运行经过适当裁剪的TFLite Micro模型是可行的。

在Arduino项目中集成TFLite Micro，通常不是直接安装一个库那么简单。你需要手动将TFLite Micro的源码作为库添加到你的项目中，或者使用一些社区维护的封装库（如EloquentTinyML或Arduino_TensorFlowLite）。我强烈建议直接从TensorFlow官方GitHub仓库获取源码，虽然步骤稍多，但能避免版本兼容性问题，也最有利于理解底层机制。

具体操作是，去TensorFlow的GitHub仓库，找到tensorflow/lite/micro目录，将其复制到你的Arduino项目库文件夹（libraries）下，并重命名为类似TensorFlowLite_Micro的名字。同时，你还需要一些依赖文件，比如flatbuffers（用于解析.tflite模型文件）。这个过程有点像搭积木，需要耐心。在PlatformIO中，则可以通过lib_deps直接指定Git仓库地址来拉取，相对省心。

2.3 模型获取与预处理：从“Micro Speech”开始

对于初学者，最好的起点是TensorFlow官方提供的“Micro Speech”示例模型。这个模型已经预训练好，可以识别两个关键词：“yes”和“no”，以及一个“未知”类别和“静音”类别。我们的第一步就是让这个模型在XIAO上跑起来。

这个模型是一个简单的卷积神经网络（CNN），但它处理的不是原始的音频波形，而是音频的频谱图（Spectrogram），更具体地说，是梅尔频率倒谱系数（MFCC）。这是语音识别中的标准预处理步骤，其目的是将声音信号从时域转换到更能代表人耳听觉特性的频域表示，同时大幅压缩数据量。

所以，我们的代码流程就清晰了：

  1. 采集：通过PDM接口，以16kHz采样率持续采集原始音频数据（16位有符号整数）。
  2. 预处理：将采集到的一段时间（比如1秒）的音频数据，通过一系列计算（预加重、分帧、加窗、FFT、梅尔滤波器组、对数运算、DCT）转换为MFCC特征向量。这个向量就是模型的输入。
  3. 推理：将MFCC特征向量输入到TFLite Micro模型中，运行前向传播（推理）。
  4. 后处理：获取模型输出（通常是每个类别的概率得分），找出概率最高的类别，如果其概率超过某个阈值（比如0.7），则认为识别到了对应的命令。

“Micro Speech”示例已经为我们提供了MFCC计算和模型推理的完整C++代码。我们的主要工作是将这部分代码与XIAO nRF52840 Sense的PDM采集代码“焊接”起来，并调整缓冲区大小、音频窗长度、步长等参数，使其与硬件性能匹配。

3. 核心实现：将“Micro Speech”移植到XIAO

这是整个项目最核心、也最容易踩坑的部分。你不能直接把Arduino Due或ESP32的示例代码搬过来，必须根据nRF52840的内存和性能特点进行调整。

3.1 音频流与环形缓冲区设计

语音是连续的数据流，但模型推理需要固定长度的数据块（例如，对应1秒的音频）。我们需要一个环形缓冲区（Ring Buffer）来协调持续的采集和批次的处理。

采集中断（onPDMdata回调）会以很高的频率被调用，每次填入几百个样本。我们不能在中断里进行复杂的MFCC计算或模型推理，这会阻塞中断导致数据丢失。正确的做法是：

  • 在中断服务程序（ISR）中，只做一件事：将新采集到的音频样本快速存入环形缓冲区。
  • 在主循环（loop）中，定期检查环形缓冲区中是否积累了足够一次推理所需的数据（例如16000个样本对应1秒）。如果够了，就复制出来，进行预处理和推理。

这个环形缓冲区的大小需要仔细设计。它必须至少能容纳“一次推理所需数据量”加上“在两次处理间隔内新采集的数据量”，防止数据覆盖。对于16kHz采样率和1秒的音频窗，这就是16000个样本。考虑到主循环其他操作的耗时，缓冲区可以设为2048或4096个样本（约128-256ms），采用“生产-消费”模型。

// 简化的环形缓冲区示例 #define RING_BUFFER_SIZE 4096 int16_t audioRingBuffer[RING_BUFFER_SIZE]; volatile uint16_t audioBufferWritePos = 0; uint16_t audioBufferReadPos = 0; void onPDMdata() { // 快速将sampleBuffer中的数据存入环形缓冲区 for(int i=0; i<samplesRead; i++){ audioRingBuffer[audioBufferWritePos] = sampleBuffer[i]; audioBufferWritePos = (audioBufferWritePos + 1) % RING_BUFFER_SIZE; // 这里可以添加缓冲区满的处理（例如丢弃最旧数据） } }

3.2 MFCC特征提取的优化与固定点运算

“Micro Speech”示例中的MFCC计算代码是浮点数运算。虽然nRF52840的Cortex-M4F有硬件浮点单元（FPU），但大量浮点运算依然会消耗可观的CPU时间和内存带宽。为了极致优化，尤其是在需要低功耗的场景下，可以考虑使用定点数（Fixed-point）运算来替代部分浮点运算。

TFLite Micro本身支持模型的量化（Quantization）。你可以训练一个8位整数量化模型，这样从输入到中间层再到输出，全部是整数运算，速度极快，内存占用也更小。但MFCC预处理部分，示例代码默认仍是浮点的。

一个折中的优化策略是：寻找MFCC计算中的关键浮点运算（如FFT、对数运算、DCT），看是否有轻量级的定点数库可以替代。或者，直接使用经过高度优化的MFCC代码库。对于初期验证，使用浮点版本问题不大，但如果你发现识别过程导致系统响应变慢或功耗过高，这就是首要的优化方向。

实操心得：在移植时，最容易出问题的是内存不足。TFLite Micro模型、音频缓冲区、MFCC计算中的中间数组都会占用RAM。nRF52840的256KB RAM看起来不少，但如果不加规划，很容易就爆掉。务必使用Serial.print(ESP.getFreeHeap())（在Arduino核心中可能是__get_free_heap()）来监控内存使用情况。如果内存紧张，首要任务是减小音频缓冲区大小，或者降低MFCC特征向量的维度。

3.3 模型推理与结果解析

当MFCC特征向量准备好后，就可以喂给TFLite Micro解释器（Interpreter）进行推理了。这个过程相对标准：

// 伪代码，展示流程 #include "tensorflow/lite/micro/micro_interpreter.h" #include "tensorflow/lite/micro/micro_mutable_op_resolver.h" #include "tensorflow/lite/schema/schema_generated.h" // 1. 加载模型（.tflite文件以字节数组形式存储在Flash中） extern const unsigned char g_model[]; // 模型数组 extern const int g_model_len; // 2. 定义操作解析器（告诉解释器模型用了哪些算子） static tflite::MicroMutableOpResolver<5> resolver; resolver.AddDepthwiseConv2D(); resolver.AddConv2D(); resolver.AddAveragePool2D(); resolver.AddReshape(); resolver.AddSoftmax(); // 3. 分配张量内存区域（Tensor Arena），这是最关键的！ const int tensorArenaSize = 10 * 1024; // 例如10KB uint8_t tensorArena[tensorArenaSize]; // 4. 创建解释器 tflite::MicroInterpreter interpreter( tflite::GetModel(g_model), resolver, tensorArena, tensorArenaSize); // 5. 分配内存 interpreter.AllocateTensors(); // 6. 获取输入输出张量指针 TfLiteTensor* input = interpreter.input(0); TfLiteTensor* output = interpreter.output(0); // 7. 在loop中：将MFCC特征数据复制到input->data.f中（浮点模型） memcpy(input->data.f, mfcc_features, sizeof(float) * FEATURE_SIZE); // 8. 运行推理 TfLiteStatus invoke_status = interpreter.Invoke(); if (invoke_status != kTfLiteOk) { Serial.println("Invoke failed!"); return; } // 9. 解析输出（例如4个类别的概率） float yes_score = output->data.f[0]; float no_score = output->data.f[1]; float unknown_score = output->data.f[2]; float silence_score = output->data.f[3];

这里的关键是tensorArenaSize。这个内存区域用于存储中间张量（中间计算结果）。如果设置太小，AllocateTensors()会失败。你需要根据模型复杂度来调整。可以从16KB开始尝试，逐步增加直到分配成功。模型越复杂，需要的Arena就越大。

识别结果出来后，不要看到一个类别的概率最高就立刻判定。我建议增加一个阈值判断和去抖动（Debouncing）逻辑。例如，只有当“yes”的概率连续3次推理都超过0.7，才最终触发“yes”命令。这能有效避免偶然的噪声误触发。

4. 从示例到实践：训练自定义关键词模型

跑通“yes/no”只是第一步。我们最终需要的是识别自己的命令，比如“打开空调”、“关闭灯光”。这就需要训练自定义模型。

4.1 数据采集：构建你自己的语音数据集

模型训练需要数据。你需要为自己定义的每个关键词（比如“开灯”、“关灯”），录制数百条音频样本。这些样本应该涵盖：

  • 不同的说话人：至少包含你自己，如果设备是多人使用，最好采集多人的声音。
  • 不同的语速和语调：正常说、快速说、慢速说、带点口音的说。
  • 不同的环境：在安静的房间、有点背景噪声的房间（如风扇声）分别录制。

采集工具可以用电脑或手机录音，保存为16kHz采样率、单声道、16位深的WAV文件。为每个关键词建立一个文件夹，把对应的音频文件放进去。同时，你还需要大量“负样本”，即不包含任何关键词的日常环境音或随机语音，这些用于训练“未知”和“静音”类别。

这个过程很枯燥，但数据质量直接决定模型上限。一个取巧的办法是使用数据增强：对已有的音频进行变速、变调、添加背景噪声等处理，人工扩充数据集。有很多Python音频库（如librosa,pydub）可以帮你自动化完成这部分工作。

4.2 使用TensorFlow训练自定义模型

有了数据，就可以按照TensorFlow官方教程来训练。大致步骤是：

  1. 预处理：用和嵌入式端完全相同的MFCC参数（滤波器数量、帧长、帧移等）处理所有训练音频，生成特征文件（如.npy）。务必保证训练和推理的预处理一致，否则模型会失效。
  2. 构建模型：你可以基于“Micro Speech”的简单CNN结构，也可以尝试稍复杂的模型（如DS-CNN），在准确率和模型大小之间权衡。
  3. 训练：在PC上使用TensorFlow/Keras进行训练。
  4. 量化与转换：将训练好的浮点模型转换为.tflite格式，并进行训练后整数量化，生成8位模型。量化会轻微损失精度，但能极大提升推理速度和减少内存占用，对嵌入式设备至关重要。
  5. 模型部署：将量化后的.tflite文件转换为C语言字节数组（可以用xxd -i命令），替换掉项目中原有的g_model[]数组。

4.3 在XIAO上集成与测试自定义模型

将新模型集成到XIAO的代码中后，重点测试以下几方面：

  • 内存：新模型是否还能在tensorArena中成功分配张量？可能需要调整tensorArenaSize。
  • 速度：完成一次“采集-预处理-推理”的循环需要多少时间？这决定了你的系统响应延迟。如果目标是实时识别，这个时间必须小于你的音频窗滑动步长（例如，如果每200ms推理一次，那么整个流程就要在200ms内完成）。
  • 准确率：在设备上实地测试。在不同距离、不同噪声环境下说出命令，观察识别结果。如果误触发多，考虑调整后处理的概率阈值和去抖动次数。

一个常见的性能瓶颈是FFT计算。MFCC预处理中的FFT运算量较大。如果发现预处理耗时太长，可以尝试使用nRF52840的CMSIS-DSP库中优化的FFT函数，它针对ARM Cortex-M系列处理器有高度优化，比纯C实现的FFT快很多。

5. 系统优化与进阶应用

当基本功能跑通后，我们可以从“能用”向“好用”和“实用”进化。

5.1 低功耗设计：让设备续航更持久

XIAO nRF52840 Sense的一大优势是低功耗。如果我们的语音识别设备是电池供电，那么功耗优化就是必修课。

  1. 间歇性唤醒：不要让系统一直处于全速运行、持续监听的状态。可以设置一个“监听窗口”模式。例如，每100毫秒唤醒一次，采集50毫秒的音频并进行一次快速的关键词检测（可以用一个更小的、计算量更少的唤醒词模型）。只有检测到可能的唤醒词后，才进入全功能识别模式。这可以借鉴手机上的“Always-On Listening”思路。
  2. 外设与时钟管理：在睡眠期间，关闭所有不必要的外设（如串口、IMU、LED），降低系统主频。nRF52840的功耗管理非常灵活，可以通过nRF5x-low-power等库进行深度睡眠配置。
  3. 算法层面优化：使用量化后的8位模型进行推理，计算能耗远低于浮点模型。此外，可以探索二值化神经网络等更极端的轻量化模型。

5.2 结合板载传感器实现多模态交互

XIAO nRF52840 Sense不止有麦克风。我们可以把语音识别和它的其他传感器结合起来，创造更智能的交互。

  • IMU（惯性测量单元）：检测设备是否被拿起、晃动或处于特定朝向。例如，只有设备被拿起并靠近嘴边时，才开启高灵敏度的语音识别，其他时间则进入低功耗监听模式，这能有效防止误触发。
  • 光照传感器：根据环境光强度调整设备状态。例如，在黑暗环境中自动关闭LED指示，或者判断设备是否在口袋/抽屉里（光照极低），从而调整语音识别的灵敏度或策略。

这种多模态融合能极大提升用户体验和设备智能化程度。例如，一个语音控制的智能遥控器，只有当你把它从桌面上拿起来时，它才“醒过来”准备听指令，放下后就进入深度睡眠。

5.3 识别结果的应用：触发动作与状态反馈

识别出语音命令后，最终要落地到执行动作。XIAO nRF52840 Sense有GPIO、I2C、SPI、UART等接口，可以轻松控制继电器、舵机、LED，或者通过蓝牙（BLE）将指令发送给手机或其他智能设备。

例如，识别到“开灯”后，可以控制一个GPIO引脚输出高电平，驱动继电器打开电灯。同时，可以通过板载的RGB LED给出视觉反馈（例如闪烁绿色），或者通过BLE向手机App发送一条通知，告知命令已执行。

这里要注意系统稳定性。避免在中断服务程序（如PDM回调）或模型推理循环中直接执行耗时操作（如网络通信、复杂的串口打印）。应该将识别结果设置一个标志位，在主循环中根据这个标志位去执行相应的动作，保持音频采集和处理的实时性不被破坏。

6. 实战避坑指南与调试技巧

最后，分享几个我实际开发中踩过的坑和总结的技巧，希望能帮你少走弯路。

  1. “无声”的麦克风：如果测试代码收不到任何音频数据，首先检查硬件连接（虽然XIAO是板载的，但也要确认焊接没问题），然后检查PDM.begin()的返回值。更隐蔽的问题是采样率配置不匹配。确保代码中设置的采样率（如16000）与麦克风硬件实际支持的采样率一致。有些麦克风模块对时钟频率有严格要求。

  2. 模型推理结果全是零或固定值：这通常是输入数据格式不对导致的。首先，确认你复制到input->data.f（或input->data.int8）的数据，其形状（shape）和数据类型与模型期望的完全一致。其次，检查MFCC特征计算过程，确保没有溢出或计算错误。一个有效的调试方法是，将你在嵌入式端计算出的前几个MFCC特征值打印出来，与你在PC端用相同音频、相同参数计算出的结果进行对比，应该基本一致。

  3. 内存崩溃与不稳定：这是最棘手的问题。症状可能是程序随机重启、推理结果错乱。务必系统性地检查内存：

    • 栈溢出：增大platformio.ini或Arduino IDE中的栈大小设置。
    • 堆碎片化：尽量避免在循环中动态分配内存（malloc/new）。所有大数组（如音频缓冲区、tensor arena）尽量作为全局静态变量分配。
    • Tensor Arena不足：如果AllocateTensors()失败或推理时崩溃，逐步增大tensorArenaSize，每次增加2KB，直到稳定。也可以使用TFLite Micro提供的PrintMemoryPlan()函数（如果编译了）来查看内存使用详情。

  4. 识别准确率低：如果在PC上模拟识别效果不错，但烧录到设备上效果变差，请检查：

    • 量化误差：你是否使用了8位量化模型？训练后量化有时会带来精度损失。可以尝试使用“量化感知训练”来改善，或者在设备上使用浮点模型对比一下效果。
    • 背景噪声：设备端的麦克风环境和你的训练数据环境差异可能很大。尝试在设备端采集一些真实环境下的背景噪声，混入到你的训练数据中进行数据增强。
    • 音量问题：设备端采集的音频音量可能过大（削波）或过小。可以在代码中添加一个自动增益控制（AGC）或简单的音量归一化步骤。

  5. 利用串口绘图仪调试：Arduino IDE和PlatformIO都内置了串口绘图仪功能。这是一个极其强大的实时调试工具。你可以将麦克风的原始采样值、计算出的音频能量、或者模型输出的概率得分实时发送到串口，并在绘图仪上可视化。这能帮你直观地看到语音信号的波形、判断静音检测是否准确、观察模型输出的跳变情况，比单纯看数字日志高效得多。

实现一个稳定可靠的嵌入式语音识别系统，是一个在硬件资源、算法精度、响应速度和功耗之间反复权衡的过程。从让麦克风出声，到跑通第一个模型，再到训练自定义命令并优化整个系统，每一步都需要耐心调试和深入理解。XIAO nRF52840 Sense以其均衡的性能和丰富的集成传感器，为这类应用提供了一个绝佳的起点。当你对着自己亲手打造的小设备说出命令，并看到它准确响应时，那种成就感绝对是驱动你继续探索下去的最大动力。希望这篇长文能为你扫清一些障碍，祝你开发顺利。