weixin_46555120的博客

原创 ESP32-S3 USB 变声器实作｜INMP441 I²S 收音与 Wi-Fi 网页控制

我用 ESP32-S3 和 INMP441 搭了一个 USB 变声盒。数字麦克风经 I²S 送入语音，芯片按块完成变声，再以 48 kHz、16 位单声道 USB 麦克风的形式供电脑录音。网页通过局域网切换 12 档预设，控制音高、增益和静音，设置保存在设备上。本文给出接线、固件入口和实际调试顺序。录音与耳机返听已在 Windows 验证，手机 USB 录音兼容性和音效听感仍在继续测试。

原创 ESP-Mosaico 轮滑动画编排台：拍点吸附、完整动作编辑与工程保存

做音乐驱动动画时，自动分析可以先排出一条动作序列，但“这个转体往后挪一拍会不会更合适”，仍然要反复听和看。早期我直接修改轮滑项目里的参数，再等待它播放到对应位置。问题出在歌曲中间时，观察和修改之间的间隔尤其明显。我给这个黑胶轮滑项目做了一个电脑编排台：先单独查看动作，再拖进音乐时间线，调整位置和拍数，最后保存为能够继续编辑的工程。本文重点记录时间线背后的数据规则，以及为什么没有照搬视频剪辑软件的自由裁切方式。

原创 ESP-Mosaico 音乐驱动动画：节拍检测、RMS 包络与预制动作编排

黑胶轮滑动画里，播放音乐和让人物跟音乐配合，需要不同的处理。本文以当前电脑端工程为例，拆解拍点、打击起音、音量包络和局部节奏的用途：时间信息参与动作重音，RMS 包络影响轨迹基宽，局部拍速与鼓点密度参与预制动作选择。再说明连续转体和跳跃为何需要限制重定时，以及如何用音频采样位置统一画面。配套素材来自实际 C 渲染器，包含原创器乐预览、真实分析图和冻结编排的音量控制变量对照。

原创 ESP-Mosaico 黑胶轮滑动画与音乐编排：从设备原型到电脑预览工作台

我做了一个以黑胶唱片为舞台的轮滑动画项目：人物沿唱片滑行，动作与音乐配合，脚下轨迹和落地特效参与表现。开发过程中，单纯增加动作数量没有解决僵硬的问题，反复烧录也影响了修改效率，于是又增加了电脑端动作编排与预览工具。本文作为系列第一篇，介绍项目目标、当前架构、真实修改流程与排查顺序，并说明电脑端功能和实机版本的区别。动作衔接、音乐卡点与歌词同步将在后续分别展开。

原创 ZeroClaw 是什么？与 ESP-Claw 的区别及文件整理用途示例

ZeroClaw 是用于搭建个人 AI 助手的开源软件。本文先用“读取笔记，生成选题清单”的例子说明用途，再结合此前在 ESP-Mosaico 上使用 ESP-Claw 的经历，对比两者的运行环境、工具与任务。ESP-Claw 已有个人上手记录；ZeroClaw 尚未本机实测，文中的文件整理和按键灯光任务均为需要配置的用途示意。

原创 ESP32-S31 WASM 应用开发实录：重力弹球从电脑预览到 ESP-Mosaico 实机测试

这次最有价值的结果不是一颗球能在屏幕上滚动，而是开发通道经受了一次从作者视角出发的完整试用：电脑预览缩短逻辑调试回路，真实设备指出轴向与手感问题，版本更新后再复测。

原创 ESP32-S31 WASM 应用怎么开发？本地工作台从示例、Manifest 到构建预览

作者在详情页能提前核对应用名称、作者、版本、简介和权限，而不用等正式上架才发现信息填错。走通这条路径后，可以继续看场景计时器、可选外设输入和 Rust 存储示例，分别学习定时重绘、外设缺失时的降级，以及跨启动保存状态。ESP32、ESP32-S31、WebAssembly、WASM、嵌入式开发、WASI SDK、C 语言、Manifest。正式项目的 ID、名称、作者和最低平台版本都要与实际内容对应。开发者包只包含公开 SDK、示例、工具和投稿说明，不包含平台签名私钥，也不会直接修改线上应用目录。

原创 ESP32-S31 项目如何制作 Windows 一键烧录包：完整镜像、esptool 与数据边界

