wangfq/vd_960
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity
278 Commits 1 Branch 4 Tags
77b667f1a03e316692455f89074ff35e041cdac8
Commit Graph
38 Commits
Author SHA1 Message Date
wangfq 5a1893cd1c feat(vd960DBN)+fix(DBNMQTTool): log_query 改 hex 原始字节上报 (2026-08-18) 
背景: MQTT 快照流实测 MQTTSerialize_publish failed — JSON 化快照记录 ~810B/条 超 800B 发送缓冲
方案(用户拍板): 对齐 BLE 通道, 原始字节 hex 上报

固件 (V4.3):
- offlog.c/h: 新增 offlog_evt_to_hex() (32B→64 hex)
- snapshot.c/h: 新增 snap_rec_to_hex() (64B→128 hex); 删 SNAP_MAX_QUERY_JSON, 恢复 count=2
- tcp_json_srv.c / iot_mqtt_srv.c: log_query 改 {"seq":N,"hex":"..."}; SEND_BUF 保持 800
- 2 条快照 hex 响应 406B < 800B

文档: TCP JSON V1.03 / MQTT V1.07 §4.17 records 改 hex + 解析表引用 BLE §6.4/§7

工具: parse_offlog_hex/parse_snap_hex/offlog_payload_desc + hex 展示; 验证: gcc 9 断言 + 工具解析全过 + offscreen UI
 2026-08-18 14:04:26 +08:00
wangfq f1c9358aad feat(vd960DBN): TCP/MQTT log_* 命令支持快照流 stream=snapshot (2026-08-18) 
- snapshot.c/h: 新增 snap_rec_to_json() — SnapRec 64B → JSON (channels 对齐 0xC0, variation 3B 符号扩展, misc_type 全枚举)
- tcp_json_srv.c: handle_log_stat/query/clear 加 stream 解析 + snapshot 分支
- iot_mqtt_srv.c: log_stat/query/clear 加 stream 解析 + snapshot 分支
- 事件流 count=0 按上限处理 (与 BLE 对齐); 快照 QUERY count≤2, CLEAR ~45ms
- 新增 gcc 隔离单测 tests/test_snap_to_json.c 34 断言全过
- devlog V4.1
 2026-08-18 09:01:22 +08:00
wangfq cb63c581be perf(vd960DBN): 二轮RAM瘦身 — RECE_BUF_LEN 1024 + ARP 16 + 中断路径static (2026-08-17) 
.map 分析: BLE 栈固定占 RAM 低 16KB 不可裁; 用户 48KB 内 .bss 41.7KB。
- net_config.h: RECE_BUF_LEN MSS×2(1400)→1024 (MSS=700帧+头≈740B, 5数组省~2.6KB)
- net_config.h: WCHNET_NUM_ARP_TABLE 50→16 (停车场景IP少, 省~0.8KB)
- tcp_json_srv.c: tmp_buf[RECE_BUF_LEN]/frame[800] 局部→static (中断上下文栈数组防溢出)

栈 4.7KB→~6.3KB, 中断栈峰值 -1.8KB。devlog 记录 .map 分析结论。
 2026-08-17 14:26:22 +08:00
wangfq b493e10454 fix(vd960DBN): UART2 粘帧/checksum fail — 高频打印关中断丢字节 + flag 不清 
现场: LUP 帧后 checksum fail 刷屏 (坏帧: 7F 03 39 EF... 多帧拼接)。
根因链条:
1. LUP Rx 打印 190B @256000 = 7.4ms 关中断 (PRINT 临界区)
   → UART2(19200) RX 溢出丢字节 → 帧解析错位 → 粘帧
2. g_pkg_uart_2.flag 清理缺失: uart_srv 0xC0 分支不 InitPkgUart,
   tcp_json_push_sensor not authed 提前 return 也不清
   → 坏帧反复处理 → checksum fail 刷屏

修复:
- LUP Rx 打印 #if 0 (高频打印关中断是丢字节根因, 调试时开)
- json_sensor_callback not authed 打印 #if 0 (每帧刷屏)
- uart_srv 所有分支消费后统一 InitPkgUart (0xC0 + 非0xC0无BLE)
- 顺带修 report disabled 双反斜杠
 2026-08-13 17:43:24 +08:00
