EdgeHippo 硬件规格书

EdgeMemory-MVP 分册 01 | 载体:ESP32-S3 N16R8(Dev-B)+ N8R8(Dev-A) | v1.0(定稿) | 2026-10-26
本分册定义 MVP 阶段 EdgeHippo 的物理边界:双板规格、分区表(可直接替换)、容量账、形态矩阵、引脚分配、电源与 USB 拓扑。
EdgeHippo —— 边缘上的另一个你。它不提供算力,只提供「我是谁、我记得什么、我不该答什么」。
配套:00 号总纲(范围与决策)· 02 号固件规格(数据布局)· 06 号排期。

1. 型号与载体规格

项目EdgeHippo Dev-AEdgeHippo Dev-B
载体XIAO ESP32-S3(N8R8)ESP32-S3-DevKitC-1(N16R8)
Flash8 MB16 MB
PSRAM8 MB(Octal)8 MB(Octal)
MAC44:BD:8D:71:FA:C814:C1:9F:21:E9:80
设备 IDEME-71FAC8EME-21E980
MVP 形态γ 磁吸卡形态原型
(form=gamma-card)
β USB Dongle 形态原型
(form=usb-dongle)
板位说明Dev-A 作为 γ 磁吸卡形态原型,Dev-B 作为 β USB Dongle 形态原型,两者同为外设本体,能力差异仅来自容量与接口(Dev-A 8 MB / BLE,Dev-B 16 MB / USB CDC+MSC)。无 HOST / PERIPH 之分,无上下级关系(见 00 号总纲 ADR-018)
App 偏移0x300000(旧)→ 0x210000(方案 B 后 app1)0x410000(旧)→ 0x210000(方案 B 后 app1)
指示灯单色 LED GPIO21(低电平点亮)WS2812 RGB GPIO48
USBUSB-Serial-JTAG(内部 PHY)USB-OTG GPIO19/20 + USB-Serial-JTAG(共享内部 PHY,见第 6 章)
互联BLE(NimBLE,复用 link_mgr)|备用 UART1 GPIO17/18
板级配置boards/sdkconfig.xiao_esp32s3_n8r8boards/sdkconfig.devkitc_esp32s3_n16r8
两块板同为 EdgeHippo 外设本体。Dev-A 的稳态容量约 3,300 条(灌入上限 3,700 条,占 93.00% 会触发淘汰,回落至稳态),是 γ 磁吸卡形态原型;Dev-B 是 β USB Dongle 形态原型。两板对等、无上下级关系,能力差异仅来自容量与接口——形态不同而已,不是「一块做主控、一块做外设」(见 00 号总纲 ADR-018)。

2. 分区表(方案 B · 可直接替换)

方案 B 的定义:app 槽由 4 MB × 2(16 M 版)/ 2.94 MB × 2(8 M 版)统一压到 2 MB × 2,把 edgehippom 与 kb_static 合并为一个 edgehippom 分区。
依据:固件实测镜像体积 1,530,080 B = 1.459 MiB(历史实测产物名 edgemeshm_gateway.bin;产物命名已按 00 号总纲 §2.1 统一为 edgehippom-<board>-<ver>.bin);2 MB 槽余量 34–38%。方案 C(1.5 MB 槽,余量 1–4%)已实测否决,详见 00 号总纲 ADR-003。

2.1 EdgeHippo Dev-B(16 MB Flash)

文件:firmware/partitions_emgw_16m.csv

# EdgeHippo 分区表(16MB Flash —— ESP32-S3R8 + W25Q256JV)
# Name,   Type, SubType, Offset,   Size,     Flags
nvs,      data, nvs,     0x9000,   0x5000,
otadata,  data, ota,     0xe000,   0x2000,
app0,     app,  ota_0,   0x10000,  0x200000,
app1,     app,  ota_1,   0x210000, 0x200000,
edgehippom,  data, 0x40,    0x410000, 0xBE0000,

末段 0xFF0000–0x1000000(64 KB)保留,供 coredump 或后续扩展。edgehippom = 11.875 MB(原 7.875 MB,+51%)。原 kb_static 分区已并入 edgehippom,由固件内部分区管理(见 02 号分册第 6 章)。