├─ 一键安装.bat # 首次安装入口├─ 检查烧录包.bat # 只校验，不写设备├─ 初始化外置NAND.bat # 按需单独初始化存储├─ 开始使用.md├─ 新手安装说明.md├─ 硬件支持说明.md│ ├─ merged-binary.bin # 首次安装使用的完整镜像│ └─ esp_mini_platform.bin # 后续 OTA 使用的应用镜像└─ tools/└─ esptool.exe # 随包携带的便携版工具这是结构摘录，不是发布包中的全部文件。

原创 ESP32-S31 上做可在线安装的 WASM 应用平台：0.4.9 Beta 发布

ESP Mini App Platform 0.4.9 Beta 已经把系统界面、WebAssembly 运行环境、应用包、权限与私有数据、在线目录和系统更新连成一条使用路径。本文介绍这次发布交付了什么、系统与应用如何分层、首次安装与 OTA 的区别，以及目前仅直接支持 ESP-Mosaico／ESP32-S31 的硬件边界。本文是版本发布说明，不是烧录命令教程。

原创 ESP32 固件 OTA 设计：双 OTA 分区、升级前预检与启动健康检查自动回滚

固件升级的安全感不来自"下载成功"，而来自"就算这次失败，设备也知道该回到哪里去"。双分区提供退路，预检确认退路存在，启动健康检查决定是否确认，回滚由 bootloader 兜底——这四层合起来，才把"新固件起不来"从意外变成一个可预期的状态。预检通过才允许开始下载。应用安装失败的影响是局部的：坏包验签不过就不会进入存储，即使已安装的 App 出错，平台固件仍在，可以卸载重装。，模拟成功与各接口失败：正常分支 23/23、强制回滚分支 11/11，另有 10 项 OTA 启动记录构造测试。

原创 ESP32 在线应用目录设计：用腾讯云 COS 托管 index.json 与签名 .app

不搭复杂后端，如何让 ESP32 在线发现和安装 App？本文给出基于腾讯云 COS、`index.json`、内容寻址文件、NAND 下载事务、语义版本和签名验证的完整设计与实机边界。

原创 ESP32 WebAssembly 小应用存储隔离：App ID、NVS 命名空间与写入配额

在 ESP32 上运行多个可安装的 WebAssembly 小应用时，只给应用增加一个storage权限并不能解决数据隔离问题。所有应用最终仍然共用同一块 Flash，平台必须决定数据属于谁、怎样防止同名键冲突、哈希碰撞时如何拒绝访问，以及怎样避免单个应用耗尽 NVS 或频繁擦写 Flash。本文介绍 ESP Mini App Platform 当前的应用数据设计：WASM 只调用kv_get和kv_set；

原创 ESP32 WebAssembly 小应用权限模型：Manifest、API 检查与资源配额

本文拆解 ESP32 WebAssembly 小应用权限模型：Manifest 权限声明如何被签名保护，WAMR 加载阶段如何限制导入和内存，以及系统 API 如何检查显示、触摸、存储权限与资源配额。

原创 ESP32 WebAssembly 应用包设计：EMAP v1、Manifest、SHA-256 与 ECDSA 签名

本文介绍 ESP32 WebAssembly 小应用的 EMAP v1 安装包格式，包括 16 字节头部、Manifest、SHA-256、ECDSA P-256 签名、设备端验证顺序、写入回读和双槽更新设计。

原创 ESP32 WASM 宿主 API 设计：硬件隔离、权限校验与事件模型

在 ESP32 上加载 WASM 模块，只能解决“应用代码能够执行”的问题。要让应用绘制界面、接收触摸、读取时间和保存数据，还需要一层连接 WASM 与原生固件的宿主 API。本文结合一个实际运行在 ESP-Mosaico / ESP32-S31 上的小型应用平台，介绍为什么不能把底层硬件直接交给应用、当前 ABI v1 开放了哪些函数、触摸事件怎样分发，以及系统怎样检查权限、坐标、线性内存地址和调用配额。

原创 ESP32 如何运行 WebAssembly：WAMR、宿主接口与小应用执行链路

ESP32 的 CPU 不认识 WASM，它通过原生固件中的 WAMR 加载 WebAssembly 小应用，再借助受限宿主接口使用屏幕、触摸与存储。本文完整拆解这条执行链路及其边界。

原创 我把 ESP32 做成了一个“小型应用平台”：从整包固件走向可安装应用

我尝试在 ESP32 上建立“小系统 + 小应用”的运行方式：应用可以独立安装、启动和更新，系统负责屏幕、触摸、网络、存储与升级。本文介绍项目动机、三层架构、应用安装流程和当前进度。