wangfq a36cc15cf2 test(vd960DBN): 二分卡死点 — 注释 json_sensor_callback enter PRINT + 删冗余打印 
现场: LUP 帧后卡死 (5分钟后神秘复位 RST=0x10000000, marker丢失)。
卡死点在 lup_process_frame 内 json_sensor_callback 的 enter PRINT
(printf %d 处理), LUP Rx 打印(%s)成功但 enter(%d%d%d)卡死。
实验:
- json_sensor_callback enter PRINT #if 0 (坐实 printf 问题)
- uart_srv 187-190 重复逐字节打印 #if 0 (LUP Rx 已缓冲打印, 冗余)
验证: 不卡死→printf %d 问题实锤; 仍卡死→json_sensor_callback 后续代码
 2026-08-13 17:22:31 +08:00
wangfq 4bdf8a7993 fix(vd960DBN): IWDG 无条件启用+喂狗 — 卡死兜底 (卡死定位闭环) 
现场: printf 重入修复后乱码消失, 但 LUP 帧处理卡死(连 JSON:
sensor_cb enter 都没打印), 且 iot_enable=0 模式 IWDG 未初始化
(iot_mqtt_poll 才喂狗, tcp_json 分支不喂) → 卡死永久冻结无兜底。

修复:
- main 无条件 iot_watchdog_init() (IWDG 4s 超时)
- 主循环 while 开头无条件 iot_watchdog_kick() (原只在 iot_mqtt_poll)
- json_sensor_callback / iot_evt_sensor_cb 加 FAULT_MARKER(MK_EVT_CB_IN/OUT)

效果: 卡死 → 4s IWDG 复位 → 上电 FAULT_DIAG 打印 marker 定位卡死点
 2026-08-13 16:15:26 +08:00
wangfq 1a01316c7f feat(vd960DBN): offlog 协议导出命令分发 — log_stat/log_query/log_clear 落地 
协议先行 (08893d5, MQTT V1.06 + TCP JSON V1.02) 的固件侧实现:
- offlog 新增导出 API: enabled/seq_last/type_str/evt_to_json
  (seq_first=seq_last-count+1, idx=start_seq-seq_first, count≤4)
- MQTT iot_handle_publish 三分支: log_stat/log_query/log_clear
  (log_query 响应 static buf 防大栈; log_clear 阻塞~2.8s 主循环可接受)
- TCP JSON 三 handler + cmd 表 (需鉴权)
- 单测新增 test_export_json (8 例全过): boot rst 大端/coil sub/evt_retry/data:null/seq 公式
- devlog V3.9
 2026-08-05 08:53:18 +08:00
wangfq 2b1e888a73 refactor(vd960DBN): tcp_json_srv data_json[2048] 宏化 → TCP_JSON_DATA_BUF_LEN(1024) 
三处 char data_json[2048] (sensor_report×2 + loop_param_query×1)
改用头文件宏 TCP_JSON_DATA_BUF_LEN, 默认 1024。

容量核验: format_sensor_json 4通道~660B / format_loop_param_json~920B
均 < 1024, format 函数有 snprintf 溢出保护; 最终帧受 MAX_FRAME=800 截断。
附带: 栈上缓冲 2048→1024 每处省 1KB
 2026-08-04 17:06:29 +08:00
wangfq c515638032 fix: MQTT协议 V1.02 同步 — 字段名缩短 + 时间单位修正 
- docs/DLD960_IoT_MQTT协议.md: 字段缩写 + 时间单位 5ms→50ms
- vd960DBN/iot_mqtt_srv.c: 6字段缩短对齐协议 (level/iscar/freq/diff/sens/cndtn)
- vd960DBN/tcp_json_srv.c: gap_ms5/passtime_ms → gap/passtime
- vd960DBN/loop_uart_proto.h: 注释 5ms→50ms
- DBNMQTTool/main.py: 模拟样本数据字段同步
 2026-07-09 10:18:03 +08:00