2.2 EdgeHippo Dev-A(8 MB Flash)

文件:firmware/partitions_emgw.csv

# EdgeHippo 分区表(8MB Flash)
# Name,   Type, SubType, Offset,   Size,     Flags
nvs,      data, nvs,     0x9000,   0x5000,
otadata,  data, ota,     0xe000,   0x2000,
app0,     app,  ota_0,   0x10000,  0x200000,
app1,     app,  ota_1,   0x210000, 0x200000,
edgehippom,  data, 0x40,    0x410000, 0x3E0000,

末段 0x7F0000–0x800000(64 KB)保留。edgehippom = 3.875 MB(原 2.0 MB,+94%)。

2.3 改分区表的三条铁律

  1. 必须整片重烧,且必须赶在正式灌库之前。改前执行 esptool flash-id 确认实际 Flash 容量(esptool v5 用 flash-id,不是 v4 的 flash-info)
  2. 改后核对:sys.info 必须报出新的 edgehippom 大小;store.map 必须报出新的容量分布
  3. 先备份:Dev-B 现网有 4343 条真实遥测,改前用 eme kb export --backup 导出后再重烧
不可逆机理:app 槽变小 → app1 结束地址前移 → edgehippom 起始偏移改变 → 已灌入的记忆全部作废。分区不能向后增长,所以「先用别的方案、容量不够再改」不是免费选项。

2.4 槽位占用硬门槛(W0-06)

在构建脚本中加入检查,不允许静默超槽:

占用率行为说明
< 80%通过正常
80% – 90%告警(构建输出黄色提示,记录到 build log)提示固件正在膨胀,需评估
> 90%构建失败2 MB 槽的 90% = 1.8 MiB;一旦超过,OTA 会在现场失败

固件实测 1.459 MiB / 2 MiB = 73%。MVP 完整态预算:1.459 − 0.115(裁剪 cam/mic/gps)+ 0.06~0.10(TinyUSB CDC+MSC)+ 0.03~0.05(emlite)+ 0.01~0.02(调试) = ≈ 1.44–1.53 MiB,即 72%–77%。

3. 容量账(实测口径)

3.1 单条记忆的字节成本

组成字节说明
向量(int8 / 384 维)384离线算好后灌入;板上不做 embedding
摘要文本≤150UTF-8,截断用 em_utf8_cut
元数据(id / ts / flags / tags / src / len)48含 8 B 对齐头
记录主体小计582
HNSW 索引摊销(M=16 邻居 × 4 B + 层信息)≈80MCU 级建议改 IVF + graph 混合,见 02 号分册
每条目净成本66202 号分册 schema 以此为准
块对齐与 WAL 冗余摊销≈2684 KB 页对齐、记录头、删除标记
每条目有效成本≈930用于容量推算

3.2 分区容量推算