原创 ESP-Mosaico 桌宠为什么会误睡？AS312 PIR 原理、休眠逻辑与排错方法

我用 ESP-Mosaico 和 Interaction V0.2 交互板做了一个“有人靠近才醒来”的桌面小精灵：检测到活动时睁眼并亮灯；一段时间没有活动，先进入困倦表情，再关闭屏幕。实测时出现了一个容易被误判为 Bug 的现象：人还坐在桌前，小精灵有时却睡着了。原因不一定是漏读，也不一定是 PIR 损坏。

原创 GY-33 颜色传感器原理详解：RGBC 采样、黑白场校准，以及它与摄像头的区别

GY-33 不是低分辨率摄像头。它不提供图像、物体轮廓和位置，只提供局部测色区域的光谱通道强度。它的优势正是数据小、处理轻、响应直接，适合固定条件下的颜色分类。要让结果稳定，需要把传感器、算法和机械结构一起设计：黑场扣底值、白场平衡通道、滑动平均减少跳变、测色通道稳定光路。很多看似分类算法的问题，根源其实在光源和结构。

原创 ESP-Mosaico 接入 GY-33：UART 颜色读取、黑白场校准与 8 帧滑动平均

黑场用于扣除环境底值；白场用于校正三个通道的响应差异；8 帧滑动平均用于压制瞬时波动；固定测色通道用于控制距离和环境光；弱光阈值用于判断未检测到物体。完成这些步骤以后，ESP-Mosaico 不再只是显示 RGB，而是形成了从外部感知、数据处理到界面反馈的完整应用链路。后续还可以把颜色结果接入 ESP-Claw，让设备回答当前颜色，或把不同色卡映射成灯光、音乐和自动化指令。

原创 ESP-Mosaico 上手 ESP-Claw：浏览器烧录、2.4GHz 配网与阿里云百炼 qwen3.7-plus 接入

ESP-Mosaico 上的 ESP-Claw 不是“大模型在微控制器里独立运行”，而是设备本地运行时与云端模型的协作系统。完成固件烧录、2.4GHz 配网和 LLM 配置后，ESP-Mosaico 就拥有了对话、记忆和工具调度的基础框架。真正决定使用体验的，则是模型能力、设备身份描述、工具集合和本地规则能否彼此对齐。这次我最终跑通了阿里云百炼。下一步准备继续测试 ESP-Claw 的 Skill、Lua 和 MCP，让屏幕、音频、IMU 与网络能力真正进入可被对话调用的工作流。

原创 ESP-Mosaico 掌上游戏开发：LVGL 抛硬币动画、音频混音与 BMI270 摇晃触发

使用 LVGL 定时器和二维对象实现 1.5 秒抛物线运动、上下翻面、落地摆动与金币散射；使用 FreeRTOS 音频任务和队列管理背景音乐、抛掷音效与结果音效；使用 BMI270 相邻采样变化量、连续命中和冷却机制实现摇晃触发。文章还会说明为什么触摸与 IMU 必须进入同一状态机入口，以及动画对象生命周期、音量持久化和音色设计中遇到的实际问题。精简字库没有包含动态提示中的字符。需要让覆盖所有标题、按钮、结果文本和错误提示。LVGL 定时器负责连续画面；抛物线与高度压缩负责运动感；

原创 ESP-Mosaico 实战：基于 ESP32-S31 开发一个掌上抛硬币游戏

拿到 ESP-Mosaico 后，我没有停留在点亮屏幕、读取传感器这类单项测试，而是直接做了一个可以完整运行的掌上小游戏。基于esp32-Mosaico开发的掌上小游戏项目的玩法并不复杂：点击屏幕上的硬币进行抛掷，硬币经过上升、上下翻转、下落和落地摆动后显示太阳面或月亮面。应用还包含不同模式、自动连抛、背景音乐、独立音效、音量设置、状态保存和 IMU 动作触发。480×480 屏幕与 LVGL 图形界面；电容触摸输入；BMI270 IMU；ES8311 扬声器音频输出；

原创 ESP-MOSAICO V1.0

原创 一颗LED灯＋8位单片机＋滚珠开关：做一个“一碰就亮”的发光盒

最近我做了一个很小的桌面发光盒。它平时处于休眠状态，把盒子拿起来再轻轻放下，正面的“白搞电子”四个字就会亮起。灯光持续几秒后自动熄灭，再次触发时会切换另一种灯光效果。这个项目的电路并不复杂，真正花时间的反而是外壳、电路板固定和光线扩散。发光盒演示视频。