wangfq a7de4dfcde feat(vd960DBN): MQTT/TCP report_config 支持完整7参数配置 
- 新增 ReportConfig 结构体 (sensor_type/enable/once/env_eval/interval/ack_required/timeout)
- net_srv.c: MQTT report_config handler — 查询/设置均返回完整配置JSON
- tcp_json_srv.c: TCP JSON handle_report_config 同步升级，兼容旧 active_report
- iot_mqtt_srv.c: g_report_active → g_report_cfg.enable
- g_report_active 全局变量替换为 g_report_cfg 结构体
 2026-07-07 18:39:45 +08:00
wangfq e6dbdb5296 fix(vd960DBN): 修复无法设置 IoT 模式的 bug 2026-07-06 10:24:15 +08:00
wangfq acb999a881 fix: 放弃 close+recreate listen socket, 改为只关数据socket 
根因: WCHNET ERR_ISCONN(0x1D), listen socket 关闭后端口5960仍被占用,
      无法在同端口立即重建. WCHNET_MainTask 循环也未能释放.

新方案: tcp_json_restart 只关数据 socket(N+1) 断开客户端,
        listen socket(N) 保持不动, 仅重置应用层状态.
        新客户端连接时 CONNECT 事件照常触发.
 2026-07-03 16:10:52 +08:00
wangfq c181839694 fix: SocketCreat 0x1D — close后先跑WCHNET回收资源再creat 
根因: WCHNET_SocketClose 异步, 资源在 WCHNET_MainTask 中释放.
      tcp_json_restart() close后立刻creat, 旧socket未回收→0x1D.
修复: close后循环5次 WCHNET_MainTask+HandleGlobalInt+Delay(10ms)
      确保资源释放后再 WCHNET_SocketCreat
 2026-07-03 15:51:16 +08:00
wangfq b97afe22d5 refactor: 去掉 60s Auth timeout, 改为 3次失败即重启 
- 删除 tcp_json_poll 中的 Auth timeout 60s 超时检查
- Auth 失败逻辑已在 handle_pwd_verify: 3次失败→tcp_json_restart()
- 连接后无交互场景由 5min 空闲检查覆盖
 2026-07-03 15:28:00 +08:00
wangfq fe69855dc9 fix: Auth timeout 耗尽重启限额导致冷却期阻断连接 
根因: auth timeout(60s) 走 do_restart 计数, 上电后 4 分钟就耗尽 3 次限额,
      进入 10min 冷却期, 客户端无法连接.

修复: auth timeout 直接调 tcp_json_restart() 绕开 do_restart,
      不消耗重启计数器. 只保留 5min 空闲/无连接作为限额保护目标.
 2026-07-03 15:18:54 +08:00
wangfq 1ce2e783ae fix: Auth timeout 死循环打印 — 改用 do_restart 而非手工 close 
根因: WCHNET_SocketClose 后 g_json_socket_listen 未归 0xFF,
      g_json_auth_timer 未重置, 下次 poll 条件仍满足 → 无限打印.
修复: auth timeout 直接 goto do_restart, 走完整的 close→recreate 流程
 2026-07-03 13:49:10 +08:00
wangfq 5966eb8657 feat: TCP Server 自动重启机制 — 3种超时条件 
触发条件（任一满足即重启）:
1. 5分钟无任何连接 (从未连或上次连接后超时)
2. 5分钟无数据交互 (已连接但静默)
3. Auth 密码错误3次

重启流程: 关闭socket→清状态→重新SocketCreat+SocketListen
保护机制: 最多连续重启3次, 超限后进入10分钟冷却期

其他改动:
- tcp_json_srv_init 去掉 _init_done 限制, 支持重新初始化
- 新增 tcp_json_restart() 函数
- 新增 g_json_last_comm_ts / g_json_last_connect_ts 追踪
- CONNECT 时清零 restart_count (正常连接重置计数器)
 2026-07-03 11:46:17 +08:00
