fix(vd960DBN): 0x8F 接入 DBN 私有指令处理器 + net_srv 裸 printf + devlog 行尾
按用户 2026-09-10 四条指示: 1) 0x8F 下行的"本地处理"明确为 CH32V208GBU6 私有指令 —— 只作用在自身读写配置上, 一般不转发。实现: 不再留空壳计数, 直接复用 BLE 侧同一个分发器 manage_dbn_ble_default() (dbn_ble_srv.c:729)。两侧帧布局完全一致 (pkg[1]=Addr, pkg[2]=LEN, pkg[3]=CMD, pkg[4..]=Value), 零适配。 响应仍走 g_buf_ble_response -> BLE 通知; 不回 4G —— Air780 侧 parser 只认 0x7F, 回 0x8F 也没人接。 增加 OTA 门控: g_flag_counter_ota.flag != 0 时拒绝私有指令 —— 私有指令会写自身配置(碰 flash), 与 OTA 刷写并发是自找麻烦。 魔数宏改用 dbn_ble_srv.h 的 MAGIC_BYTE_DBN_DEFAULT, 不再硬编码 0x8F。 2) 0x7D 帧: 删除/不理会。V1.11 曾提的 DBN<->Air780 握手/配置同步构想作废, 代码里本就没实现, 正式协议也从未收录。devlog 待办项移除, 记入"已定案"。 3) net_srv.c:125 裸 printf() -> PRINT。该文件本已用 PRINT 53 处, 无需补 include。 DEBUG=0 时随 PRINT 一起消失, 不再出现"往未初始化的 USART1 写字节"。 4) devlog.md 行尾统一 CRLF (修复 132 个孤立 LF: 顶部 V1.13 条目原为 LF)。 验证 (host 单测, 代码从 usart_biz.c 原样抽取, gcc -Wall -Wextra -Werror 零警告): 15 组用例全部通过, 其中新增: - 0x8F -> manage_dbn_ble_default 被调用 1 次, 传入 len==全帧长, 内容逐字节一致, 未转发 - OTA 期间 0x8F -> 处理器未被调用, 但仍计数 (可观测) 原有 13 组 (魔数分流/最大帧/坏帧回找魔数/截断帧不丢帧/LEN 非法/0x9F 忽略...) 保持通过。 待板级验证: 需 MounRiver 工具链编译 + 实机 (本机无 riscv 工具链)。
This commit is contained in:
wangfq
+144
-137
@@ -21,7 +21,11 @@
|
||||
且**只转发 `lup_verify_checksum()==0` 的完整帧**。插入点必须在 BLE 分支改写 `pkg[0]=0x8F` 之前 ——
|
||||
否则会把已改魔数的帧发给 Air780。
|
||||
|
||||
**下行**（Air780 → DBN）：UART1 收帧 → **魔数分流**：`0x7F` → `UART2_SendString()` 给 Loop；`0x8F` → DBN 本地处理（预留，当前仅计数）。
|
||||
**下行**（Air780 → DBN）：UART1 收帧 → **魔数分流**：`0x7F` → `UART2_SendString()` 给 Loop；
|
||||
`0x8F` → **DBN(CH32V208GBU6) 私有指令**：只作用在自身读写配置上，**一般不转发**（用户 2026-09-10 澄清）。
|
||||
落地方式：直接复用 BLE 侧同一个分发器 `manage_dbn_ble_default()` —— 两边帧布局完全一致
|
||||
（`pkg[1]=Addr, pkg[2]=LEN, pkg[3]=CMD, pkg[4..]=Value`），零适配。响应仍走 `g_buf_ble_response`→BLE；
|
||||
不回 4G（Air780 侧 parser 只认 `0x7F`，回 `0x8F` 也没人接）。**OTA 期间拒绝**：私有指令会写自身配置(碰 flash)，与刷写并发是自找麻烦。
|
||||
|
||||
### 三个关键设计决定（含理由）
|
||||
|
||||
@@ -42,7 +46,8 @@
|
||||
此时 `#if(DEBUG)` 为假：`PRINT` 是空宏，且 `USART_Printf_Init()` 里 USART1 的配置分支整段不参与编译
|
||||
（已核对 `USART_Init/USART_Cmd` 均在 `#if(DEBUG == DEBUG_UART1)` 内）→ USART1 干净地交给本文件。
|
||||
- 调试版（DEBUG!=0）本通道编译为空实现，**`debug.h`/`debug.c` 一行未改**，printf 行为完全不变。
|
||||
- ⚠ 遗留：`net_srv.c:125` 有一处裸 `printf()`（错误路径），`DEBUG=0` 时仍会调用，建议改为 `PRINT`（列入待办）。
|
||||
- 已处理：`net_srv.c:125` 裸 `printf()`（错误路径）→ 改 `PRINT`；`DEBUG=0` 时随 `PRINT` 一起消失，
|
||||
不再出现"往未初始化的 USART1 写字节"这种恶心事。该文件本身已用 `PRINT` 53 处，无需补 include。
|
||||
|
||||
### 验证
|
||||
|
||||
@@ -67,149 +72,151 @@
|
||||
- 与 Air780 必须**交叉**：`DBN_PB6(TX) → Air780_RX`，`DBN_PB7(RX) ← Air780_TX`
|
||||
- 波特率两侧一致：115200（Air780 侧日志 `Uart_ChangeBR uart1, 115200`）
|
||||
|
||||
### 已定案
|
||||
|
||||
- `0x7D` 帧：**删除/不理会**（用户 2026-09-10）—— V1.11 曾提的 DBN↔Air780 握手/配置同步构想作废，
|
||||
代码里本就没有实现，`docs/DLD960_IoT_MQTT协议.md` 正式协议也从未收录。历史条目保留不动（记录当时的想法）。
|
||||
|
||||
### 仍待办
|
||||
|
||||
- [ ] `0x8F` 下行的本地处理行为（当前仅计数；协议未细化具体动作）
|
||||
- [ ] `0x7D` 握手/配置同步帧（V1.11 曾提，未进正式协议，暂预留）
|
||||
- [ ] BLE 设置服务器/topic 时同步下发 Air780 配置（V1.12 第 2 条）
|
||||
- [ ] 通道切换策略（V1.12 第 3 条，待讨论；暂定默认 4G）
|
||||
- [ ] `net_srv.c:125` 裸 `printf` → `PRINT`
|
||||
- [ ] 板级联调：编译烧录 + 帧计数对齐 + 断线重连
|
||||
|
||||
---
|
||||
|
||||
## 2026-08-31 — MQTT 协议 V1.13：initialize extra_info 增加 imei/iccid 可选字段
|
||||
|
||||
> 用户需求 2026-08-31：initialize 指令的 `extra_info` 增加可选字段 `imei` / `iccid`（4G 模块 IMEI / 流量卡 ICCID）。
|
||||
|
||||
### 协议变更（V1.12 → V1.13）
|
||||
|
||||
- §5.1 initialize 示例 + 字段表：`extra_info.imei` / `extra_info.iccid` 可选
|
||||
- 语义：无 4G 模块时省略或空串；**4G 通道由 Air780 填真实值**（§6.2 说明）
|
||||
- 用途：平台解析 initialize 即可拿到 4G 模块/流量卡标识（配合 4G 通道设备管理）
|
||||
|
||||
### 固件同步（vd960DBN iot_mqtt_srv.c iot_send_initialize）
|
||||
|
||||
- `extra_info` 增加 `imei`/`iccid` 字段（当前空串占位——DBN 固件无 4G 模块信息）
|
||||
- ⚠ 待 vd960DBN 实现"BLE→Air780 配置同步"后，可考虑从 Air780 回读 4G 信息填充（列入开发计划）
|
||||
|
||||
### 同步
|
||||
|
||||
- `README.md` 文档索引 V1.12 → V1.13
|
||||
- 协议文档 §5.1 + §6.2 + 修订记录 V1.13
|
||||
|
||||
---
|
||||
|
||||
## 2026-08-31 — MQTT 协议 V1.12：4G 通道适配修订为方案 C（Air780 协议转换）
|
||||
|
||||
> **协议先行修订**（同日 V1.11 方案 B 未落地即修订，固件均未实现）。
|
||||
|
||||
### 修订动因
|
||||
|
||||
V1.11 曾定**方案 B**（vd960DBN 纯转发 + frame_report/frame_cmd hex 透传）。讨论后改为**方案 C**：Air780 解析 0x7F 帧并转换为**标准 JSON 命令**（loop_data / event_report / initialize / heartbeat），平台零改动、与有线通道一致。
|
||||
|
||||
### 四个决策点（用户 2026-08-31）
|
||||
|
||||
| # | 决策 | 结果 |
|
||||
|---|------|------|
|
||||
| 1 | event_report | Air780 以 Lua 复刻 DBN iot_evt_* 逻辑（沿检测 + ACK + 5s×3 + 16 深队列 + 跨重连同 msg_id），可行性已评估：全部逻辑块可映射 Lua，无硬障碍 |
|
||||
| 2 | 事件面 | **4G 仅线圈事件**（car_enter/car_leave/loop_cut/loop_restore），不含 DBN 内部网络事件（协议 §6.4 明确） |
|
||||
| 3 | 命令响应 | Air780 单命令状态机 + 超时回 code=5（与 DBN g_lup_cmd 同模式），协议 §6.5 |
|
||||
| 4 | frame_* 去留 | **保留为可选兜底**（Air780 未实现转换命令/未识别帧透传），协议 §6.8 |
|
||||
|
||||
### 协议变更（V1.11 → V1.12）
|
||||
|
||||
- §6 重写：方案 C 架构（Air780 协议转换）/ 命令面 = 标准 JSON / 转换职责表（0x7F↔JSON）/ 事件上报 / 命令响应链路 / link / 平台要求
|
||||
- §3 命令详表：frame_cmd/frame_report 标注改为"可选兜底"
|
||||
- 修订记录 V1.12
|
||||
|
||||
### vd960DBN 侧开发计划（固件未实现，不变）
|
||||
|
||||
- [ ] UART1(PB6/PB7) 通道 + UART2↔UART1 双向透传（⚠ 转发不丢帧是 Air780 沿检测的前提）
|
||||
- [ ] BLE 设置服务器/topic 参数时同步下发 Air780 配置
|
||||
- [ ] 通道切换策略（待讨论；暂定默认 4G）
|
||||
|
||||
### 同步
|
||||
|
||||
- `README.md` 文档索引 V1.11 → V1.12
|
||||
- 协议文档 §6 重写 + 修订记录 V1.12（V1.11 保留作历史）
|
||||
|
||||
---
|
||||
|
||||
## 2026-08-31 — MQTT 协议 V1.11：4G 通道适配（方案 B：原始帧透传 + hex 封装）协议先行
|
||||
|
||||
> **本次为协议文档先行**（Air8781P 4G 兜底通道设计稿并入主协议；vd960DBN 固件未实现，列入开发计划）。
|
||||
|
||||
### 背景
|
||||
|
||||
vd960DBN 有线网络失效时需要 4G 兜底上报。接入方案定为 **方案 B：vd960DBN 纯转发**——Loop 传感数据(0x7F 帧)经 UART1 原样透传 Air780(Air8781P/Air780EPM, LuatOS vd960Air 工程),由 Air780 走 MQTT;4G 下行地感指令经 Air780 透传回 Loop。
|
||||
|
||||
### 协议变更(DLD960_IoT_MQTT协议 V1.10 → V1.11)
|
||||
|
||||
| 项 | 内容 |
|
||||
|----|------|
|
||||
| 新增命令 | `frame_report`(dev→srv, 上行 0x7F 帧 hex 封装, 每条上行携带 link)+ `frame_cmd`(srv→dev, 下行 0x7F/0x8F 帧 hex) |
|
||||
| 4G 通道命令面 | 不使用有线标准 JSON 业务命令(loop_data/event_report);initialize 由 Air780 发(JSON + link, 用于上线识别 + report_config 时钟校准) |
|
||||
| 不适用命令 | ssc_net_*/iot_net_*/iot_topic_*(4G 通道下发回 code=4) |
|
||||
| link 对象 | imei/iccid/imsi/msisdn/csq/net(4G 特有字段, 流量卡管理/信号监控) |
|
||||
| 链路层 | 数据面 0x7F 帧字节流透传(魔数分流在 DBN 侧: 0x7F→UART2 / 0x8F→本地);0x7D 帧仅 DBN↔Air780 配置同步/握手 |
|
||||
| 平台侧 | 双通道区分解析 + 新增《DLD960Loop_串口通信协议》解析依赖 |
|
||||
|
||||
### vd960DBN 侧开发计划(固件未实现)
|
||||
|
||||
- [ ] UART1(PB6/PB7)通道: 0x7F 帧魔数分流
|
||||
- [ ] UART2↔UART1 双向透传(复用 manage_dbn_ble_transparent 模式)
|
||||
- [ ] BLE 设置服务器/topic 参数时同步下发 Air780 配置
|
||||
- [ ] 通道切换策略(待讨论: 动态自动 vs 人工;暂定默认 4G)
|
||||
|
||||
### 同步
|
||||
|
||||
- `README.md` 文档索引 MQTT V1.10 → V1.11
|
||||
- 协议文档 §3 命令详表 + §6 4G 通道适配章节 + 修订记录 V1.11
|
||||
- CHANGELOG 历史条目保留不动
|
||||
|
||||
---
|
||||
|
||||
## 2026-08-31 — BLE 协议文档补全 V1.03：配置命令全表 + 未实现如实标注
|
||||
|
||||
> **本次为文档补录**（固件代码未变，不升固件版本）：对照 `dbn_ble_srv.c`（GBK+CRLF）逐命令梳理，`DLD960_BLE协议.md` 由 V1.02（仅脱机日志/快照 6 命令）补齐为完整 BLE 协议。
|
||||
|
||||
### 背景
|
||||
|
||||
`DLD960_BLE协议.md` 此前只覆盖 0x25~0x2A（OFFLOG/SNAP 6 命令），既有的 BLE 配置命令（0x09~0x24 等）没有文档——小程序/APP 对接无从下手。本次从代码反向梳理全部命令。
|
||||
|
||||
### 文档补全内容
|
||||
|
||||
| 命令码 | 名称 | 实现状态（代码核实） |
|
||||
|--------|------|---------------------|
|
||||
| 0x09/0x10/0x11/0x12 | 序列码/设备信息/SSC 网络读写 | ✅ manage_dbn_ble_default |
|
||||
| 0x13/0x14/0x15/0x16 | IoT 网络/Topic 读写 | ✅ unpack_packs（字符串数组 0x00 分隔） |
|
||||
| 0x1C/0x1D | 验证/修改密码 | ✅ unpack_packs（0x1D 不在 switch，分包收尾处理） |
|
||||
| 0x1E/0x92 | 出厂初始化 | ✅ 回 [0] + factory_dev_info() |
|
||||
| 0x1F | 设备复位 | ✅ 无响应直接 NVIC_SystemReset |
|
||||
| 0x22 | 子功能码 | ✅ 2B LE，无响应 |
|
||||
| 0x23/0x24 | 车检器参数读写 | ⚠ 空壳（0x23 仅回 [0] 不处理参数；0x24 空响应） |
|
||||
| 0x31 | UART 波特率读写 | ✅（⚠ 写响应多 1B 重复低字节，文档已标注） |
|
||||
| 0x8A | Loop 灵敏度列表 | ⚠ 空响应 |
|
||||
| 0xC5 | 传感上报使能 | ✅ 设置生效无响应；⚠ report_sens_acs 无定义 → 0xC0 上报未实现 |
|
||||
| 0x17/0x18/0x20/0x21/0x87/0x88/0x89 | 交通参数/通知/Loop 采样等 | ⚠ 头文件有定义，switch 无 case（未实现） |
|
||||
| 0x7F/0x9F | 透传通道 | ✅ UART2 原样转发 / OTA 透传 |
|
||||
|
||||
### 关键发现
|
||||
|
||||
- **0x1D MODIFY_PASS 实际已实现**：不在 manage_dbn_ble_default 的 switch，而在 unpack_packs 分包收尾分支（头文件有定义、switch 无 case ≠ 未实现，须看 unpack_packs）
|
||||
- **0xC0 BLE 主动上报已废弃**：`report_sens_acs()` 仅 dbn_ble_srv.h 声明，全工程无定义无调用；0xC5 使能后无上报动作（上报走 MQTT/TCP）
|
||||
- **0x31 写响应固件 bug**：`tmp_ble_buf[i++] = g_storage_uart_baud;` 后紧跟 `tmp_ble_buf[i++] = (uint8_t)g_storage_uart_baud;` 重复写低字节，响应 10B 而非 9B——文档按语义描述 + 标注实际多 1B，待板级联调时确认是否修固件
|
||||
- 请求分包（unpack_packs）与响应分包（set_response_to_notify）格式一致：header 高 4 位=包数、低 4 位=序号（从 1 起）
|
||||
|
||||
### 同步
|
||||
|
||||
- `README.md` 文档索引 BLE 协议 V1.02 → V1.03（描述更新为完整命令表）
|
||||
- CHANGELOG 历史发布条目（V1.02 不变）保留不动
|
||||
- 待板级：0x31 写响应长度、0xC5 使能后无上报是否符合预期
|
||||
|
||||
---
|
||||
|
||||
## 2026-08-31 — MQTT 协议 V1.13：initialize extra_info 增加 imei/iccid 可选字段
|
||||
|
||||
> 用户需求 2026-08-31：initialize 指令的 `extra_info` 增加可选字段 `imei` / `iccid`（4G 模块 IMEI / 流量卡 ICCID）。
|
||||
|
||||
### 协议变更（V1.12 → V1.13）
|
||||
|
||||
- §5.1 initialize 示例 + 字段表：`extra_info.imei` / `extra_info.iccid` 可选
|
||||
- 语义：无 4G 模块时省略或空串；**4G 通道由 Air780 填真实值**（§6.2 说明）
|
||||
- 用途：平台解析 initialize 即可拿到 4G 模块/流量卡标识（配合 4G 通道设备管理）
|
||||
|
||||
### 固件同步（vd960DBN iot_mqtt_srv.c iot_send_initialize）
|
||||
|
||||
- `extra_info` 增加 `imei`/`iccid` 字段（当前空串占位——DBN 固件无 4G 模块信息）
|
||||
- ⚠ 待 vd960DBN 实现"BLE→Air780 配置同步"后，可考虑从 Air780 回读 4G 信息填充（列入开发计划）
|
||||
|
||||
### 同步
|
||||
|
||||
- `README.md` 文档索引 V1.12 → V1.13
|
||||
- 协议文档 §5.1 + §6.2 + 修订记录 V1.13
|
||||
|
||||
---
|
||||
|
||||
## 2026-08-31 — MQTT 协议 V1.12：4G 通道适配修订为方案 C（Air780 协议转换）
|
||||
|
||||
> **协议先行修订**（同日 V1.11 方案 B 未落地即修订，固件均未实现）。
|
||||
|
||||
### 修订动因
|
||||
|
||||
V1.11 曾定**方案 B**（vd960DBN 纯转发 + frame_report/frame_cmd hex 透传）。讨论后改为**方案 C**：Air780 解析 0x7F 帧并转换为**标准 JSON 命令**（loop_data / event_report / initialize / heartbeat），平台零改动、与有线通道一致。
|
||||
|
||||
### 四个决策点（用户 2026-08-31）
|
||||
|
||||
| # | 决策 | 结果 |
|
||||
|---|------|------|
|
||||
| 1 | event_report | Air780 以 Lua 复刻 DBN iot_evt_* 逻辑（沿检测 + ACK + 5s×3 + 16 深队列 + 跨重连同 msg_id），可行性已评估：全部逻辑块可映射 Lua，无硬障碍 |
|
||||
| 2 | 事件面 | **4G 仅线圈事件**（car_enter/car_leave/loop_cut/loop_restore），不含 DBN 内部网络事件（协议 §6.4 明确） |
|
||||
| 3 | 命令响应 | Air780 单命令状态机 + 超时回 code=5（与 DBN g_lup_cmd 同模式），协议 §6.5 |
|
||||
| 4 | frame_* 去留 | **保留为可选兜底**（Air780 未实现转换命令/未识别帧透传），协议 §6.8 |
|
||||
|
||||
### 协议变更（V1.11 → V1.12）
|
||||
|
||||
- §6 重写：方案 C 架构（Air780 协议转换）/ 命令面 = 标准 JSON / 转换职责表（0x7F↔JSON）/ 事件上报 / 命令响应链路 / link / 平台要求
|
||||
- §3 命令详表：frame_cmd/frame_report 标注改为"可选兜底"
|
||||
- 修订记录 V1.12
|
||||
|
||||
### vd960DBN 侧开发计划（固件未实现，不变）
|
||||
|
||||
- [ ] UART1(PB6/PB7) 通道 + UART2↔UART1 双向透传（⚠ 转发不丢帧是 Air780 沿检测的前提）
|
||||
- [ ] BLE 设置服务器/topic 参数时同步下发 Air780 配置
|
||||
- [ ] 通道切换策略（待讨论；暂定默认 4G）
|
||||
|
||||
### 同步
|
||||
|
||||
- `README.md` 文档索引 V1.11 → V1.12
|
||||
- 协议文档 §6 重写 + 修订记录 V1.12（V1.11 保留作历史）
|
||||
|
||||
---
|
||||
|
||||
## 2026-08-31 — MQTT 协议 V1.11：4G 通道适配（方案 B：原始帧透传 + hex 封装）协议先行
|
||||
|
||||
> **本次为协议文档先行**（Air8781P 4G 兜底通道设计稿并入主协议；vd960DBN 固件未实现，列入开发计划）。
|
||||
|
||||
### 背景
|
||||
|
||||
vd960DBN 有线网络失效时需要 4G 兜底上报。接入方案定为 **方案 B：vd960DBN 纯转发**——Loop 传感数据(0x7F 帧)经 UART1 原样透传 Air780(Air8781P/Air780EPM, LuatOS vd960Air 工程),由 Air780 走 MQTT;4G 下行地感指令经 Air780 透传回 Loop。
|
||||
|
||||
### 协议变更(DLD960_IoT_MQTT协议 V1.10 → V1.11)
|
||||
|
||||
| 项 | 内容 |
|
||||
|----|------|
|
||||
| 新增命令 | `frame_report`(dev→srv, 上行 0x7F 帧 hex 封装, 每条上行携带 link)+ `frame_cmd`(srv→dev, 下行 0x7F/0x8F 帧 hex) |
|
||||
| 4G 通道命令面 | 不使用有线标准 JSON 业务命令(loop_data/event_report);initialize 由 Air780 发(JSON + link, 用于上线识别 + report_config 时钟校准) |
|
||||
| 不适用命令 | ssc_net_*/iot_net_*/iot_topic_*(4G 通道下发回 code=4) |
|
||||
| link 对象 | imei/iccid/imsi/msisdn/csq/net(4G 特有字段, 流量卡管理/信号监控) |
|
||||
| 链路层 | 数据面 0x7F 帧字节流透传(魔数分流在 DBN 侧: 0x7F→UART2 / 0x8F→本地);0x7D 帧仅 DBN↔Air780 配置同步/握手 |
|
||||
| 平台侧 | 双通道区分解析 + 新增《DLD960Loop_串口通信协议》解析依赖 |
|
||||
|
||||
### vd960DBN 侧开发计划(固件未实现)
|
||||
|
||||
- [ ] UART1(PB6/PB7)通道: 0x7F 帧魔数分流
|
||||
- [ ] UART2↔UART1 双向透传(复用 manage_dbn_ble_transparent 模式)
|
||||
- [ ] BLE 设置服务器/topic 参数时同步下发 Air780 配置
|
||||
- [ ] 通道切换策略(待讨论: 动态自动 vs 人工;暂定默认 4G)
|
||||
|
||||
### 同步
|
||||
|
||||
- `README.md` 文档索引 MQTT V1.10 → V1.11
|
||||
- 协议文档 §3 命令详表 + §6 4G 通道适配章节 + 修订记录 V1.11
|
||||
- CHANGELOG 历史条目保留不动
|
||||
|
||||
---
|
||||
|
||||
## 2026-08-31 — BLE 协议文档补全 V1.03：配置命令全表 + 未实现如实标注
|
||||
|
||||
> **本次为文档补录**（固件代码未变，不升固件版本）：对照 `dbn_ble_srv.c`（GBK+CRLF）逐命令梳理，`DLD960_BLE协议.md` 由 V1.02（仅脱机日志/快照 6 命令）补齐为完整 BLE 协议。
|
||||
|
||||
### 背景
|
||||
|
||||
`DLD960_BLE协议.md` 此前只覆盖 0x25~0x2A（OFFLOG/SNAP 6 命令），既有的 BLE 配置命令（0x09~0x24 等）没有文档——小程序/APP 对接无从下手。本次从代码反向梳理全部命令。
|
||||
|
||||
### 文档补全内容
|
||||
|
||||
| 命令码 | 名称 | 实现状态（代码核实） |
|
||||
|--------|------|---------------------|
|
||||
| 0x09/0x10/0x11/0x12 | 序列码/设备信息/SSC 网络读写 | ✅ manage_dbn_ble_default |
|
||||
| 0x13/0x14/0x15/0x16 | IoT 网络/Topic 读写 | ✅ unpack_packs（字符串数组 0x00 分隔） |
|
||||
| 0x1C/0x1D | 验证/修改密码 | ✅ unpack_packs（0x1D 不在 switch，分包收尾处理） |
|
||||
| 0x1E/0x92 | 出厂初始化 | ✅ 回 [0] + factory_dev_info() |
|
||||
| 0x1F | 设备复位 | ✅ 无响应直接 NVIC_SystemReset |
|
||||
| 0x22 | 子功能码 | ✅ 2B LE，无响应 |
|
||||
| 0x23/0x24 | 车检器参数读写 | ⚠ 空壳（0x23 仅回 [0] 不处理参数；0x24 空响应） |
|
||||
| 0x31 | UART 波特率读写 | ✅（⚠ 写响应多 1B 重复低字节，文档已标注） |
|
||||
| 0x8A | Loop 灵敏度列表 | ⚠ 空响应 |
|
||||
| 0xC5 | 传感上报使能 | ✅ 设置生效无响应；⚠ report_sens_acs 无定义 → 0xC0 上报未实现 |
|
||||
| 0x17/0x18/0x20/0x21/0x87/0x88/0x89 | 交通参数/通知/Loop 采样等 | ⚠ 头文件有定义，switch 无 case（未实现） |
|
||||
| 0x7F/0x9F | 透传通道 | ✅ UART2 原样转发 / OTA 透传 |
|
||||
|
||||
### 关键发现
|
||||
|
||||
- **0x1D MODIFY_PASS 实际已实现**：不在 manage_dbn_ble_default 的 switch，而在 unpack_packs 分包收尾分支（头文件有定义、switch 无 case ≠ 未实现，须看 unpack_packs）
|
||||
- **0xC0 BLE 主动上报已废弃**：`report_sens_acs()` 仅 dbn_ble_srv.h 声明，全工程无定义无调用；0xC5 使能后无上报动作（上报走 MQTT/TCP）
|
||||
- **0x31 写响应固件 bug**：`tmp_ble_buf[i++] = g_storage_uart_baud;` 后紧跟 `tmp_ble_buf[i++] = (uint8_t)g_storage_uart_baud;` 重复写低字节，响应 10B 而非 9B——文档按语义描述 + 标注实际多 1B，待板级联调时确认是否修固件
|
||||
- 请求分包（unpack_packs）与响应分包（set_response_to_notify）格式一致：header 高 4 位=包数、低 4 位=序号（从 1 起）
|
||||
|
||||
### 同步
|
||||
|
||||
- `README.md` 文档索引 BLE 协议 V1.02 → V1.03（描述更新为完整命令表）
|
||||
- CHANGELOG 历史发布条目（V1.02 不变）保留不动
|
||||
- 待板级：0x31 写响应长度、0xC5 使能后无上报是否符合预期
|
||||
|
||||
---
|
||||
|
||||
## 2026-08-21 — MQTT 协议 V1.10 代码落地：网络上报携带地感版本（loop_ver/loop_hw_ver）
|
||||
|
||||
> **固件版本：归入 vd960DBN V1.02.05 发布**（2026-08-21 升版，cmcng.h 三段式一致：FIRMWARE_VER="1.02.05" + MAIN=1/SUB=2/SUBSUB=5）。V1.02.05 涵盖 8-20 联网稳定性修复系列（SocketSend 0x11 / OTA hex 空格 / union 合并 / 刷写状态语义）+ 本次 V1.10 协议实现。
|
||||
|
||||
Reference in New Issue
Block a user