项目EdgeHippo Dev-B(N16R8)EdgeHippo Dev-A(N8R8)
edgehippom 分区11.875 MB = 12,451,840 B(3,040 页)3.875 MB = 4,063,232 B(992 页)
字节级布局见 components/edgehippom/SPEC.md §2.3 / §2.4(已逐行求和校验)
每条目存储成本648 B(记录 16 B 头 + 体 ALIGN4(32+150+64+384)=632)
12,000 条装载后记录区占用79.86%(跨页;低于 85% 淘汰线)—
稳态容量(策略层淘汰后)12,600 条3,300 条
灌入上限(96.1% 水位)见 SPEC.md §2.103,700 条(93.00%,触发淘汰)
Go/No-Go 判据 G1≥ 12,000 条(可行性门槛 8,000)
达标,余量 600 条
≥ 2,500 条
达标
勘误(v1.0 原推算作废,2026-10-26 修正):
原本表按「固定开销 = superblock 64 KB + WAL 512 KB = 589,824 B」推算,得出 Dev-B ≈12,900 条、Dev-A ≈3,700 条。这是错的,两处原因:
① 真实布局的固定区是 3 页 = 12,288 B(非 64 KB),加 WAL 512 KB 应为 536,576 B;
② 更致命的是:用本表自己的 930 B/条 去除可用 11,862,016 B,只得 11,204 条,与所写 12,900 条相差 1,696 条——原文算术不自洽。
处置:本表不再自行推算,容量账一律以 components/edgehippom/SPEC.md §2.10 为唯一权威。上表只保留结论数字,中间账一律转引。
[注意] 容量数字已三次收敛,本表仅为快照,不得当作定论引用
演进轨迹:930 B/条(v1.0,算术不自洽)→ 644 B/条、稳态 12,649(v1.1,记录头按 12 B)→ 648 B/条、稳态 12,346(v1.2,记录头实际为 16 B)。 每推进一层实现细节,数字就会变一次。本表的绝对值只用于说明量级与取舍,任何对外承诺、任何测试用例期望值,一律以 SPEC.md §2.10 的当前值为准。若两者不一致,以 SPEC 为准并在本表更新快照日期。
稳态 ≠ 灌入上限:灌满后策略层会淘汰到 75–85% 水位,所以「能灌进去」和「长期稳定持有」是两个数。对外与对内的容量口径一律用稳态值(Dev-B 12,600 / Dev-A 3,300),不要用灌入上限,否则会被实测打脸。
[注意] 记录区容量不是唯一上限,ANN 索引可能先满。真实容量上限 = min(记录区稳态, ANN 的 rec_cap),两者都须 > G1,否则会出现「记录区还有余量但已写不进去」。Dev-B 定案 rec_cap = 12,600(ANN 区已调整为 base 槽 128 页 + 增量日志 160 页 + IVF 96 页;扩槽前上限仅 12,059,距 G1 的 12,000 只差 59 条,属"表面达标、实际零余量")。改任一侧都必须重算并复核两侧边际差(Dev-B 现差 178 条 = 1.4%),只调一侧会让差拉大、复现"记录区有余量但索引先满"。
[高危] PSRAM 侧只剩 3 条余量。按 rec_cap = 12,600:PSRAM 占用 5,241,600 B = 4.9988 MiB,距 G3 上限 5 MiB(5,242,880 B)仅余 1,280 B——换算即 rec_cap 硬上限 = 12,603,定案值距上限只有 3 条。换算常数:rec_cap 每 +1 条 → PSRAM +416 B。
⇒ 任何上调(向量维度、ann_M、rec_cap)都必须重跑 PSRAM/DRAM 拆分。当前达标的前提是 IVF centroid 缓存(64×384 = 24,576 B)放在 DRAM——它只在查询开始时被顺序读一遍(约 0.6 ms),不是热数据;若放进 PSRAM 则超 G3 23,296 B。这条归属不是可选优化,是达标条件。
[注意] 淘汰是断崖不是线性:占用一旦超过 85% 淘汰线,策略层直接降至 75%,不是线性衰减。做容量规划时按断崖算,按线性算会系统性高估。
[好消息] 对外容量数字与 compact 风险已解耦:稳态口径取 12,600(受 ANN rec_cap 约束),而非记录区侧的 12,778。即使将来 compact 实测翻车、回滚记录区到 2,349 页,稳态仍是 min(12,645, 12,600) = 12,600,对外数字不变。因此本表数字不必等待 compact 实测即可对外引用。 前提条件:上述 Dev-B 占用 80.6% 的前提是 ADR-015 将时序区预算压到 0.4375 MB,且必须实现记录跨页。若维持旧时序预算,12,000 条将占 89.8%、稳态跌至约 10,022 条;若记录不跨页,则占 85.14%、越线后断崖淘汰、稳态仅 10,566 条(淘汰是断崖不是线性)。两种情形 G1 均不达标。

3.3 三项高杠杆容量优化(按量级排序)

序手段预期增益代价任务
1降维 / 量化:384d→256d,或 PQ/SQ 量化(384 B → 96–128 B)+50% ~ +150%召回率下降与延迟变化。判据:召回降 ≤5% 而容量升 ≥40% 则采纳W1-14
2时序区实测回划:L0 已决定放 PSRAM 不落 flash,L1 是分钟级聚合,实测很可能只需 0.5 MB+1,100 条无(纯回收)W1-15
3分区内动态比例:把「记忆库 / 时序区」比例改为 edgehippom 内部动态分配—无。以后调比例不用改分区表、不用整片重烧W1-16

