wangfq
|
89ba602e4f
|
fix(vd960DBN): 栈溢出修复闭环 — 打印恢复 + 字符串0终止保险 (2026-08-17)
RAM 瘦身后栈 1.9KB→~4.75KB (END 0x2000f834→0x2000ed3c 实测), printf 峰值安全:
- cfig_flash.c: 恢复 load_cfg 3 处调试 PRINT (magic mismatch×2 + Sub_Code)
- cfig_flash.c: 字符串 0 终止保险 (remote_addr/client_id/username/password/topic_pub/sub
末字节强制 '\0', 防 Flash 字符串不足定长时 %s 越界打印)
- peripheral_main.c: 恢复 output_cfg_from_flash() (调试配置打印)
- 注释更新为修复闭环说明
设备实测: 无复位, MQTT 连 159.75.137.141:1883, BLE 广播正常
|
2026-08-17 14:18:52 +08:00 |
|
wangfq
|
26f2326c96
|
fix(vd960DBN): 栈溢出止血 — load_cfg 去调试打印, output_cfg 暂关 (2026-08-17)
实验D确认 load_cfg/output_cfg 为跑飞触发点。根因: .bss≈46KB
(BLE栈+ETH DMA 7.6KB+SPI_FLASH_BUF 4KB+网络缓冲) 挤占 RAM,
栈仅 ~1.9KB (BOOT_CNT@0x2000f84c 证明 .noinit 被推到 RAM 顶)。
load_cfg 的 printf 栈峰值触顶 → 覆盖 .noinit+返回地址 → PC 跑飞循环。
修复:
- cfig_flash.c: load_cfg 内 3 处调试 PRINT 注释 (magic mismatch×2 + Sub_Code×1)
- peripheral_main.c: load_cfg 恢复(配置加载保留); output_cfg 调用 #if 0 (纯调试打印)
- devlog: 实验D结论 + 修复记录
根治待办: 减 .bss 给栈腾 4KB+ (需 .map 确认大数组);
output_cfg 恢复调试打印前需减栈压力
|
2026-08-17 11:06:56 +08:00 |
|
wangfq
|
452ff68bae
|
test(vd960DBN): 实验D — 栈空间诊断 + load_cfg/output_cfg 触发点验证 (2026-08-17)
新证据: BOOT_CNT@0x2000f854 = .noinit 被推到 RAM 顶, 栈顶(0x20010000)
之下仅 ~1.9KB → .bss≈46KB (BLE/WCHNET/SPI_FLASH_BUF 等大数组挤占)。
栈溢出 → 覆盖 .noinit(g_boot_count 恒1/g_fault_diag 消失) + 覆盖返回地址
→ PC 跑飞跳回 0 → 循环。快照延后无效因为问题不是快照 SPI 而是栈空间。
- BOOT_CNT 打印加 _end(堆起点, 反推.bss大小) + 当前 SP(栈深)
- load_cfg/output_cfg #if 0 (EXPD 标记): 稳定→触发点确认; 仍崩→更晚
- 待用户提供编译后 .map 确认 .bss 组成
|
2026-08-17 11:00:03 +08:00 |
|
wangfq
|
8cf01544f6
|
feat(vd960DBN): 快照区延后初始化(开机3s后) — 避开启动早期SPI重负载窗口 (2026-08-17)
诊断: 08-14恢复快照区后频繁重启。RSTSCKR无复位标志(非硬件复位) +
BOOT_CNT恒=1(.noinit被清, RAM全丢级) + 实验A(跳过offlog_boot)仍崩
→ 启动早期SPI重负载(offlog/snap init 擦+整扇区写回~80ms×2)让系统
进入临界状态, 后续SPI操作(load_cfg读参数区)成为压垮点。
方案:
- snapshot.c/h: 新增 snap_delayed_init(), 主循环每轮调用, 开机3s后
首次进入执行 snap_init (非阻塞, mstick()>=3000 门控)
- peripheral_main.c: main() 移除 snap_init 调用; 主循环喂狗后加
snap_delayed_init(); 撤销实验A(恢复offlog_boot)/实验B(恢复load_cfg)
- 3s内传感帧由 snap_enqueue/snap_flush 的 !_ready 门控自动丢弃不落盘
- 保留 BOOT_CNT 诊断打印(.noinit 计数器+地址)
- devlog 置顶 2026-08-17 条目
|
2026-08-17 10:31:39 +08:00 |
|
wangfq
|
5803255d89
|
test(vd960DBN): 实验B — 跳过 load_cfg/output_cfg, 跑飞触发点下移 (2026-08-17)
实验A(跳过 offlog_boot)仍循环复位 → offlog_boot 非触发点, 跑飞点下移。
新证据: BOOT_CNT 恒=1 (.noinit 计数器每次被清) → RAM 全丢级重启,
RSTSCKR 却无复位标志 → 疑似掉电-恢复(未触发POR) 而非软件跑飞。
- load_cfg_from_flash + output_cfg_from_flash #if 0, 加 EXPB 标记
- BOOT_CNT 打印加 &g_boot_count 地址, 确认 .noinit 段是否生效
(地址 >= _ebss≈0x2000612c 且在 .noinit → 复位不清零; 恒1 → RAM被清)
预期: 不崩 → 触发点在参数区SPI读或%s打印; 仍崩 → 触发点更晚/更早
|
2026-08-17 10:15:21 +08:00 |
|
wangfq
|
0c717e4818
|
test(vd960DBN): 实验A — 跳过 offlog_boot SPI 写, 验证跑飞触发点 (2026-08-17)
日志诊断: RSTSCKR 全 0(非硬件复位) + snap ok 后 71B 乱码 + 无 ASCII 打印
→ PC 跑飞跳回 0x00000000 重启, 触发点锁定 offlog_boot(SPI 32B 页写)。
与 08-12 实验 99ef634 结论一致。
- offlog_boot() 调用 #if 0, 保留 RMVF 清除
- 新增 .noinit g_boot_count 计数器: 每次 main 重进 +1 并打印 BOOT_CNT
(跑飞重启不清零, 区分真复位 vs 跑飞)
- 新增 EXPA: offlog_boot skipped 标记打印
预期: 不崩 → offlog_boot 写实锤; 仍崩 → 跑飞点下移 load_cfg/output_cfg
|
2026-08-17 10:04:52 +08:00 |
|
wangfq
|
8873b334d2
|
feat(vd960DBN): 恢复快照区功能, 移除 sim_snap_spi 实验桩, UART2 波特率注释修正
- peripheral_main.c: snap_init() 恢复 (去 #if 0), offlog_boot() 恢复
(上电复位原因记入事件日志); 删除 sim_snap_spi 模拟写密度实验函数
及主循环调用 (printf 重入修复后 SPI 写无罪已确诊, 实验收尾)
- loop_uart_proto.h/c: UART2 波特率注释 115200/19200 -> 192000
(usart_biz.c 硬编码 192000 为实际值; g_storage_uart_baud=19200
为独立配置项不驱动 UART2, BLE 显示 19200 不代表实际速率)
- devlog: 新增 2026-08-14 条目, UART2 RX DMA 方案列入待办
|
2026-08-14 09:46:23 +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
|
9f5102e9e8
|
feat(vd960DBN): fault_diag — .noinit RAM 现场 + 执行轨迹 marker 定位神秘复位
现象: LUP 帧后复位, RST=0x00000000 (无标志) 且 HardFault 打印缺失
(上次 0x10000000=SFT 确认 HardFault 路径, 这次连打印都没有)
方案: .noinit 段复位不清零, 跨复位留痕
- Link.ld: 新增 .noinit 段 (startup 只清 .bss 不碰)
- fault_diag.h: FaultDiag{magic,mcause,mepc,mtval,marker,boot_cnt} + FAULT_MARKER 轨迹宏
- HardFault_Handler: 纯 RAM 写 mcause/mepc/mtval (官方 __get_MCAUSE/MEPC/MTVAL,
不依赖 UART/printf, 栈坏也能留痕) + 尽力打印
- main 开头 fault_diag_init(): 打印上次现场 + 递增 boot_cnt
- 轨迹 marker: 主循环 LOOP_TOP/UART_SRV/SIM_SPI/POLL_BLE + LUP 链
LUP_FRAME/INGEST/EVT_FEED 入口出口, 复位后看 marker 停在哪一步
|
2026-08-13 15:44:07 +08:00 |
|
wangfq
|
87c8e01936
|
test(vd960DBN): SPI写密度模拟实验 + factory写止血 — VDD跌落诊断
- peripheral_main: sim_snap_spi 模拟快照落盘节奏 (20ms 64B页写 + 每64条切扇区擦除+头写)
- cfig_flash: magic不匹配时跳过 factory SPI_Flash_Write, 用内存默认值继续
(SPI写触发硬件复位死循环止血: 参数区0x00写也崩, RST=0x00000000)
- 诊断修正: CH32V208GBU6 QFN28 无 NRST 引脚, 共线假设作废;
SPI写/擦除→电流尖峰→VDD跌落→内部POR/PDR(2.4V)复位;
BLE射频+SPI电流叠加是头号嫌疑
|
2026-08-13 11:27:08 +08:00 |
|
wangfq
|
99ef6348d7
|
test(vd960DBN): 跳过 offlog_boot 写 — 二分定位 SPI 触发点
f766530(跳过snap)仍崩 → 非快照SPI; 旧固件也有 offlog_boot 32B 写
→ 硬件一直有问题只是未暴露; 另一差异: 事件区 0x010000(旧) vs 0x090000(新)
本版: #if 0 offlog_boot 写 (保留 RMVF 清除)
不崩 → offlog_boot 写(或切扇区擦除)触发; 崩 → 更早 SPI 读操作/非SPI
|
2026-08-12 19:39:50 +08:00 |
|
wangfq
|
f766530609
|
test(vd960DBN): 跳过 snap_init 实验 — SPI 序列还原旧固件
回答'为什么旧固件正常': 旧固件也有 offlog_boot 32B 写, 理论上也踩同样硬件问题
差异: 新固件启动早期 SPI 密度翻倍(snap_init 读+擦+写头) + 快照区首擦
实验: #if 0 snap_init → SPI 序列=旧固件
稳定 → 快照 SPI 触发; 崩 → offlog_boot 本身, 旧固件也该崩(硬件一直有问题)
|
2026-08-12 19:34:55 +08:00 |
|
wangfq
|
9053831f27
|
fix(vd960DBN): SPI 串扰复位软件缓解 — 降时钟+缓边沿, 恢复功能
实验闭环: Flash/SPI 全禁用后设备稳定 (BLE/WCHNET/TCP 全正常)
→ SPI 操作触发复位+乱码实锤; 崩点在 offlog_boot 写 32B (不擦除)
→ 排除电流, 判定 SPI 信号串扰 NRST(复位) + 调试线(乱码)
缓解: storage.c GPIO 50MHz→10MHz 缓边沿 + SPI 分频 4→16 降时钟
恢复: peripheral_main.c 两个隔离块改 #if 0 (Flash + UART2 正常)
硬件根治(待现场): NRST 加 100nF 电容 / SPI 走线远离 NRST / 串阻 22Ω
|
2026-08-12 19:27:47 +08:00 |
|
wangfq
|
22224416a3
|
test(vd960DBN): Flash/SPI 全禁用实验 — 定位 SPI 操作触发复位
UART2 隔离后(06fb009)依旧 80ms 复位循环+乱码 → 排除 Loop 数据路径
Hex 日志: 乱码紧跟 snap ok 后的 offlog_boot SPI 写, 复位标志全 0
= NRST 毛刺复位特征, 疑似 SPI 总线(PA4-7)串扰 NRST/调试线 或 电源瞬态
本版: #if 1 跳过 storage/offlog/snap/offlog_boot/load_cfg 全部 SPI 调用
判定: 稳定 → SPI 触发实锤, 硬件查电源/NRST/布线
仍复位 → 与 SPI 无关, 纯硬件(电源/晶振/其他)
|
2026-08-12 19:21:57 +08:00 |
|
wangfq
|
06fb009773
|
test(vd960DBN): UART2 隔离实验 — 软件禁用 Loop 口定位复位源
现场: RST_REASON 全 0 瞬态复位, 总在 Loop 帧后 ~10ms, 指向 Loop 侧干扰
实验: uart_init 后立即禁用 USART2 + PA3 脱离 UART 功能(上拉输入)
= 等效软件断开 Loop; 同时快照无帧入队, 同步验证 SPI 活动非诱因
判定: 不复位+无乱码 → Loop 数据路径干扰实锤
还复位 → 物理引脚级干扰 或 CH32 自身电源问题
通过后删除此块
|
2026-08-12 19:15:37 +08:00 |
|
wangfq
|
eadc67584f
|
fix(vd960DBN): 复位原因位定义错位修正 — RST_REASON=0x08000000=PORRSTF
现场: RST_REASON 打印 0x08000000, 对照 WCH ch32v20x.h 发现
offlog.h 位定义整体错位 (IWDG=bit31❌实为bit29, SFT=bit24❌实为bit28,
POR=bit25❌实为bit27, LPWR=bit29❌实为bit31)
结论: 0x08000000=PORRSTF=上电/掉电复位 → 电源跌落方向 (SPI擦除电流脉冲?)
修正:
- offlog.h 位定义对齐 WCH 库, 新增 OFFLOG_RST_RMVF=bit24
- peripheral_main.c RMVF 清除改 bit24 (原写 bit27=PORRSTF 只读位,
复位标志从未清除, 历史累积污染诊断)
- 协议文档 boot 事件位解析同步
测试回归全过
|
2026-08-12 18:58:16 +08:00 |
|
wangfq
|
f5b52d5bde
|
fix(vd960DBN): 启动诊断打印 + snap_flush 无条件挂载
现场: 懒擦后仍起不来 (200ms 乱码后死机), 需定位复位/卡死点
- main 开头打印 RST_REASON (RCC_RSTSCKR): 一锤定音区分
IWDG死锁(bit31) / POR掉电(bit25) / NRST外部复位(bit26) / 软复位(bit24)
- 各 init 步骤加标记 (storage/offlog/snap ok), 定位卡死位置
- snap_flush 从 iot_enable 分支移到 Main_Circulation 无条件调用:
原实现 TCP 模式(iot_enable=0)下快照永不落盘, RAM 暂存满丢新
|
2026-08-12 18:42:40 +08:00 |
|
wangfq
|
92887a3d92
|
feat(vd960DBN): 传感快照区落地 snapshot.c + BLE SNAP_STAT/QUERY/CLEAR
- snapshot.h/c: 64B 定长 SnapRec (头部16B + 4x12B 0xC0线圈数据原样)
环形分区独立于事件日志, 快照区 = 总容量 - 固定区576KB - 事件区
- 线程模型: USART2 ISR 只打包+RAM暂存(8深满丢新), 主循环 snap_flush 落盘
(iot_sensor_ingest 在中断上下文, SPI 45ms 擦除严禁进中断)
- dbn_ble_srv: SNAP_STAT(0x28)/SNAP_QUERY(0x29)/SNAP_CLEAR(0x2A)
QUERY 上限 2 条 (64x2+2=130B, ODR 教训防御)
- iot_mqtt_srv: ingest 挂 snap_enqueue, publish_sensor 挂 snap_flush
(放在 READY 检查前, 断网照常落盘)
- peripheral_main: offlog_init 后加 snap_init
- 清空审计: 写事件流 log_clear payload[0]=2
- 测试: test_snapshot.c 8 例全过, offlog/ble_offlog 回归全过
- 文档: DLD960_BLE协议 V1.02 + ROADMAP P1.2 状态 + devlog
|
2026-08-12 17:40:14 +08:00 |
|
wangfq
|
ac3fb512d5
|
feat(vd960DBN): 脱机事件日志系统 (W25Q32 环形) — 解决重复上线取证
背景: 设备挂平台测试出现重复上线(现场未断电), 无本地日志无法区分
设备真复位 vs MQTT 断连重连。iot_handle_suback 每次重连都发
initialize 是重复上线的直接证据, 日志需能区分二者。
实现 (V3.6, ROADMAP P1.2 事件流先行):
- offlog.c/h: W25Q32 256KB 环形事件日志 (头扇区+63数据扇区, 8064条)
- 32B 定长记录: magic/type/len/flags/seq/ts_ms/unix_ts/boot_seq/payload[12]
- 8 类事件: BOOT(复位原因)/IOT_CONNECT/READY/DISCONN/RECONN/
EVT_RETRY/GIVEUP/COIL/TIME_ANCHOR/LOG_CLEAR
- 掉电恢复: 头扇区写指针锚点 + 上电 seq 连续性扫描
- 编译期断言防 32B padding 回归
- 插桩 (全部主循环上下文, socket 中断内不写 SPI):
- main(): offlog_init + RCC_RSTSCKR 复位原因采集/清除
- iot_mqtt_poll(): MQTT 状态沿检测 (CONNECT/READY/DISCONN)
- 重连退避/TCP超时/CONNACK拒绝: RECONN/DISCONN(4)/(3)
- iot_evt_process/enqueue: EVT_RETRY/GIVEUP/COIL
- net_srv.c dev_time_sync: TIME_ANCHOR 时钟同步锚点
- tests/test_offlog.c: gcc 隔离单测 6 例 (mock W25Q32 NOR 语义)
关键坑: ①中断内写SPI阻塞 ②结构体36B padding致环形错乱
③扇区级覆盖粒度count扣减语义 (均单测抓出)
待办: P1.3 导出命令(log_query/stat/clear) + 快照流 + 复位原因板上验证
|
2026-08-04 15:04:12 +08:00 |
|
wangfq
|
3d017ccca9
|
fix(vd960DBN): IoT MQTT 栈独立接管 socket 事件, 消除双 CONNECT 致频繁 initialize
root cause: WCHNET_HandleSockInt 在 iot_enable=1 时仍走旧 MQTT 代码:
CONNECT → mqtt_connect() ← 发 MQTT CONNECT #1
iot_mqtt_poll() → send_connect() ← 发 MQTT CONNECT #2 (同一socket)
broker 见双 CONNECT → 协议违规踢线 → 4s 后重连 → 循环
RECV → mqtt_data_manage() ← 旧代码收 CONNACK
→ dev_initialize_pub() ← initialize msg_id=1, 强设 g_iot_state=READY
fix:
1. net_srv.c WCHNET_HandleSockInt: iot_enable 时直接调 iot_mqtt_handle_sock_int
2. peripheral_main.c: poll_mqtt() → iot_mqtt_poll() (IoT 自有 PINGREQ)
BSS savings: -1024B (data_json eliminated), send buffer 隔离 (v3)
|
2026-07-23 11:25:52 +08:00 |
|
wangfq
|
c17b67d185
|
refactor(vd960DBN): MQTT 重构,对标 DBN101GA 参考项目
net_srv.c 改动:
- WCHNET_HandleSockInt IoT 分支:SINT_STAT_CONNECT 直接调 mqtt_connect(),
SINT_STAT_RECV 调 mqtt_data_manage() — 复用已有的 SocketId_TCP/mqttBuf/mqttData
- 新增 mqtt_data_manage(): 处理 CONNACK/SUBACK/PUBLISH/PINGRESP
- 新增 poll_mqtt(): 心跳 PINGREQ (~9s)
peripheral_main.c 改动:
- IoT 模式下 poll_mqtt() 替代 iot_mqtt_poll()
对标 DBN101GA 的关键差异:
- net_srv.c 已有完整 mqtt_connect/mqtt_publish/MQTT_Subscribe/MQTT_Pingreq
- SocketId_TCP 由 WCHNET_CreateTcpMqttSocket 创建,不再自建 socket
- SINT_STAT_CONNECT 直接发 MQTT CONNECT,不延迟
|
2026-07-06 17:21:48 +08:00 |
|
wangfq
|
0c8402d726
|
fix(vd960DBN): MQTT socket 复用 SocketId_TCP,对标官方 WCHNET MQTT 例程
根因分析:iot_connect_broker 自建 socket 与 WCHNET_CreateTcpMqttSocket
创建的 SocketId_TCP 冲突(重复创建),且自建 socket 的 WCHNET_SocketSend
崩溃。官方 MQTT 例程使用统一的 SocketId/SocketId_TCP 模式。
改动:
- peripheral_main.c: 恢复 WCHNET_CreateTcpMqttSocket() 调用
- iot_connect_broker: 不再创建新 socket,直接复用 SocketId_TCP
- 全链路(SocketSend/HandleSockInt/poll)通过 g_iot_socket=SocketId_TCP 统一
|
2026-07-06 16:09:22 +08:00 |
|
wangfq
|
c0220c1d37
|
fix(vd960DBN): IoT socket 重复创建 + broker IP 解析错误
- iot_connect_broker: 删除 memcpy,get_ipstr_to_array 已正确解析 IP
之前 memcpy 把原始 ASCII 字节覆写到 broker_ip,导致 IP 变成 49.50.49.46
- peripheral_main.c: IoT 模式下跳过 WCHNET_CreateTcpMqttSocket,
由 iot_connect_broker() 统一管理 socket 生命周期,避免重复创建
|
2026-07-06 10:46:51 +08:00 |
|
wangfq
|
5333fe40de
|
refactor(vd960DBN): replace compile-time NET_SSC/NET_JSON/NET_IOT macros with runtime g_sub_code_enable.iot_enable
- Remove NET_SSC_ENABLE, NET_JSON_ENABLE, NET_IOT_ENABLE from net_config.h
- Socket config always allocates max: 1 UDP + 2 TCP + 1 TCP_LISTEN
- All #if guards in net_srv.c/h and peripheral_main.c replaced with
runtime g_sub_code_enable.iot_enable checks
- iot_enable=0 -> SSC mode (UDP + TCP client + JSON server)
- iot_enable=1 -> IoT MQTT mode (MQTT client via iot_mqtt_srv)
|
2026-07-03 18:07:32 +08:00 |
|
wangfq
|
9629729dc9
|
feat: IoT MQTT 客户端实现 — NET_SSC_ENABLE=0 时启用
新增文件:
- iot_mqtt_srv.h/c: MQTT 客户端 (TCP→CONNECT→SUBSCRIBE→READY)
支持: dev_info_query, pwd_verify (其他命令框架预留)
上报: loop_data (传感器), heartbeat (心跳 60s)
断线重连: 指数退避 5s~60s
协议: DLD960 IoT MQTT V1.00 (dld960/{sn}/...)
修改:
- net_config.h: 新增 NET_IOT_ENABLE = !NET_SSC_ENABLE,
IoT 模式分配 1 TCP socket (MQTT client)
- net_srv.c: IoT 初始化 + socket 中断路由
- peripheral_main.c: IoT poll + sensor publish 调用
模式:
NET_SSC_ENABLE=1 → SCC + TCP JSON Server (原有行为)
NET_SSC_ENABLE=0 → IoT MQTT Client (新增)
|
2026-07-03 17:36:22 +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
|
e5c99069a0
|
refactor: 用 NET_SSC_ENABLE 宏隔离原有 TCP/UDP 代码,默认=0
net_config.h:
- 新增 NET_SSC_ENABLE=0, NET_JSON_ENABLE=1 功能开关
- WCHNET_NUM_UDP/TCP 根据开关条件编译
- 默认仅保留 JSON TCP server (1 TCP socket),SSC 全部禁用
net_srv.h:
- SocketId_TCP/UDP extern 放入 #if NET_SSC_ENABLE
- WCHNET_CreateTcpSocket/MqttSocket 原型放入 #if
net_srv.c:
- SSC/MQTT 变量和函数全部置入 #if NET_SSC_ENABLE
- WCHNET_HandleSockInt 中 SSC 处理分支置入 #if
- net_srv_init 中 WCHNET_CreateUdpSocket 和 memset(socket) 置入 #if
- JSON routing 保持无条件编译
peripheral_main.c:
- WCHNET_CreateTcpSocket/MqttSocket 调用置入 #if NET_SSC_ENABLE
tcp_json_srv.h:
- 移除 SocketId_TCP/UDP extern(JSON handler 不再引用)
影响:NET_SSC_ENABLE=0 时设备仅运行 TCP JSON server (port 5960),
原有 SSC UDP/TCP/MQTT 代码不参与编译,零干扰。
|
2026-07-01 11:33:32 +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 |
|
wangfq
|
95808f9f25
|
refactor(vd960Loop): 算法回退到 DLD154V4B,四通道适配
- 用 DLD154V4B vd1_task/per_channel 替换 vds_task 复杂算法
- 移除 FUNCTION_B/二次判断/快速变化/多重确认等增强特性
- 保留平坦性离开算法 (CN200910309382),每通道独立状态
- 灵敏度表改为 DLD154V4B 4级: {216,108,36,10} / {108,72,18,9}
- 清理废弃类型: FltHistoryManager, Loop_ACS_Info, StageRangeConfig 等
- 首次添加 vd960DBN 完整源码
|
2026-06-25 16:21:57 +08:00 |
|