wangfq d9059fac92 rename: passtime_ms5 → passtime_ms 2026-07-03 11:08:53 +08:00
wangfq 9bab650c27 feat: 0xC0 时间量根据 car_state 区分通过时间/车间距 
car_state=0(无车) → passtime_ms5 (通过时间)
car_state=1(有车) → gap_ms5 (车间距)
 2026-07-02 17:48:05 +08:00
wangfq 2163b89d28 feat: 协议 V1.04 — 主动上报增加继电器输出次数 (misc_type=3) 
- loop_uart_proto.h: LUP_CoilSensor.misc 联合体新增 relay_count
- tcp_json_srv.c: format_sensor_json 处理 misc_type=3 → relay_count
- docs: 更新协议文档至 V1.04
 2026-07-02 16:50:06 +08:00
wangfq 43d815a4fe fix: WCHNET_SocketSend 使用数据 socket (listen+1) 而非 listen socket 
诊断日志确认: g_json_socket_listen=0, 数据中断走 sock=1
WCHNET TCP 模式下 listen=N, 收发数据必须走 socket N+1

修改: json_sensor_callback + tcp_json_push_sensor 两处
 2026-07-02 14:40:31 +08:00
wangfq ff17bbbc88 fix: 回调注册前置到 socket 操作之前 + 入口诊断日志 
- lup_set_sensor_callback 移到 SocketCreat/SocketListen 之前
  避免 socket 失败 return 导致回调漏注册
- json_sensor_callback 入口打印 socket/auth/report 三状态
  各检查点分别打印 skip 原因
 2026-07-02 14:35:56 +08:00
wangfq c4a2b50ca5 fix: tcp_json_srv_init 加一次性守卫 + callback NULL 诊断 
问题: NET_SSC_ENABLE 时 g_net_state.flag 保持 1, net_srv_init 反复调用
      tcp_json_srv_init 第二次因 socket 已存在失败 → 过早 return
      → lup_set_sensor_callback 未执行 → 0xC0 回调永远 NULL

修复:
- tcp_json_srv_init: 加 static _init_done 守卫，防止重复执行
- lup_set_sensor_callback: 打印注册/清除日志
- lup_process_frame: 回调为 NULL 时打印诊断信息
 2026-07-02 14:29:23 +08:00
wangfq d559294359 fix: 添加 format_sensor_json 前置声明，修复 implicit declaration 编译错误 2026-07-02 14:21:06 +08:00
wangfq 6acd788d13 fix: 0xC0 帧通过回调直接驱动网络上报 
loop_uart_proto:
- 新增 lup_sensor_cb_t 回调类型 + lup_set_sensor_callback
- lup_process_frame 收到 0xC0 → 调用注册的回调推送数据

tcp_json_srv:
- json_sensor_callback: 检查 g_report_active → 解析 → TCP 发送
- tcp_json_srv_init: 注册回调

usart_biz:
- uart_srv: 0xC0 由回调直接 TCP 推送，BLE 连接时也转发 BLE
- 移除旧的 _report_flag 轮询路径

数据流: ISR → lup_process_frame(校验) → json_sensor_callback → WCHNET_SocketSend
 2026-07-02 14:15:28 +08:00
wangfq 8526023e06 feat: 实现 sensor_report 主动上报功能 
vd960DBN:
- 新增 g_report_active 全局标志控制传感器数据主动上报
- handle_report_config: 解析 active_report JSON 字段，设置/清除标志
- tcp_json_push_sensor: 检查 g_report_active 开关，仅在启用时推送

DBNetClient:
- tcp_json_client.py: 新增 report_config(active_report) 方法
- main.py: 线圈标签页添加"启用主动上报"复选框
- main.py: 注册 sensor_report push 处理器，实时显示推送数据
 2026-07-02 13:42:59 +08:00
wangfq 615b369690 fix: 同步协议文档 V1.03 — 0x8A 响应格式 + LEN 计算修正 
协议变更(V1.02→V1.03):
- 0x8A 响应: Ret(0x10/0x11) + Amount + Amount*(SensIn+SensOut)
- 新增灵敏度响应例程 (7F 80 13 8A 10 04 ...)
- 波特率确认 192000

