基于 ESP32-S3 的语音备忘录设备

最新推荐文章于 2026-08-17 14:08:04 发布

原创最新推荐文章于 2026-08-17 14:08:04 发布 · 1.3k 阅读

25 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

AI助手已提取文章相关产品：

基于 ESP32-S3 的语音备忘录设备：从芯片到体验的全链路实践

你有没有过这样的瞬间？突然想到一个绝妙的点子，手边却没纸笔，手机又不在身边——等你翻出手机打开录音 App，灵感早就溜走了。

而市面上那些“智能”录音笔，要么依赖云端处理，隐私堪忧；要么功能单一，像个只会按开始/停止的傻瓜盒子。更别提动辄几百上千的价格了。

但如果我们换个思路呢？

如果用一块成本不到30元的 ESP32-S3 芯片，就能做出一个真正“懂你”的语音备忘录：
- 它能听懂你的唤醒词，比如“记一下”，立刻开始录音；
- 所有数据都留在本地，连不上Wi-Fi也照常工作；
- 一次充电能待机半年，放在口袋里随时可用；
- 还支持蓝牙同步、OTA升级，甚至未来可以离线识别你说的每一个字……

听起来像科幻？其实它已经能做了。而且整个系统的核心，就是这块小小的国产Wi-Fi+蓝牙双模MCU。

为什么是 ESP32-S3？

在嵌入式领域，“做语音”曾经是个奢侈的事。传统方案要么靠高性能ARM Cortex-A系列跑Linux + Python模型，功耗高得吓人；要么把音频传到云端做ASR（自动语音识别），不仅延迟大，还等于把你的私密对话主动交出去。

直到像 ESP32-S3 这样的芯片出现。

它不是什么超级计算机，但它聪明得刚刚好。

双核Xtensa LX7，主频240MHz，自带512KB SRAM和384KB ROM，还能外扩PSRAM和Flash到16MB以上——这配置对一个MCU来说已经相当能打了。更重要的是，它内置了 向量指令扩展（Vector Instructions） ，这让定点和浮点运算效率大幅提升，尤其是运行轻量级神经网络时，性能提升可达3倍以上。

换句话说，它能在毫瓦级功耗下完成关键词唤醒（KWS）、语音活动检测（VAD），甚至是简单的命令词识别。不需要GPU，也不需要云服务器，一切都在设备端闭环完成。

而且它是乐鑫出品，意味着有成熟的 ESP-IDF 开发框架 、Arduino兼容性、丰富的文档和社区支持。不像某些国外MCU，光配个I²S驱动就得啃几十页英文手册。

硬件怎么搭？从麦克风到存储

我们先来看最核心的链路：声音是怎么被捕捉并存下来的。

想象一下这个过程：

声波 → MEMS麦克风 → 数字信号 → 处理 → 编码 → 存入闪存

其中最容易被低估的一环，其实是 模拟前端设计 。很多人直接拿个驻极体麦克风焊上去，结果录出来全是嗡嗡的底噪，稍微远一点就听不清。

我们的选择是： PDM数字麦克风 ，比如 Knowles 的 SPH0645LM4H-B 或 Infineon 的 IM69D130。

为什么选PDM？

因为它输出的就是1-bit高采样率（通常是1.28MHz或3.072MHz）的脉冲密度调制信号，抗干扰能力强，走线再长也不怕串扰。最关键的是——ESP32-S3 的 I²S 外设原生支持 PDM 解调！

这意味着什么？

意味着你可以省掉运放、滤波电路、ADC转换这些复杂的模拟设计，直接通过两个GPIO（时钟CLK和数据DIN）连接麦克风，剩下的解调工作由硬件自动完成：PDM信号经过抽取滤波器变成标准PCM音频流（比如16kHz/16bit），放进DMA缓冲区，CPU只需要定期来取就行。

这不仅仅是简化电路的问题，更是降低了噪声源的数量。少一级放大，就少一分失真。

来看一段实际的初始化代码：

#include "driver/i2s.h"
#include "esp_log.h"

#define SAMPLE_RATE     (16000)
#define BITS_PER_SAMPLE (16)
#define CHANNELS        (1)

static const i2s_config_t i2s_config = {
    .mode = I2S_MODE_MASTER | I2S_MODE_RX | I2S_MODE_PDM,
    .sample_rate = SAMPLE_RATE,
    .bits_per_sample = I2S_BITS_PER_SAMPLE_16BIT,
    .channel_format = I2S_CHANNEL_FMT_ONLY_LEFT,
    .communication_format = I2S_COMM_FORMAT_STAND_I2S,
    .dma_buf_count = 8,
    .dma_buf_len = 64,
    .use_apll = false
};

static const i2s_pin_config_t pin_config = {
    .bck_io_num = GPIO_NUM_5,   // PDM CLK
    .ws_io_num = GPIO_NUM_6,    // PDM WS / L/R select
    .data_out_num = GPIO_NUM_NC,
    .data_in_num = GPIO_NUM_7   // PDM Data In
};

这段代码里有几个关键点值得细说：