原创 机械键盘空格键和D键同时失灵：从轴体复位、焊盘飞线到LED故障定位

机械结构：D键轴体歪斜；PCB连接：空格键焊盘及线路断开；电子器件：D键LED灯珠损坏。

原创 ESP32-S3流体灯板优化：去掉ESP-DL，改用传统视觉追踪与按键切换灯效

上一版AI流体灯板已经能够在ESP32-S3上完成OV2640摄像头采集、ESP-DL手势识别，并通过UART控制另一块ESP32-S3上的HUB75流体灯效。项目虽然跑通了，但完整手势识别链路约为262～263ms，折算下来只有约3.5Hz。对one、two、five、ok这类离散手势来说尚可接受，但用检测框估算手部位置时，灯板的跟随效果明显不够连续。重新梳理需求后，我决定在下一版中暂时移除ESP-DL：视觉板只负责追踪手的位置和移动趋势，灯效模式改由实体按键切换。

原创 做端侧 AI，ESP32 到底怎么选？从 S3、S31 到 P4 的工程选型方法

如果只想先把小模型跑通，S3 仍然是稳妥起点；希望在单板上整合摄像头、显示和无线，可以关注 S31；项目进入高分辨率视觉、视频和复杂 UI 后，再考虑 P4。当任务规模明显超过 MCU 边界时，直接换 Linux SoC 或 NPU 平台，比继续压缩模型更符合工程实际。选择 ESP32 端侧 AI 芯片时，推荐使用这样的顺序：任务类型 → 输入数据量 → 目标延迟 → 无线与显示 → 内存和媒体接口 → 软件生态 → 芯片价格。

原创 ESP32-S3不用神经网络也能追踪手指：颜色分割、连通域与坐标平滑

优点是稳定、抗少量噪点；缺点是得到色块中心，不是实际末端。

原创 ESP-DL到底是什么？从OV2640到手势结果，拆解ESP32-S3端侧推理链路

PC端采集/训练-> 导出ONNX或PyTorch模型-> ESP-PPQ量化与转换-> 生成.espdl-> 嵌入固件/分区/存储卡-> ESP-DL加载和推理ESP-DL 支持面向目标芯片的 8 位或 16 位量化模型。我的项目没有自行训练，而是使用乐鑫官方提供的手部检测与手势分类组件。ESP-DL 不是“一个会识别手势的库”，而是让量化神经网络能在 ESP 芯片上运行的推理基础设施。一条完整端侧 AI 链路至少包含四层：传感器输入、模型、推理框架、应用逻辑。

原创 ESP32-S3双板实现AI流体灯板：OV2640端侧手势识别＋HUB75粒子灯效

经过USB摄像头、OV2640裸模组和网页预览等几轮尝试，我终于把这套AI流体灯板的端侧链路跑通了。当前版本不依赖电脑和云端。OV2640采集画面后，第一块ESP32-S3运行ESP-DL完成手部检测与手势分类，再通过UART把手势和坐标发给第二块ESP32-S3。第二块板负责粒子流体计算，并以约30 FPS刷新64×64的P2.5 HUB75E灯板。本文记录最终架构、手势映射、实际识别速度、端到端延迟，以及过程中几个比较关键的工程取舍。

原创 ESP32-S3 MultiNet新增离线语音指令完整教程：Command ID、拼音注册与动作映射

ESP32-S3已经能识别“打开电灯”和“彩虹模式”，如果还想增加一句“恢复亮度”，需要重新训练MultiNet模型吗？在本文使用的工程里，答案通常是否定的。命令短语 → Command ID → 实际执行动作芯片：ESP32-S3-N16R8；中文MultiNet模型；启动时通过API注册命令词。不同ESP-SR版本的接口和命令格式可能不同，请先确认自己工程使用的是运行时API、命令文件还是menuconfig配置方式。定义新的Command ID；

原创 ESP32-S3＋OV2640端侧手势识别实战：关闭网页、双核调度与看门狗排查

上一篇折腾OV2640时，我买的是“裸摄像头＋24Pin转接板”。真正接线以后才发现，那块转接板只负责把FPC触点引出来，并不会自动补齐OV2640需要的AVDD、DVDD、DOVDD以及相关配套电路。这一次，我换成了带摄像头插座和配套电路的完整OV2640模块板。模块接入ESP32-S3后，网页终于出现了实时画面，ESP-DL也能识别张开的手掌。但网页跑通以后，我又做了一个看似反常的决定：把Wi-Fi、HTTP服务和网页预览从正式固件中全部移除，让ESP32-S3只负责采集、识别和输出结果。