对照:压 app 槽(方案 C)只有 +9.3%,且不可逆、有变砖风险。三项高杠杆的量级都远超它。

4. 产品形态矩阵 α / β / γ / δ

形态产品宿主接口目标价单位毛利MVP 状态
αEdgeHippo α
板载模组
UART / SPI¥99–149¥80MVP 无板级原型(Dev-A = γ 磁吸卡形态原型,Dev-B = β USB Dongle 形态原型,两块板均为外设本体)。α 出货后强制保留双槽 OTA——焊死在客户设备里没有救砖通道
βEdgeHippo β
USB Dongle
USB CDC + MSC¥399¥327MVP 主要交付对象(Dev-B 即其原型,form=usb-dongle)。唯一销量可达且不依赖单一大客户的形态
γEdgeHippo γ
磁吸卡
BLE¥799¥692P2 量产。贴手机背面的个人记忆卡;形态实测由 Dev-A 承担(form=gamma-card)
δEdgeHippo δ
SD 卡
SDIO——期权,不排期
β 形态是唯一「既是主权又是 IM」的形态,定为首个自销 SKU。
达成 ¥500 万毛利所需出货:α 需 6.25 万台|β 仅需 1.53 万台|γ 需 0.72 万台。硬件化把「必须绑定一家年出货百万级的设备厂」降级成了「万余台的可控目标」。

5. 引脚分配表

5.1 EdgeHippo Dev-B(DevKitC N16R8)—— β 原型

功能引脚方向 / 电气备注
USB-OTG D−GPIO19双向TinyUSB CDC + MSC。与 USB-Serial-JTAG 共用内部 PHY,见第 6 章
USB-OTG D+GPIO20双向
WS2812 RGB 指示灯GPIO48输出GRB 序,10 MHz。IDF v6.1 的 rmt_transmit() encoder 不可为 NULL(用 rmt_copy_encoder);config 必须 memset,不可 {0}
UART1 TX / RX(互联备用)GPIO17 / GPIO18输出 / 输入BLE 不可用时的降级通路
UART0 consoleGPIO43 / GPIO44输出 / 输入切 TinyUSB 后 console 改走这里,须常备 USB-UART 转换器
I2C(传感器扩展)TBD—P2,真实传感器接入时定
SPI(外部 Flash 扩展)TBD—δ 形态评估时用
VBUS 检测TBD(分压)输入S3 引脚 3.3 V 耐压,不能直接接 5 V。自供电场景必须处理

5.2 EdgeHippo Dev-A(XIAO N8R8)—— γ 磁吸卡形态原型

功能引脚方向 / 电气备注
单色 LEDGPIO21输出,低电平点亮注意与 Dev-B 极性不同
USB-Serial-JTAG内部 PHY—γ 形态不提供 USB 外设通路,保留原生串口用于烧录与 console
UART1 TX / RX(互联备用)GPIO17 / GPIO18输出 / 输入与 Dev-B 交叉连接
BLE片内—NimBLE;板间互联拓扑 1 usb-dongle + 2 gamma-card(原记作「1 gateway + 2 edge」,为板级角色表述)
两板互联:首选 BLE(复用现有 link_mgr,已实现 1 usb-dongle + 2 gamma-card 的互联拓扑);备用 UART1,交叉连接 GPIO17↔GPIO18、共地。NimBLE host 任务栈 ≥ 8192,否则周期自发重启。

6. USB 拓扑与 PHY 冲突(必读)

ESP32-S3 的 USB-OTG 与 USB-Serial-JTAG 共用同一个内部 PHY。二者不能同时工作。要并存必须二选一:
① 使用外部 USB PHY;② 烧 eFuse 把 USB-Serial-JTAG 永久切走。
这是 PCB 阶段必须决定的事项,事后不可改。

6.1 MVP 期间的应对