代码修正:
- lup_build_sensitivity_read:  LEN=3 (was 4)
- lup_build_sensitivity_write: LEN=3+Amount*4 (was 2+Amount*2)
- lup_parse_sensitivity_resp: 解析 Ret 字节 + SensIn/SensOut 双值
- lup_build_set_param:        LEN=3+5*Amount (was 2+5*Amount)
- tcp_json_srv:               JSON 输出含 sens_in/sens_out 字段
 2026-07-02 11:55:29 +08:00
wangfq e9c24ae736 feat: DBNetClient Loop命令完善 + vd960DBN 发送调试打印 
vd960DBN:
- loop_uart_proto.c: 所有发送函数添加 LUP Tx 调试打印
- tcp_json_srv.c: 新增 loop_version_query/loop_reset/loop_factory_init/
  loop_sens_read/loop_sens_write 命令处理器 + 延迟响应解析
- 修复 loop_sens_write 未设置命令状态机和错误使用解析函数的问题

DBNetClient:
- tcp_json_client.py: 新增 full Loop MCU API (6 条命令)
- main.py: 线圈参数标签页增加版本/复位/出厂/灵敏度操作按钮
 2026-07-02 10:33:11 +08:00
wangfq 4fbda96078 feat(vd960DBN): 实现 DLD960Loop 串口通信协议 (0x7F) 
新增:
- docs/DLD960Loop_串口通信协议.md — 协议文档 V1.02
- loop_uart_proto.h/c — 协议实现: checksum/组包/解析/帧状态机/命令状态机

修改:
- usart_biz.c: 使用 lup_feed_byte() 帧解析器替代 timeout heuristic; 波特率修正为 115200
- tcp_json_srv.c/h: loop_param_set/query 真实实现(0x63/0x64), 0xC0 传感器推流, 延迟响应机制
- peripheral_main.c: 添加 tcp_json_push_sensor() 调用, 帧解析器超时保护

校验验证: 5个协议例程 XOR+SUM 全部通过
 2026-07-02 09:26:34 +08:00
wangfq 4e75312a0f fix: CONNECT 事件到达 TCP_LISTEN socket(1) 而非 TCP socket(0) 
WCHNET 将 CONNECT 事件投递到 TCP_LISTEN 内部 socket (sock 1)，
而非用户创建的 TCP socket (sock 0)。之前的路由只检查
socketid==g_json_socket_listen(0)，遗漏了 sock 1。

修复：
- NET_SSC_ENABLE=1 时同时路由 sock N 和 sock N+1 到 JSON handler
- NET_SSC_ENABLE=0 时所有 socket 事件都路由到 JSON handler
- tcp_json_handle_sock_int 移除 socket 限定，处理任意 socket 事件
 2026-07-01 14:09:34 +08:00
wangfq ba35ea8ae3 refactor: 按 WCH 官方 TCPServer 例程重写 TCP JSON server 
核心变更：去掉 g_json_socket_client，listen socket 直接承载收发数据。

参考 EVT/EXAM/ETH/TCPServer 例程：
- 创建 PROTO_TYPE_TCP socket → WCHNET_SocketListen
- 同一 socket 处理 CONNECT + RECV + DISCONNECT + TIMEOUT
- 不需要 'accepted socket' 检测

移除的复杂逻辑：
- g_json_socket_client 变量及所有 'newly accepted' 检测代码
- WCHNET_HandleSockInt 第二路由条件（socketid!=listen,!=TCP,!=UDP 那串）
- tcp_json_handle_sock_int 中 listen/client 分离处理
- listen==client overlap 的迂回保护

修改文件：
- tcp_json_srv.h: 移除 g_json_socket_client extern
- tcp_json_srv.c: 移除 g_json_socket_client，handler 简化为 4 个 if
- net_srv.c: 路由简化为仅 socketid==g_json_socket_listen
 2026-07-01 11:18:43 +08:00