原创 ESP32-S3 离线语音识别原理：AFE、WakeNet、MultiNet 完整链路与排错方法

AFE：把声音整理好；WakeNet：判断现在要不要开始听命令；MultiNet：判断听到的是哪一条预设命令。ESP-SR 则负责把这些能力组织成一套可以在 ESP32 上本地运行的语音方案。理解这条链路后，灯带只是输出端之一，最后一步也可以换成继电器、电机或其他执行器。

原创 我又一次翻车：一块24Pin转接板，为什么接不动OV2640？

本以为买一个OV2640，再加一块24Pin FPC转接板，就能接入ESP32-S3。真正开始核对电路后才发现：我解决的只是接口形式，摄像头需要的三路供电依然没有着落。

原创 ESP32-S3 连接 USB 摄像头完整排错：从 VBUS 只有 0.5V 到 UVC 接口不兼容

我一度准备剪开摄像头 USB 线，单独连接 5V、GND、D+ 和 D-。USB 线芯颜色未必绝对可靠；D+、D- 不适合使用过长的杜邦线；外部 5V 与电脑 USB 处理不当可能反向灌电；开发板引脚与原生 USB 数据线的连接关系需要先确认。在动剪刀之前，我重新检查了开发板正反面。板子型号为，背面两个 USB-C 接口附近有一组标记为USB-OTG的焊盘。这组焊桥默认断开。闭合后，COM 口从电脑获得的 5V 会被送到原生 USB 口，为 USB 外设提供 VBUS。

原创 一次大更新：LED 灯板模拟器 V1.4.4，支持图片、视频和音乐律动

最初做这个软件时，我只想解决一个很实际的问题：真实 LED 灯板还没接好，ESP32 发出的 RGB 数据到底对不对？现在它不只是一个查看串口数据的小工具了。到了 V1.4.4，它已经可以把图片、视频和音乐送进一块可配置的虚拟 LED 灯板里，用来提前验证画面、映射和灯效。

原创 ESP32-S3接USB摄像头还是OV2640？USB Host、UVC、DVP与实测计划

我之前做了一套AI视觉流体灯板：USB摄像头连接电脑，电脑使用MediaPipe识别手势，再通过串口把手势和坐标发送给ESP32-S3，最后由ESP32-S3计算流体并刷新P2.5灯板。USB摄像头 -> 电脑（MediaPipe） -> 串口 -> ESP32-S3 -> P2.5灯板这套方案能用，但离不开电脑。现有USB摄像头 + ESP32-S3 USB Host；OV2640 DVP摄像头 + ESP32-S3并行摄像头接口。

原创 ESP32-S3 AI视觉流体灯板脱离电脑的三阶段升级方案

这篇文章介绍了一个手势控制流体灯板项目的分阶段升级计划。项目当前依赖电脑进行手势识别，下一步目标是将视觉处理迁移到ESP32-S3视觉板实现独立运行。将升级过程拆分为三个阶段：1) 验证摄像头采集和网页预览；2) 加入板端手势识别并通过串口控制显示板；3) 关闭调试功能实现独立运行。文章详细说明了每个阶段的技术要点、验收标准和设计思路，并解释了采用双ESP32-S3架构的原因（视觉板+显示板分工）。这种分阶段验证方法能有效隔离问题，降低调试难度，为后续可能的单板集成奠定基础。项目涉及摄像头驱动、图像处理

原创 ESP32-S3 驱动 64×64 P2.5 LED 灯板：HUB75 通信、位平面与刷新时序详解

本文深入解析了ESP32-S3驱动HUB75 LED灯板的底层原理。与WS2812B不同，HUB75需要外部持续扫描，通过RGB数据线、CLK时钟、LAT锁存、OE使能和行地址信号协同工作。文章详细介绍了64×64 1/32扫描面板的数据传输流程：将RGB888颜色拆分为8个位平面，通过512个CLK脉冲移入64列数据，锁存后由行地址选择显示行。文中还澄清了8MHz时钟、约100Hz刷新率和30FPS画面更新率的区别，并说明驱动库如何自动完成坐标映射、位平面拆分和时序控制。理解这些底层机制有助于快速排查显示