小龙虾
2138a572ee
- 新增多电机状态、版本和OTA中继监控模块（monitor/motor_state.cpp, monitor/motor_version.cpp, monitor/motor_ota_relay.cpp） - 在CAN反馈任务中添加0xC5/0xC6/0xD2类型消息处理，支持多电机状态推送 - 重构调试日志系统，将一次性JSON分配改为512B栈缓冲流式发送，降低内存峰值 - 调试UART波特率从115200提升至30000 - 修改版本管理方式，从自动生version.h改为手动维护 - 更新VSCode设置以支持ESP-IDF开发环境配置 - 在OTA协调器中添加电机OTA互斥机制，防止并发冲突 - 完善中继状态机异常处理，添加远程取消通知机制
4.2 KiB
4.2 KiB
目标
把电机 OTA 从"收固件+触发喂数据"一步式，改成 BLE 刷 GD32 那样的两段式：先收完固件写 flash，再单独触发 SPI START + 喂数据。拆分后收固件阶段不碰 SPI，避免与 GD32 按铃推送竞态；触发阶段只发一个短小的 SPI 0xD0。
改动点（共 4 个文件）
1. main/server/http_handlers.cpp — 拆分上传 + 新增 relay 触发
motor_ota_upload_handler（line 2057）改：
- 保留：互斥检查、
beginWriteSession、流式收固件写 flash（flashWriteChunk循环）、beginWriteSession复位 - 删除：末尾的
motorOtaStart(...)调用（line 2128） - 收完后写 meta：
metaSave({total_size=content_len, stored_size=received})，让 relay 端点能确认固件完整 - 返回改为
{"status":"stored","message":"call POST /motor/ota/relay?ch=X to trigger","channel":ch,"size":received}
新增 motor_ota_relay_handler：
- 从 query 读
ch（和上传端点一致） Gd32FlashStore::metaLoad确认stored_size >= total_size，否则返回 400firmware not fully storedmotorOtaIsActive()检查，已在跑则 409- 调
motorOtaStart(meta.total_size, ch)：- 0 →
{"status":"ok","message":"OTA started"} - -2 → 409
already in progress - -3 → 500
SPI start failed（保留原日志 DEBUG_ERR）
- 0 →
- 成功触发后清 meta（
metaClear），固件已交给 feedTask，避免残留
2. main/server/wifi_ota.cpp:482 — 注册新路由
路由表加一行：
{"/motor/ota/relay", HTTP_POST, motor_ota_relay_handler},
（紧挨现有三个 motor/ota 路由，CORS preflight 复用现有循环自动处理）
3. main/server/http_handlers.h — 声明新 handler
加 esp_err_t motor_ota_relay_handler(httpd_req_t *req);
4. tools/motor.html — 前端两段式调用
startOta（line 2986-3001）改：
// 步骤2：POST /motor/ota 只收固件
const upResp = await fetch("/motor/ota?ch=${ch}", { POST, body: ota.bytes, timeout 15s });
const upJson = await upResp.json();
if (!upResp.ok) throw new Error(upJson.error);
otaLog("[上传] 成功，触发 GD32 转发…");
// 步3：POST /motor/ota/relay 触发喂数据
const rResp = await fetch("/motor/ota/relay?ch=${ch}", { POST, timeout 5000 });
const rJson = await rResp.json();
if (!rResp.ok) throw new Error(rJson.error);
otaLog("[转发] GD32 开始握手…");
startOtaPoll(); // 轮询不变
超时：上传 15s（48KB），触发 5s（一个 SPI 事务）。
cancelOta： 不用改。/motor/ota/cancel 两阶段都有效：触发前 motorOtaCancel 是空操作（feedTask 没跑），但仍清 GD32 状态；可顺便让 cancel handler 也清 meta（见下）。
5.（附带）motor_ota_cancel_handler 加清 meta
cancel 时 motorOtaCancel() 后补一行 Gd32FlashStore::instance().metaClear()，覆盖"上传完未触发就取消"场景，清掉残留固件 meta。触发后取消也清 meta 无害（feedTask 已停）。
状态机与轮询（不变）
/motor/ota/status复用，返回 GD32 pushStatus 的 state/packets_acked- 触发前 status = IDLE；触发后进 HANDSHAKE/TRANSFER/FINISHED/ERROR
- 前端在 relay 请求成功后才
startOtaPoll，避免触发前空轮询
关键收益
- 消除竞态：收固件纯 HTTP 流式写 flash，不碰 SPI/MISO 缓冲，不与 GD32 按铃推送争抢；触发阶段只发一个短 SPI 0xD0，窗口极小
- 语义清晰：和 BLE 刷 GD32 的
prepare+收流 → /ota/relay两段式对齐 - 改动最小：feedTask、GD32 侧、状态轮询全部不动；只拆 HTTP 端点和前端调用顺序
风险
- 前端两次请求间若用户取消：cancel 已覆盖两阶段
- 上传成功但触发失败：meta 仍存，用户可重试 relay（relay 端点先检查
motorOtaIsActive再触发）；或 cancel 清 meta 重来 - 固件占 flash 未触发：metaClear 在 cancel/relay 成功后执行，残留风险低
验证
- 编译 ESP32_COMM（idf.py build）
- 手动测：选固件→开始，看日志先"[上传] 成功"再"[转发] GD32 开始握手"，确认两次 HTTP 分开
- 观察 SPI 按铃竞态是否消失（原"SPI start failed"概率应降到极低）
- feedTask 终态判定（之前加的）继续生效