很多 MCU 升级方案把「签名校验」当作终点，实际上它只是中间检查点。真正难的是链路：BLE 有 MTU 限制、USB 会掉线、UART 会丢字节。EdgeDeploy 就是把「包可信」与「包能完整到达」拆成两件事分别解决的那一层。
三条链路，同一套帧语义
EdgeDeploy v1 的协议语义与承载链路解耦：无论走 UART、原生 USB 还是 BLE，都使用固定帧头、CRC32、传输 ID、分片 ACK、丢包重试、断点续传、接收端重启恢复、提交结果重放和整包 SHA-256。差别只在分片大小与传输载体：BLE 通道把 512 字节的 EdgeDeploy DATA 拆成 128 字节的 GATT 写片，靠通知流重组、超时、取消与重试补齐。
| 链路 | 分片与载体 | 已完成的软件/实板验证 | 仍未验证 |
|---|---|---|---|
| 原生 USB | 序列包分帧，独立流解码器 + 共享加锁接收器 | COM6 从 3,504 字节断点续传并成功 COMMIT；序列 4 包七帧 DATA 完整安装；B 槽 Flash 回读 SHA-256 与发送包一致 | 掉电恢复、目视显示确认 |
| BLE（GATT） | 512 字节 DATA → 128 字节写片；固定 128 位服务/Request/Response UUID | ESP32-S3 加密写入/通知服务、NimBLE Host 复用、浏览器闭环 16/16 场景通过 | 真实射频与配对不在任务验收内 |
| UART | 按传输 ID 分片 ACK 与重传 | 框架测试覆盖；外接 UART 实传仍待验证 | 外接 UART 实传、掉电恢复 |
| Android APK | 系统配对 + 签名 EFP 文件选择 + 分片/重试/断点/提交 + 进度界面 | ARM64 构建、3 项协议测试、Lint 0 错误；APK 2,987,883 字节 | 真机配对、安装、重启健康确认、断线恢复与后台行为 |
断点续传和提交结果重放解决的是两个不同的失败
断点续传解决「写到一半断了」：传输 ID 与序号让接收端知道已经收了多少，重连后从偏移继续，而不是从 0 重来。提交结果重放解决「提交后不知道成功没有」：接收端重启后能回答上一次 COMMIT 的结果，避免主机重复提交或误判失败。
这两条都服务于同一个下游动作——只有当整包 SHA-256 与签名校验通过，C99 接收器才把完整 EFP 交给 A/B 包管理器，随后才是暂存、试运行、原子激活与 5 秒健康窗口确认。也就是说，传输层只保证「完整送到」，是否运行仍由 96 字节事务状态记录与三态机制决定。
现在已经验证到什么程度
微雪 ESP32-S3-Touch-AMOLED-1.75 是目前走得最远的实板：EF-106 记录它已从 ota_1 启动并保留 ota_0 原应用与完整 Flash 备份；EF-106D 的串口观察显示 COM6 复位后 7 个信号、2 条管线、4 个组件就绪，65 秒无复位，UI 任务最低剩余栈 7,576 字节。框架侧自动测试当前共 46 项，本机 44 项通过，另 2 项 Linux POSIX 与 SocketCAN vcan0 集成测试在非 Linux 主机按条件跳过。
需要说清楚的边界是：以上都是串口可见的软件行为，不等于整机通过。屏幕像素、手指触摸、外部传感器、掉电与长期运行尚未验收；Wasm 后端属于 P3 计划，尚未完成。把「编译通过」或「COM 口有输出」说成「产品可用」，是这类端侧项目最常见的自我误导。
这对赛道数据链路意味着什么
赛道日的现实是：设备已经在车上、线束已经走好，此时才发现某个信号解析有误，可用的补救窗口只有几十分钟。因此部署通道的价值不在「无线很方便」，而在可断点、可校验、可回退——包传一半断连不必重来，装上去不健康能在 5 秒内自动回到旧槽。
这与车载采集和复盘环节的诉求是一致的：SR-RaceBox 车载数据采集器 负责把姿态与位置数据完整落盘，SR-Data 圈速分析器 负责事后复盘，任何一次「改完就回不去」的更新都会让整段数据失去连续性。对 Toyota GR86 这类以 OBD 车速作为计时输入的场景尤其明显——计时口径一旦在更新中改变，同一条赛道（例如 宁波国际赛车场）的历史圈速就无法再横向比较。
FAQ
EdgeDeploy 和 OTA 是一回事吗？
不是。OTA 通常指整份固件的无线替换；EdgeDeploy 传的是签名的功能包 EFP，落地后要经 A/B 包管理器暂存、试运行与原子激活，且传输层自带断点续传与提交结果重放。
BLE 传固件为什么一定要拆成 128 字节？
因为 GATT 写片受 MTU 限制。EdgeDeploy 把 512 字节 DATA 拆成 128 字节写片，配合通知流重组与重传，才能在受限链路上保证完整性。
断点续传后还需要重新验签吗？
需要。整包 SHA-256 与 Ed25519 验签在接收端完成后才交给包管理器，续传只解决字节完整性，不替代来源校验。
现在能说 EdgeDeploy 已经量产可用吗？
不能。外接 UART 实传、掉电恢复、Android 真机配对与长期运行仍未验证，Wasm 后端属 P3 未完成项。
参考资料
- 项目 05 ——
D:/Backup/Documents/开发板侧端模型/EdgeForge自编译软件框架方案.md（V1.4，平台层五类接口、EdgeDeploy v1、MVU 与 P3 路线） - 项目 05 ——
D:/Backup/Documents/开发板侧端模型/DEVELOPMENT_TASKS.md（EF-105 / EF-105A / EF-105C / EF-106 / EF-106D / EF-114A 状态）
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复