后果影响应对
不能再通过 USB 串口烧录首次烧录与排障路径改变用 UART0(GPIO43/44)+ USB-UART 转换器;或先烧 eFuse 前完成开发
不能再通过 USB 串口看日志console 通道改变console 改走 UART0;多任务共串口须单锁整行原子写(cmd_console_write + esp_log_set_vprintf)
救砖通道USB 挂了还能救保留 esptool-js / eme 串口刷写作为最终兜底

6.2 USB 设备形态(Dev-B)

类用途说明
CDC ACM行协议 / 日志 / eme 直连WebUSB 与 Web Serial 都基于此
MSC虚拟 U 盘,拖 .emf 灌库官方有现成 UF2 虚拟盘方案可参考。浏览器访问不了 MSC(见 ADR-009)
复合设备CDC + MSC 同时枚举ESP-IDF 官方已支持 TinyUSB 复合设备,示例 tusb_composite_msc_serialdevice
UF2 拖拽升级是 β 形态的第三个选项:拖固件和拖 .emf 用同一套交互,能再省 2.5 MB(可去掉 OTA 双槽)。但单槽写入中断会变砖。α 模组形态强制保留双槽 OTA,不采用 UF2 升级。

7. 电源与 VBUS 检测

场景供电注意事项
β Dongle 插 PC / 充电器USB 5 V → 板载 LDO 3.3 V标准场景,无需额外处理
α 模组焊入客户设备客户设备 3.3 V需确认客户电源纹波与峰值电流(PSRAM + Flash 并发写入时)
自供电同时插 USB双源必须检测 VBUS:S3 引脚 3.3 V 耐压,不能直接接 5 V,须分压或比较器。β 量产前必须处理
掉电测试台架程控电源 / MOS 开关TC-N-08 需要 100 次随机掉电,建议用继电器 + 脚本控制,不要手工拔线

8. 指示灯语义

状态灯效含义
就绪绿 / 橙 常亮库已打开,可查询
传输中蓝 快闪灌库 / 同步进行中
Wi-Fi 断红 2 Hz网络不可用(本地功能仍应可用,见 G6)
互联断黄 慢闪EdgeMesh 链路断开
未配对白 双闪等待配对

NVS 命名空间 emled2。Dev-A 为单色 LED,只能用闪烁频率区分,测试时以串口 sys.led 命令状态为准。

9. BOM 与采购

物料数量MVP 用量备注
ESP32-S3-DevKitC-1 N16R82Dev-B ×1 + 备用 ×1已有
XIAO ESP32-S3 N8R82Dev-A ×1 + 备用 ×1已有
USB-UART 转换器(CP210x / CH340)2Dev-B console(切 TinyUSB 后必需)需采购
程控继电器模块(掉电台架)1TC-N-08 随机掉电 100 次需采购,或用 MOS 开关自制
USB 电流/电压表1功耗测量可选
逻辑分析仪(8 ch)1UART1 互联排障可选,BLE 通则可省

9.1 量产阶段选型提示(不在 MVP 范围)

10. 硬件验收清单

ID检查项方法通过标准
HW-A1Flash 实际容量esptool flash-idDev-B = 16 MB;Dev-A = 8 MB
HW-A2PSRAM 可用量启动日志 + sys.info≥ 7.5 MB 可分配(Octal 8 MB)
HW-A3分区表生效sys.infoedgehippom = 11.875 MB(B)/ 3.875 MB(A);app0/app1 = 2 MB
HW-A4USB 复合设备枚举PC 设备管理器 / lsusbCDC + MSC 同时出现;不冲突
HW-A5MSC 拖文件灌库拖入 .emf≤ 60 s 完成,LED 蓝快闪 → 绿常亮
HW-A6console 走 UART0USB-UART 转换器日志完整、多任务输出不串行
HW-A7WS2812 灯效目测 + sys.led五种状态语义正确,颜色为 GRB 序
HW-A8BLE 互联link.scan / link.connect板间互联拓扑 1 usb-dongle + 2 gamma-card 可建立(原记作「1 gateway + 2 edge」)
HW-A9UART1 互联降级交叉连接 GPIO17/18BLE 关闭时仍可通信
HW-A10掉电台架继电器脚本 100 次台架本身可重复、可记录时刻