之前 OpenClaw 爆火的时候就在网上看到了一个可以在 ESP32-S3 上跑的替代版本，也是一个开源项目，叫 mimiclaw，纯 C 编写，资源需求比 OpenClaw 低很多。
周末的时候稍微花了点时间体验了一下，分享一下感受～
PS. 一开始我一直以为这个项目叫 miniclaw，后面在终端中一直进目录不能自动补全，才发现是 mimiclaw 😂。
项目地址： https://github.com/memovai/mimiclaw
mimiclaw 是一个基于 ESP-IDF 开发，可以运行在 ESP32-S3 开发板上的个人 AI 助理项目，支持 OpenAI 以及 Anthropic 的接口，基于 ReAct 循环，内置了一些工具和 SKILL。
基本的体验和 OpenClaw 没有特别大的区别，毕竟本身能力依赖于后端的模型使用哪一个，如果和 OpenClaw 使用同样的模型，在纯对话场景，不会有太大差距。
另外 mimiclaw 每次在使用 AI …
阅读全文 »
之前已经用 ESP32-S3 模块做了不少项目，会经常使用到 SPI 总线来驱动外设，想起来有两个坑需要注意，这里记录一下供大家参考～
两个坑都跟 GPIO 使用有关系：
ESP32-S3 有很多封装版本，N16R8 的意思是：板载 16MB Flash + 8MB PSRAM。听起来很香，内存大、Flash 大，DIY 项目首选。
但它有个代价：片内的 Octal Flash 和 Octal …
阅读全文 »
之前用 ESP32-S3 搞了个游戏机（见 成本60元，用ESP32-S3做个开源游戏机，能玩FC/NES、GameBoy，还有专属彩色PCB，啊好久远，已经是前年了 🙈），最近又拿出来把玩了一下。
然后想起来之前有人说能不能加中文支持，这样游戏 ROM 可以直接用中文名存在 TF 卡里，刚好现在 AI 这么厉害，完全就可以让 AI 来完成这个开发嘛 😃，顺便把固件版本更新到 retro-go 的最新版本。
原来的分支是从官方某个较早版本 fork 出来的，本身也修改不多，直接 rebase 来应用到最新的分支上。
git remote add github https://github.com/ducalex/retro-go.git
git fetch github
git checkout esp32s3-st7789v
git rebase github/dev # 当时执行的是 git rebase origin/dev我在 …
阅读全文 »
之前做了 ESP32-S3 上常见 JPEG 解码库（Tjpg_Decoder、JPEGDEC、ESP_NEW_JPEG）的性能测试，最终结论是 ESP_NEW_JPEG 在此前测试中表现最强（见 ESP32-S3 + Arduino 各种 JPEG 解码库速度对比，到底哪个才是最快的？、勘误：ESP_NEW_JPEG 更新到最新版后，所有分辨率都是最快的）。
但是上次是用的静态图片，每次解码都是同样图片数据，与真实使用场景会有差异，毕竟如果是使用 ESP32-S3 播放视频，每一帧的内容都是不一样的，解码时间也会有波动。
这次直接从视频里抽帧，模拟一下真实视频播放场景，看看在这个条件下能把 FPS 推到多高。
另外上次测试时也没有优化解码与传输步骤，理论上可以使用 DMA 实现 CPU 时间更有效的利用，这次也优化一下代码，对比看看效果。
那么这次测试在以下两个条件下，最终结果会如何？
先说结论：在 240×240 + RGB565 + SPI 40MHz 的配置下，最终逼近链路上限，实测约 40 …
阅读全文 »
上篇文章（见 ESP32-S3 + Arduino 各种 JPEG 解码库速度对比，到底哪个才是最快的？）测试了三个 JPEG 解码库的性能，最终结论是 ESP_NEW_JPEG 在低分辨率遥遥领先，但到了 240x240 和 320x240，被 JPEGDEC 追平。
结果最近想测试 ESP_NEW_JPEG 的 block 解码方式，发现怎么找都找不到对应的 API，这才意识到——我用的库版本根本不对 😅。
上篇文章用的是 Arduino 生态里的封装库 ESP32_JPEG，这个库最后一次更新是三年前，是对 ESP_JPEG 早期版本的封装，早就停止维护了。
乐鑫官方真正在维护的最新版本是另一个仓库：esp-adf-libs/esp_new_jpeg，五个月前还在更新，block 解码、最新的 SIMD 优化都在这里。
两个库同名，但版本差距已经是三年了，之前完全踩坑了 😂。
换成最新版 ESP_NEW_JPEG，测试环境与上次完全一致：
之前分享了使用 NMOS 驱动电磁铁通断来实现的段码时钟（见 电磁铁驱动的段码时钟找到解法了，先来一位试试），在评论区有朋友指出电路中电磁铁没有并联续流二极管，我之前虽然接触过这个概念，但是对于为什么要使用并没有很深刻的概念，并且似乎也没有出问题？
但是这肯定是有问题的，为了学习一下没有续流二极管有什么危害，还是来测试看看。
在原来的电路中，电磁铁连接在 12V 和 NMOS 的 Drain 上，通过 Gate 控制 NMOS 的导通，从而接通电磁铁，实现对段码上永磁铁的推动，实现段码的翻转。
在测试时使用 10V 对电磁铁进行供电，并且通过单片机对 NMOS 进行操作，在翻转段码时，对电磁铁进行接通 50ms 的操作。
然后示波器连接在 NMOS 的 Drain 上，观察电压变化。
未接续流二极管电压变化
可以看到在关闭 NMOS 的瞬间，有一个极高的尖刺出现，示波器显示电压为 37.6V，这理论上已经超过了 NMOS 的工作电压 😂。
放大看可以看到这个电压持续了 300us 再逐渐降低到正常工作电压的 10V。
顺便向 AI …
阅读全文 »
电磁铁段码时钟这个项目还是年初的时候在 Instructables 看到的，中间尝试过复刻，但是有两点实在有点麻烦就一直没弄：
然后最近逛淘宝发现了有现成的线圈卖，买了测试一下，还真可以推动 5x2mm 的圆形永磁铁了，这下可以开始搞一搞了。
这里因为是放在桌子上拍的，段码翻转声音会比较大，实际竖着放的时候会好一些。
PS. 拍视频的时候左上角那个段有一个电磁铁坏了，所以最后可以看到它没有翻转成黑色 😃。
在找 DeepSeek 学习了一大圈之后，终于对电磁铁明白一点点，需要足够多的匝数，才能会有大一点的磁性。
然后就找到了这个商品，应该是顺着别人做磁悬浮的配件找到的。
买回来之后把铁芯敲掉就可以了。
之前还买过下面这两种，测试的时候完全推不动 5x2mm 的圆形永磁铁，因此从年初到现在都没有折腾过。
原项目使用了达林顿管还有移位寄存器什么的组合起来控制，我觉得比较麻烦，板子也太多了。
在拿到电磁铁线圈之后，就想着既然是控制通断，是不是可以直接用 NMOS 就可以了。直接用零件搭了个测试电路，完全可以把圆形磁铁推开，那就开始画块板子吧。
直接最省事的做法了，MCU 的 GPIO 直接控制 NMOS Gate，电磁铁线圈接在 Drain 上，通过短暂开启 GPIO，就可以让电磁铁产生磁力推开特定的段码。
这里使用 NMOS 而不是 PMOS 来控制电磁铁通断，是因为如果电磁铁需要更大推力，需要更高的电压，测试了在 10V 的时候效果比较好，因此如果需要 MCU 3.3V 的 GPIO …
阅读全文 »
二值化黑白图像展示
灰度抖动图像展示
之前使用 ESP32-S3 + 12864 OLED 做了个串流小电视（见 桌面小电视新思路，ESP32-S3 + 12864 OLED 串流视频），通过网络发送视频帧的方式来播放视频。
因为 12864 OLED 是一个单色显示屏，因此在播放视频时，整个画面的颜色通过“灰度化->二值化”的步骤来生成黑白纯色画面，在视频中可以看到画面没有层次和细节，不太容易看清画面内容是什么。
因此我们需要引入灰度来让整个画面更加丰富，但是在 12864 OLED 没有灰度的情况下如何显示灰度信息呢？
在这里我们就可以引入一种特别的显示技术——抖动 (Dithering)，它能让单色屏幕拥有显示4阶灰度的能力。
抖动，它的原理却非常直观，相当于通过大脑形成一种视觉错觉。
在单色屏幕上，只有纯黑和纯白的像素。抖动的核心思想就是：通过改变像素点的排布密度，来模拟出不同程度的灰度。
举个最简单的例子，如果你仔细观察报纸上的照片，你会发现那些“灰色”的部分，其实是由许多大小不一或疏密不同的黑色墨点组成的。在远处看，这些墨点混合在一起，就形成了我们看到的灰度。旧式的点阵打印机也是同样的原理，通过打印点的疏密来表现深浅。
抖动就是利用人眼的这种视觉混合效应。当我们观察一个由许多纯黑和纯白像素组成的区域时，如果这些像素非常小并且排列得足够紧密，我们的大脑就会将这些黑白像素的混合视为一个统一的灰色。像素点越密，看起来就越黑；像素点越稀疏，看起来就越白。
我们通常说的灰度，可以有 256 级，甚至更多。但是通过抖动模拟出的灰度，其实是牺牲了有效分辨率换来的。
对于 12864 OLED 来说，原生的黑白分辨率是 …
阅读全文 »
之前搞了个小电脑使用 ESP32-S3 + OLED 显示视频（见 3 步从 nana banana AI 生成的复古小电脑到真实桌面小玩具），但是受制于 Flash 空间有限，只放了 10 秒。
后来就想到是不是可以 ESP32-S3 只作为一个播放设备，视频数据从电脑上串流过去，而且在 ESP32-S3 支持这样串流的能力之后，理论上可以显示任意想要显示的信息，例如作为电脑的小副屏。
说干就干～
因为屏幕使用的是 OLED，分辨率是 128x64，颜色是单色， 单帧数据只需要 128x64/8 =1,024 字节，即使串流 30 FPS 也只有 30 KB/s 的流量，因此在电脑端直接发送完整屏幕数据是完全可以接受的。
并且大部分图像处理工作都在电脑端处理完成了，ESP32-S3 的固件在实现渲染时压力就会小很多，只需要 接收数据->写入 OLED 显存 即可。
通信协议为了省事，直接使用 WebSocket 了，这样直接一个消息就是一帧数据…
阅读全文 »
之前买了个血氧仪，带蓝牙数据传输功能，想使用它监控一下整晚睡眠时的血氧。
但是在使用时才发现，如果想要持续监控，配套的 App 需要一直在前台保持激活状态，就是手机不能息屏，浪费电不说，在后续查看数据时发现 App 中查看也不太好用。
这时想到它既然是使用蓝牙传输数据的，那大概率是直接用了 BLE，如果传输没有加密的话，那不是可以直接用 ESP32-S3 直接来读取一下，再转发到 MQTT 服务器，就可以实现全天的血氧监控了，而且可以有全部数据点的详细数据。
注：本文仅供学习研究与互操作性分析之用。请仅在对目标设备与数据拥有合法权利或已获明确授权的前提下使用。禁止用于未授权访问、数据窃取、绕过安全机制等违法用途；一切后果由使用者自行承担。
说干就干，先在电脑上用 BLE 测试软件看看能不能抓到一些数据。
将手指放进血氧仪，待数据稳定之后，打开 Lightblue 看看能不能找到设备～
很快就找到一个 PC-60F 打头的设备。
可以看到这个设备，有一个 Notify 的 Character，看看这个是不是
可以看到在订阅这个 Character 之后，血氧仪在一直发送数据，这时把这些数据日志保存下来，看看能不能找到血氧数值在哪条消息里。
好吧，其实我用了一个笨方法，通过观察血氧仪的读数，再在日志中查找对应的数字，一般来说，血氧最大值 100%，那么用一个字节就可以表示了，应该是可以直接搜索到的。
在观察过程中，血氧仪显示 97%，那么在日志中搜索对应的 16 进制数 0x61：
截取这段中有 3 条数据出现了 0x61，但是前一个字节不太一样，分别是 0x01 和 0x02，这个时候可以选择再继续观察后续数据，来确认哪一个是上报的血氧数据。
但是我选择了对比一下心率，当时看到的心率是 81，对应 16 …
阅读全文 »
近期评论