69d70af4cf2a9ad63292d454f062f63cb426b508
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 wandering1
|
45086cf5f9 |
refactor(104): [comm] 段实现搬进配对模块 iec104_comm.c 并同笔补双端注册
上一笔
|
||
|
wandering1
|
e7136cbea3 |
feat(104): [comm] 配置段落地，公共地址与端口由 defaultTask 读、iec104 服务端消费
新增 App/protocol/iec104/iec104_comm.h + iec104_pts.c 内的 [comm] 段实现：内核前由 app_main.c 调 iec104_comm_init()（H1，与 run_par_init 同批），合法带自愈、非法回退 出厂值并留痕；ca 在任务启动时填一次、port 每次 bind 现取（H2，iec104_serv.c/.h 共 6 处取值来源），iec104_link.h 里那个从不生效的死 define IEC104_PORT 删除并改为指向真 源的注释。零新增 .c 之外的注册面（.h 不进注册钩子）；s_src_yk_exec / s_clock_sync 两个记录投递点一字未动。 主站地址白名单本批**不做**并写明理由：CH395F 单连接 socket 上「拒绝即 close + 重 listen」等于给扫描风暴开门，且该值当前没有任何既有消费点（详见网络配置说明 §3.6）。 生效方式是重启生效，不新增事件位。 三套主机单测：cfg_file 207/207、iec104 174/174、iec104_serv 37/37；断言只增不减， 逐字节对账（HEAD 161/155/35 → 168/175/38，测试文件 diff 删行数为 0）。编号形态已 整改：4 处裸号改成带模块码（TC-IEC104-031~033），新用例的属主登记处定义补进配置文 件单元测试说明.md（TC-CONFIG-056/057），模块游标抬到 TC-IEC104-033。 改后实测（作者自跑 @build：0 错误 0 警告，Code 228,812 / RO 25,060 / RW 1,456 / ZI 135,976）：RW_CCM 57,376 = 87.9% 未动、RW_IRAM1 +16 B（61.0% 不变，来源是 s_cfg 去 const 的 RO→RW 搬家，s_comm 那 4 B 吃进 pts .data 原有对齐余量）、ZI 增量 0；静态最坏链 iec104Task 1,456 → 1,464 / 2,560（余 42% PASS）、defaultTask 3,040 （40% PASS）。本笔净增：RAM ≈16 B、CCM 0、ROM ≈0.4 KB，与立项预估同级。 越域两处按纪律点名：App/app/app_main.c 与 App/task/iec104_serv.c/.h 属 H1/H2 批准 钩子（各 3 行与 4~6 行），其余改动都在 iec104 目录与本模块测试内。 ui_data_feed.c 切 getter 留给 task-9（serv.h 注释已埋交接痕）。 编号游标本笔一次抬三处（TC-IEC104-033 / TC-CONLOG-179 / TC-UIDATA-026）：后两个是 为**已在飞的两条道**预留，号都已由各自用例落定义，先抬是为了避免它们提交时再撞一 次门禁；游标只表示"已发出"，不代表对应用例已入库。 为什么本笔与下一笔（控制台）也走 --no-verify：UI 道正在写 task-6（页面实例已落盘但 还没在 ui_menu_tree.txt 绑叶子），此刻任何 staged 组合下 generated-fresh 都会红在别 人的半成品上，而 stash 又会把人家在飞的整棵树打回 HEAD——两害相权，改为逐条实跑相 关门禁 + 留证，**全量钩子实跑放到 UI 落地后的收尾一笔**（届时工作树静默，才是有意义 的那一次）。已逐条跑过：@build 0 错误 0 警告（作者自跑，与本侧构建逐字节同码）、 check_ids.py --strict **退出码 0**（不可判定 1,154 / 上限 1,166、可判定 86.63%）、 bom-guard 无红（本笔不碰 BOM 名单文件）、mojibake 无 U+FFFD、三套主机单测全绿。 mem-budget 会红的成因是磁盘 .map 混着 UI 道在飞代码与 HEAD 台账不同码，按约定由收 尾一笔统一回填。 |
||
|
wandering1
|
77779d49d6 |
feat(ui+记录): 整定写路径与四类页落地，五类记录写入方补齐
UI 面：ui_data 增加深度 4 参数写队列（请求 168 B、队列 .bss 672 B）与状态机 OK/ERR_RANGE/ERR_LOCKED/ERR_BUSY，ui_data_feed 出队后按注入 ops 走「闭锁 → 整批 预检 → 逐项 prot_set_set_sealed」，只提交改动位图；par 帧尾追加 cal_block （口径 = UA/UN/IA 三路 ADC_CAL_F_VALID，与 protect_task 判据同构，不用 rt.eng 反推，V0.1 下 eng 恒 0）、UI_DATA_VER 升到 2。参数/定值/控制字/软压板四叶绑定 内容页（UI_PAGE_MAP_COUNT 12→16，复用四个查看模块，零新增 .c），编辑态按 is_editable 分派，LOCK（写不进去）与「未标定」（仍可改值）两源两通道两词。 记录面：syslog_request_clear/state/apply 三段式删除 API（UI 只发请求，落地在 defaultTask 的 drain 尾部且必须后置，卷锁一律 try，幂等只认 FR_NO_FILE）； 事故/告警/启动/操作/遥控五类各有一个真实写入点，记录类型 = 日志 ID 本身 （一类一个 /log 严格 8.3 文件；64B 定长体没有类型字段位，塞字段会砸掉既有读者）。 为守 protectTask 872 B 静态最坏链另拆 syslog_post_quiet()（无 DBG 的投递核， 丢弃留痕挪到 drain 侧差值补发），syslog_post 对外语义逐字不变。 为什么两道合成一笔而不是各一笔（实测，不是省事）：simulator/main.c 同时消费 两道新增 API（整定 pump 与 logtest 清除用例），按道切文件会让中间提交编不过； RAM 受管快照与体积同码凭证描述的是合并后的 .map，拆开必落在「台账与 .map 不同 码」这条红线上。pre-commit 跑钩子前会 stash 未 staged 部分，这类耦合没法绕。 实测：@build 0 错误 0 警告；Code 228,260 / RO 24,960 / RW 1,440 / ZI 135,976 B； RW_IRAM1 79,992 B = 61.0%、RW_CCM 87.9%（阈值 92%）；九个任务静态最坏链全 PASS， protectTask 872 B / 57% 改前后逐字节不变（记录投递没垫栈）。主机单测 ui_data 82→ 164、sys_log_mcu 106→137、prot_elm 47→60、iec104 141→154、iec104_serv 28→34， 既有断言零删改；48 个钩子 --all-files 全绿；编号门禁可判定 86.34%（基线 86.0%）、 不可判定 1,153 处低于上限 1,166；doc-links 无法判定 0；UI 黄金 18 页扩到 27 页 连跑两次逐字节一致；字库 diff 空。 顺手修掉三处既有缺陷（都是本轮第一个消费者才暴露）：sim_syslog.c 的 s_paths 行宽 16 而 "sim_selftest.log" 正好 16 字符没有 NUL 位（stat/remove 读越过数组尾，此前 靠后面 .rodata 碰巧为 0）；ui_w_setlist 二态行 ENTER 不回绕（控制字与软压板出厂值 全在最后一项，按了像没反应而叠层里已是越界值）；生成物 ui_menu_tab.h 与 gen_menu.py 模板漂移（上一笔改了模板没重跑生成器），现随生成器输出对齐。 未收口（不算完成）：保存后重启值保持与主站 C_RD 读回两条只能上板，台架窗口执行； LOCK 屏显与越界反显的页面侧在模拟器造不出来（模拟器不跑定值自检、无 NAND）， 已由生成侧单测与代码注释点名差距；同类页数与钩子数陈述残留另立待办。 |
||
|
wandering1
|
8c72698666 |
feat(运行参数): 卡10 run_par真源收编+104段0x8020~0x8058读写映射（道D M6-①）
新增 App/algo/run_par.c/h（「数据可信」卡 10，lead 四裁落地）： - [run_par] cfg 段：遥测死区 9 键 int32 毫单位（db_ua…db_freq），工厂默认 = 卡 6 额定 0.5% 档（500mV×4 / 5mA×4 / 500mHz）；注册走 adc_cal 同款内核前 契约（app_main_init），不挂回调 = 引擎副本即生效值；键数 9≤16 不拆段 - 真源收编（裁③）：pts 层 s_yc_db 运行时副本删除，COV 每拍实时读 run_par （协议→算法向下依赖，同 meas 先例；无投递无缓存 = 顺序/幂等平凡成立）； iec104_pts_yc_set_deadband()/deadband() 保留为转发壳，壳内保留"成功清 半截确认计数"语义并由 TC-IEC104-027 追加断言钉住（裁⑤） - 104 地址映射（裁①）：0x8030~0x8038 死区 9 点 / 0x8040~0x8047 k 覆盖 / 0x8048~0x804F b 覆盖（逐项地址本仓自定——复现规划 §5.4 权威表不在仓， 送检点表到位后替换 run_par.c 顶部常量段一处；已在 IEC104 §3.4 表头挂账）； 路由顺序 = run_par 表先、未命中落 prot_set——0x8027~0x802A 属 prot_set 告警段永不覆盖，TC-IEC104-029 双向往返钉死；空隙地址自然 COT14/PN - 通道系数覆盖 = adc_cal_set 代理（裁②a）：合法带/越带 [ERR] 留痕全复用， run_par 不存第二份系数（防双真源）；单侧写 RMW 用另一侧当前生效值； 回显 = 生效值视图（文件坏值被哨兵回退 ROM 时主站看到的就是下游吃到的）； adc_cal 配套：+adc_cal_b_codes() 读取口（回显/RMW 用）+ set() 授权写者 注记扩至 iec104Task 直通路径（单字原子契约同「数据可信」§4.4） - 持久化（裁②b）：新事件位 SYS_EVT_RUN_PAR_SAVE(1<<8)；iec104Task 主循环 peek 投递 → defaultTask run_par_store_save() 一条事件一趟 cfg_file_save 整档外科（覆盖 [run_par] 9 键 + 联动 [adc_cal] 两段）；失败脏保留 = 天然 重试（B7 prot_set 同款）。C_SE 现行无"暂停/测试态"门控——文档现行如此 不造新语义，送检若要求接线点已写进 §3.4 注（裁④） 测试：新建 test/host/run_par（TC-RUNPAR-001~008，67 断言，真实 cfg 引擎 + 真实 adc_cal + 内存虚拟盘同 adc_cal 套件先例；[run_par] 注册契约/落盘往返/ 外改文件即副本生效/两段式不提交不置脏/合法带拒+RMW+生效值回显/init 幂等 重注册留痕）；iec104 套扩真链 TU（cfg_file+adc_cal+run_par 非桩，141 断言： +TC-IEC104-029 路由 + 壳清确认计数 3 断言）；meas 套静态更名 s_snap*→ s_ms_snap*（与 cfg_file.c s_snap 同 TU 相撞，D1 同款改名法，226 断言不变）； iec104_serv 套补 run_par_dirty_peek 假件。id_registry 建族 TC-HOST-RUNPAR （游标 008）+ TC-HOST-IEC104 游标 028→029；新钩子 run-par-unit-test + iec104 钩子触发面随真链扩；uvprojx +run_par.c（合法入库）+ SIM_EXEMPT 登记 （模拟器不编 104 协议，已核实 CMake 面）。 文档：IEC104 §3.4 运行参数段表（含送检替换账/门控未来条件/代理声明）、§7、 §8 第 4 条、变更记录；网络配置说明新增 §3.5 [run_par] 键表；复现规划 §5.4 补运行参数段落实进度。**遗留（交 lead）**：数据可信 §4.4 "引擎 RAM 副本" 一节当时的措辞对象含 pts 侧副本，s_yc_db 删除后该句过时（裁③b 点名，§4.4 在写域外未动）。 gate：@build 0/0（Code=219620 RO=22036 RW=1280 ZI=132864）；vs 0cbae7d： Flash +1912B、RAM(RW+ZI) +8B（37B 新静态被链接器并洞吸收）；iec104Task 栈 1456B/margin 43%、defaultTask 3032B 不变；id-check/doc-links/cppcheck/ coding-standard 实跑过；--all-files 全量 45 钩子实跑（43 绿 + 仅 mem-budget / mem-numbers 两红 = 台账受管区 vs .map 漂移，回填属 lead 单写者区，批 1/道D-1 /D2 同口径）：gate: only mem-budget/mem-numbers pending lead ledger backfill BOM/CR/U+FFFD/字面量 ASCII 逐文件自查通过。 |
||
|
wandering1
|
924ac3d428 |
test(host): 断言字面量统一纯 ASCII，30 文件 1535 行
用户裁定「统一」。口径就是 AGENTS 铁律：字符串字面量必须纯 ASCII （无 BOM 文件里奇数个汉字会吞掉结束引号，偶数才侥幸通过），中文只写注释。 四名队友按目录分四组并行、写范围互斥：net_socket 418 行（6 文件）、 console_log/sys_log_mcu/soe_store/cfg_file_store_mcu 268 行（4 文件）、 11 个存量套件 404 行 + adc_input 89 行、iec104 与 lftpd 与 NET 四套等 356 行 （9 文件）。runner 的 .py 文档串不在口径内（Python 源不经 ARMCC 代码页）。 两套口径必须分清：粗口径（按行切引号）普查 = 34 文件 / 1,552 行；严格口径 （状态机剥掉块/行注释与字符常量后再取字符串字面量）= 30 文件 / 1,535 行。 差值那 4 个文件的命中全在注释里（ns_peers.c、net_socket/stub/ns_rtos.h、 common/ch395f_fake.h、common/fatfs_fake.c）——按口径一处都不该改，改了等于 把中文从注释里搬走、正好违背口径。粗口径绝不能当交付判据，否则要么白改 注释、要么留下「这行为什么没改」的悬案。 Lead 独立终检（不采信自报）五条硬判据，结果 30 文件漂移 0：① 每文件 TC 号 集合与 HEAD 逐字相同 ② 断言宏调用点数不变 ③ 行数与 HEAD 完全相等（专抓 整文件回写把尾部含 main() 吃掉的截断，第 1 轮真发生过两次）④ 剥注释后代码区 非 ASCII 字符 = 0 ⑤ 字节卫生（BOM 与 HEAD 一致、无 CR、无 U+FFFD、单尾换行）。 另用「逐行把字面量整体替换成空串后与 HEAD 必须逐行相等」机械证明只改了字面量； 各套 --module 覆盖率与断言数逐字不变（net_socket 887/889·53/53、console_log 199/200·16/16、sys_log_mcu 324/326·13/13、adc_input 103/103、sys_clock 100/100） → 生产码零改动，基线不需重登。 闸拦下一处真实回归（我的验收器没抓到）：ns_s6_edges.c 翻译时把一个上一轮 已整改成平实描述的编号又写回了 CHECK 标签。原因很清楚：「只改字面量」并不 等于「只改无害内容」，标签里完全可以带进未登记族的编号形态；而 Lead 的自动 验收器只比对了 TC 形 id 集合，未覆盖 L/E/N/S/TRAP 等族。教训：批量改标签的 守卫必须加一条「新串不得出现任何已登记前缀族之外的编号形态」，且结构不变式 只覆盖自己想到的维度时不能替代真闸。 Lead 自查另清掉 126 处写坏的反斜杠（JS→Python 转义层数翻倍，把 markdown 反引号写成反斜杠+反引号），恰好发生在记录这条教训的那一节里。 文档：docs/测试说明/主机单测覆盖率口径.md §9 新增「第 2 轮」小节（两套口径对照 表、五条终检判据、六条手法含「转换说明符序列必须逐位相同」取代「禁止裸 %」、 三条协作纪律含先改板再派工与临时文件带组前缀、后续项 3 条）+ 变更记录一行。 后续项（本轮不做）：把剥注释词法扫描器收进 scripts 当门禁（需用户点头并先定 test/ 是否纳入 coding-standard）；iec104 的简写编号归族（牵 id_registry， 不能顺手做）；替换器加「编号形态白名单」校验。 gate: pre-commit run --all-files -> 39 hooks, 37 Passed; failed = mem-numbers + mem-budget（受管快照与本树 .map 的漂移，属第 1 轮生产码改动的遗留，非本批 增量）。本批只碰 test/host/**，不进 Keil 编译面也不进模拟器 CMake，**RAM/Flash 增量 = 0**；实测水位 RW_IRAM1 57.4%、RW_CCM 87.9%，均低于 92% 红线。 id-check 0 台账外新账（可判定 84.63% > 基线 82.6%）；test-coverage 33/33 全绿； cppcheck / coding-standard / bsp-err / layer-deps / doc-links 全 Passed。 按仓内分支约定 --no-verify 提交，台账 --write 回填留待主工作树合并后。 |
||
|
wandering1
|
ec2dbc9e01 |
chore(merge): 回填内存台账与钩子规范化，收口 task/cov-host-line-coverage
done cov 已把 15 个提交合入主干（合并提交 c8de948），但它的门禁按已知顺序跑在 @build 之前（skill 实测陷阱那条），比对用的是合并前的旧 .map，台账必然失配。 这里按 skill 的官方处置在主工作树回填，使主干自身全绿。 内存台账（@build 已在 done 里跑过：0 错 0 警，Code=213652 RO=18860 RW=1192 ZI=131504；主工作树的 .map 是权威值）： - scripts/ram_baseline.py --update（趋势行 2026-10-24：RW_IRAM1 75,272 B 57.4% / RW_CCM 57,376 B 87.9%）+ --write（受管区）；check_mem_numbers.py --write。 - RAM使用分析与优化方案.md 两处正文数字：「当前状态」那句刷成合并后的真值 （75,264 → 75,272，日期改 2026-10-24）；2026-10-23 那条变更行里的裸 B 值 232,536 改为 KB + 快照文件指针——**历史结论一字未改**，只是不再在正文里留 会过期的裸字节值（--scan 的判据正是"曾是区域值、现已不是"，无内联豁免）。 - 补一行本次合并的变更：RAM +8 B（net_cfg.c 为 WAIT 契约修复新增 s_save_busy）、 Flash -24 B（lftpd_string 改名删死循环 + net_select 去冗余守卫）、CCM 零增量。 覆盖率口径文档：修我自己留下的占位符泄漏——§9 有一段写的时候用 @@ 当反引号哨兵 （run_code 里反引号与模板串冲突），漏做还原，共 52 处。后果不只是难看： - `docs/网络/网络自愈架构设计.md` §4.10 因失去反引号而不再被识别为"紧邻写法"， 被 doc-links（钩子带 --sections-strict）按**自引用**判成失效章节——这条真红了。 - "test/host/common/ch395f_fake.h + .c" 被整体当路径引用检查，报文件不存在。 - 另有一处未配对的 @@ 与一个 ``` 残留，以及过期计数（"套件 21+"、"族数 16"）， 改为落地实测值：TC-HOST 族 16 → 22、套件 16 → 28，并指向下方落地进度表。 核对：该文档 @@ 残留 0、U+FFFD 0、无 CRLF。 12 个 run_unit_test.py：end-of-file-fixer 去掉末尾多余空行。分支期我用 --no-verify 提交（只为跳过 .map 台账那两条已知误报），把这两个改写型钩子的规范化机会一起 跳掉了——本批由钩子自己改正，**内容零改动**，也正是"提交门禁不该长期绕过"的账单。 自查：pre-commit run --all-files 在本工作树 **38 Passed / 0 Failed**（含 16 个主机 单测钩子实跑）；doc-links --all --sections-strict 0 问题；mem-numbers --scan 绿。 未 push（推送需用户明确指示）。 |
||
|
wandering1
|
957ec64645 |
test(APP/104): iec104_serv 模块（28 条，84.2%）——P1 十三块全部进分母
P1 收官批次。新增 test/host/iec104_serv/，iec104_serv.c 覆盖 117/139 = 84.2%。 做法：把生产源整个 #include 进 TU，直接驱动它的 7 个 static 辅助函数——**不跑 iec104_serv_task 的无限主循环**（那是 never-returning 的任务体，不适合单测；事件组 相关支路用 sys_evtHandle=NULL 走"不可用"分支）。链路层与 pts 层给假件：链路协议本身 有 test/host/iec104 的 97 条专测，本模块只管服务怎么活、怎么死、怎么重生。 钉住的契约： - 建监听：2404 端口过 htons、绑 NET_INADDR_ANY；socket/bind/listen 任一失败都要把 已经拿到的号关掉（漏关就是每次重试漏一个 socket 号，CH395F 只有 8 个）。 - **网络代次一变就拆掉旧连接与旧监听并重建**：现场改 IP 后端口必须在新地址上继续 服务，这条不重建就是"设备换了 IP 之后 104 主站再也连不上"。 - accept 门控：监听未就绪不 accept；表项已失效时把监听号丢掉、下一轮重建。 - 单连接 socket 的断线语义：对端 FIN 时只关数据口，**监听必须留着**；数据号与监听 号同一个时绝不关（关了就端口失联）。recv 返 -1 且 errno 是 WOULDBLOCK 是正常空转， 不能当成错误丢连接；真错误则丢弃并**当场重建监听**，不留空窗。 - 判死用**连续**短写计数：一次成功即复位。写成累计就会把偶发拥塞误判成断线，主站 看到的就是莫名掉线（连到 3 次才判死，I104_SEND_FAIL_MAX）。 - 32 分频探活：无可读数据时不是每轮都去收（省 CPU 预算），到点才收一次；对端 FIN 后 复位计数器。协议状态掉回 IDLE 也要丢并重生（否则服务挂着但永不服务）。 - 时钟桥接两个溢出边界：epoch 秒超过 32 位一律拒绝且不碰时钟（截断写进 RTC 就是乱值）； 未对时（sys_clock_get 返回 UINT32_MAX）回 UINT64_MAX 哨兵而不是 0（否则对端会以为 设备时间是 1970-01-01）。 主机侧兼容处理（写进桩注释）：真实 App/util/sys_clock.h 会 include sd2506.h（RTC 芯片 驱动）一路拉到 HAL，PC 上编不动，故桩掉 sys_clock.h 但**两个签名与真实头逐字一致**； 104 的头散在 App 与 Drivers/BSP 的多个子目录（iec104_serv.h/iec104_link.h/iec104_pts.h/ task_watchdog.h/sys_events.h/prot_set.h/sd2506.h…），逐个手写 include 目录必漏且报错会 落在被测源上、极易误读成生产代码坏了——运行器改为**按目录实际是否含 .h 自动收集**。 自查：初跑红 2 条，都是我的场景问题（分频到点那轮 recv 返回 0 会走对端 FIN 支路， 应给 -1 + WOULDBLOCK；"重建失败丢监听号"必须同时让表项失效），改正后 28/28。 P1 收官合计：12 个新模块、**308 条断言**；套件 16 → **28** 全绿；files_tested 19 → **32**； 未触及 .c 47 → **34**；恒等式 34 = 0(P1 剩) + 5(P2) + 29(P3)；分母 2,893 → **4,684** 行； line=4020/4684（85.8%）、func=300/333（90.1%）。百分比"降"是摊薄不是回退（lftpd.c 64.3%、 lftpd_io.c 53.5% 这类只测主体的文件也进了分母），按 §5 口径该盯 files_tested/files_untested。 亮点：lftpd_inet.c **127/127 = 100%**、net_listener.c 99.2%、net_events.c 97.8%。 编号补建 TC-HOST-I104SRV（游标 041），TC-HOST 族数 20 → 22。§9 的落地进度表补齐并 统一为 NET 拆出的四块 ①②③④。 自查门禁：test-cppcheck Passed；check_ids --strict 通过；doc-links 35 处（= 存量）； 10 个新增/改动文件 BOM/CR/U+FFFD/行尾逐项净。零生产代码改动，未跑 @build。 --all-files 仍只有 mem-numbers / mem-budget（.map 台账漂移，等 Lead 合并后统一回填） 与 ui-golden（ref/*.bin 不入库）三条失败，与本分支改动无关。 |