wangfq 7804d97a45 fix: listen socket CONNECT 不应触发 accepted 客户端逻辑 
- WCHNET_HandleSockInt 第二路由条件增加 socketid!=g_json_socket_listen
- tcp_json_handle_sock_int 'Newly accepted' 检查增加 socketid!=g_json_socket_listen
- 防止 listen socket 的 CONNECT 事件误触发 WCHNET_ModifyRecvBuf 和 g_json_socket_client 覆写

根因：TCP_LISTEN socket 和 accepted client 是不同 socket ID（1 vs 3），
listen socket 的 CONNECT 不应穿透到 'newly accepted' 分支去配置 recv buffer，
否则会干扰 WCHNET 对 accepted socket 的数据路由
 2026-07-01 09:52:28 +08:00
wangfq be8c48688c fix: tcp_json_handle_sock_int RECV 被 listen socket 分支拦截导致收不到鉴权数据 
- RECV 处理移到函数最前面，优先于 listen socket 检查
- listen socket 分支增加 socketid!=g_json_socket_client 保护，
  防止 listen 与 accepted client 为同一 socket ID 时
  RECV 事件被 listen 分支 return 拦截
- WCHNET 某些版本可能将 TCP_LISTEN 和已 accept 的连接
  共用同一 socket ID，此时旧代码在 listen 检查处直接 return
  导致后续 client RECV 处理永远不被执行
 2026-07-01 09:20:44 +08:00
wangfq 735af8c0eb fix: WCHNET 接收缓冲区与帧缓冲区重叠导致数据损坏 
根因: WCHNET_ModifyRecvBuf 将 socket 内部缓冲区设为 g_json_recv_buf,
但 WCHNET_SocketRecv 又从同一缓冲区(偏移)拷贝到自身 — 源和目的重叠。

修复:
1. 新增独立的 g_json_wchnet_buf 作为 WCHNET 内部接收缓冲区
2. RECV 时从 g_json_wchnet_buf 读入临时 buffer, 再追加到 g_json_recv_buf
3. 两缓冲区完全隔离, 消除重叠拷贝
 2026-06-30 19:04:11 +08:00
wangfq 3e00a352d3 debug: 在 json_process_frame + handle_pwd_verify 增加详细日志 
添加关键路径诊断日志以定位鉴权失败根因:
- json_process_frame: msg_id/cmd/匹配结果/auth状态
- handle_pwd_verify: data提取/password值/dev_pwd对照
 2026-06-30 19:03:00 +08:00
wangfq ae02e58a36 fix: json_get_cmd 未去除引号导致命令匹配失败 
simple_parse_json 提取字符串值时保留双引号, json_get_cmd
直接用于 strcmp 匹配命令表, 因 "pwd_verify" != pwd_verify
导致所有命令都走进 'unsupported command' 分支。
改用 json_get_str_field (自动去引号) 修复。
 2026-06-30 17:52:30 +08:00
wangfq eb79c66763 fix: JSON TCP accept后未配置接收缓冲区导致无法收数据 
根因: WCHNET TCP Server 模式下, accept后的socket需要调用
WCHNET_ModifyRecvBuf 配置接收缓冲区才能正常接收数据。

修复:
1. tcp_json_srv.c: accept时调用 WCHNET_ModifyRecvBuf 设置 recv buf
2. 去掉脆弱的scan逻辑, 改为收到CONNECT+socket不匹配已知socket时自动识别
3. net_srv.c: 同步更新路由条件
4. DBNetClient: 增加原始JSON发送日志
 2026-06-30 17:38:45 +08:00
wangfq af997a79fe feat(vd960DBN): TCP JSON协议服务 — 端口5960, 鉴权+15条命令 
- net_config.h: TCP_LISTEN=0→1, TCP=2 支持 JSON 监听
- 新增 tcp_json_srv.h/c: 行分隔 JSON, pwd_verify鉴权, 命令分发
- 实现15条协议命令: dev_info/ssc_net/iot_net/iot_topic/pwd_set/factory_reset等
- loop_param_set/query 接受命令返回stub(Loop MCU中继待实现)
- net_srv.c: 集成 JSON 中断路由 + init
- peripheral_main.c: 主循环 tcp_json_poll()
 2026-06-30 14:53:53 +08:00