I2S_MODE_PDM 是启用PDM接收的关键标志，否则默认走的是标准I²S PCM模式；
dma_buf_count 和 dma_buf_len 决定了缓冲区大小。设为8个buffer、每个64字节，总共约512字节，对应16kHz单声道采样大约是1.6ms的数据量。太小会导致频繁中断，太大则增加延迟；
使用DMA而非轮询读取，让CPU可以在后台做其他事，比如检查是否有唤醒词；
.use_apll = false 表示不使用音频PLL，因为PDM模式下APLL可能不稳定，实测反而影响同步。

安装完驱动后，就可以用非阻塞方式读取PCM流了：

uint8_t buffer[1024];
size_t bytes_read;

while (1) {
    i2s_read(I2S_NUM_0, buffer, sizeof(buffer), &bytes_read, portMAX_DELAY);
    // 此处可进行VAD、降噪、编码等处理
}

是不是很简洁？整个音频采集层就这样搭好了。

录音文件存哪儿？SPIFFS 还是 LittleFS？

接下来的问题更现实：我们不可能一直把PCM原始数据扔进内存。一段1小时的16kHz/16bit单声道录音，未压缩就有约110MB，而ESP32-S3常用的外部QSPI Flash通常只有4~16MB。

所以必须压缩 + 高效存储。

先说压缩。WAV格式直接pass，那是给调试用的。我们要的是 高压缩比、低延迟、低复杂度 的编码器。最佳选择是 Opus 。

Opus 是 IETF 标准化的一种开源音频编码格式，特别适合语音场景。它能在6kbps~40kbps之间动态调整码率，在12kbps下依然保持清晰可辨的人声质量。换算一下：1小时录音仅需约5.4MB空间，相比WAV节省了近95%！

虽然ESP-IDF没有内置Opus编码库，但可以通过组件管理器引入轻量版libopus（例如 idf-component-opus ），编译后体积控制在80~120KB左右，完全可接受。

再来说文件系统。

很多初学者喜欢用 SPIFFS，因为它简单、ESP-IDF默认支持。但它的致命缺陷是 缺乏断电保护机制 。一旦在写入过程中断电，很可能导致整个文件系统损坏，录音文件全部丢失。

对于一款要随身携带、可能随时被拔电池的设备来说，这是不可接受的风险。

所以我们转向 LittleFS ——一个专为嵌入式设计的、具备“断电安全”特性的文件系统。它采用日志结构（log-structured）设计，所有写入操作都是原子性的，即使中途断电也能恢复一致性状态。

更重要的是，它支持磨损均衡（wear leveling）。Flash每个扇区擦写寿命约10万次，如果每次都往同一个地址写录音文件头，很快就会坏掉。而LittleFS会自动分散写入位置，延长Flash寿命。

配置也很简单：

const esp_vfs_littlefs_conf_t conf = {
    .base_path = "/littlefs",
    .partition_label = "storage",
    .format_if_mount_failed = true,
    .dont_mount = false
};

esp_err_t err = esp_vfs_littlefs_register(&conf);
if (err != ESP_OK) {
    ESP_LOGE(TAG, "Failed to mount LittleFS");
}

然后就可以像普通文件一样操作了：

FILE *f = fopen("/littlefs/recording.opus", "wb");
fwrite(encoded_data, 1, encoded_size, f);
fclose(f);

再加上元数据管理（比如用 cJSON 存储时间戳、标签、时长），一套完整的录音管理系统就成型了。

如何做到“永远在线”却不烧电？

这才是真正的挑战。

你想啊，如果设备要响应“记一下”这种唤醒词，就必须一直开着麦克风监听。但如果全程以240MHz全速运行，别说待机几天，几个小时都撑不住。

那怎么办？

答案是： 分层唤醒机制 + 超低功耗协处理器（ULP）+ 深度睡眠

具体怎么做？

我们可以把设备的状态分成三级：

模式	功耗	CPU状态	可唤醒源
运行模式	~120mA	双核全开	-
轻睡眠	~5mA	CPU暂停，RTC运行	定时器、GPIO
深度睡眠	<10μA	几乎全关	RTC_GPIO、ULP、触摸传感器

平时设备处于 深度睡眠 ，整机电流压到10μA以下。一颗2000mAh的锂电池，理论待机时间超过 6个月 。

那么怎么唤醒呢？

这里有两种路径：

物理按键唤醒 ：按下录音键，触发RTC GPIO中断，立即唤醒主CPU；
语音唤醒 ：由ULP-FSM（超低功耗状态机）配合定时器周期性采集PDM麦克风数据，喂给一个极小的量化KWS模型（比如TensorFlow Lite Micro训练的MobileNetV1-Quantized），每200ms推理一次。

关键在于，ULP本身功耗极低（微安级），即使持续运行，平均额外功耗也不超过5mA。也就是说，你在享受“随时喊话唤醒”的便利时，付出的电量代价几乎可以忽略。

至于那个KWS模型，也不是随便找个大模型塞进去就行。我们必须做三件事：