Files

T

wandering1 343305b433 feat(adc): 心跳新增 adc: 行输出 9 路原始码值，并补卡 0 台架注入验证流程

背景：ADC 采集的软件链路已全部打通（节拍、语义取数、折算、相量、
200 ms 快照、104/UI 消费），但"读数对不对"从未验证过——卡 0 的
已知电压注入一直挂账。挂账的直接原因之一是读数出口不够用：
固件只有 cal: 行（UA/UN/IA 三路，mV）与 first: 行（9 路码值，仅
开机一次），验 8 个通道 × 3 个注入点要复位二十余次。

改动一（App/task/adc_task.c，v3.3）
- 心跳新增 adc: 行，每 10 s 输出 9 路原始码值，与 first: 行同序
  同格式，台架"改电压 → 读一行"即可对表，全程免复位。
- 不并入 cal: 行：9 个码值会把该行推到 168 字符，撞
  DBG_CON_LINE_MAX(192) 的静默截断边界（截断不报错，只会少打几路，
  是最难发现的台架假数据来源）。
- 无新增跨任务状态、无新增外设访问；栈 +36 B（局部码值数组），
  adcTask 静态最坏 1400 B / 余量 1160 B（底线 1024 B），stack_report
  PASS；静态 RAM 不变，Flash +188 B。

改动二（新增 docs/测试说明/ADC前端注入验证流程.md）
- 卡 0 的执行侧：注入点清单、期望码值表、零点/线性/映射/极性/节奏
  五步、现场记录表、安全红线、已知坑。
- 固化 2026-10-27 的网表结论：逐通道追 V0.1.tel 确认 ADCn 节点上
  只有"串阻 2 脚 + 滤波电容 + 转换器引脚"，没有对地分流电阻；所谓
  "1k 到地"是 TPAFE 负输入脚 AIN_nGND 经 1k 拴到 AGND 的差分滤波。
  故本板不存在 2:1 分压，端子侧斜率 = 引脚侧斜率 = 6553.6 / 1241.2
  码/V。数据可信.md §2.1 的 305.18 / 1611.3 µV/码 确认不成立。
- 不验交流：台架无信号源，且五路单极性削顶。

改动三（索引与指针）
- docs/README.md 测试说明索引、测试文档模板规范.md 的 ADC 缩写行
  （原"待立"）同步。
- 数据可信.md 卡 0 增加指向该流程的指针（本表只写判据，不写怎么
  接表笔）。

门禁：Keil 构建 0 错误 0 警告；check_ids --strict 通过；
check_doc_links --all --sections-strict 通过（193 文档 / 2871 处引用）；
pre-commit 全过（含 cppcheck、编码规范、体积档、标定层与量纲回归
单测）；两处内存台账已按 --write / --update 刷新。

2026-10-27 15:14:07 +08:00

8.5 KiB

Raw Blame History

RAM 预算台账（配额 · 趋势 · 门禁）

定位：docs/内存管理/RAM使用分析与优化方案.md §8.2 模板与内存治理三件套的落地件（2026-10-12，登记簿条目「缩堆迁 CCM 后半（暂缓）」的已落地前半）。回答三个问题：每个子系统还能用多少 RAM（配额）、总量趋势往哪走（基线 TSV）、 超了怎么拦（92% 门禁）。

数字不手抄：下方受管区由 scripts/ram_baseline.py --write 从 .map 生成， pre-commit mem-budget 钩子校验一致性（同 mem-numbers 的"事实源唯一"思路）。配额是规划值，本文件 §2 是配额与阈值的唯一权威（2026-09 体系评审提出、2026-10-12 落地后报告侧条目已销项），改动 = 先登记本文件 §6 变更记录，再改 ram_baseline.py 的 QUOTAS。区域放置与 DMA 可达性规则 → 内存内容分配策略.md（本文件不重复）。

1. 区域预算与门禁（受管区）

区域	用量	容量	占比	门禁（≤92%）
ER_IROM1 (Flash)	261,764 B	1,048,576 B	25.0%	参考
RW_CCM	57,376 B	65,280 B	87.9%	PASS
UNINIT_CCM	48 B	256 B	18.8%	参考
RW_IRAM1	81,072 B	131,072 B	61.9%	PASS

子系统（静态 RW+ZI；除 RTOS 堆在 CCM 外均在 SRAM1）	现值	配额	状态
网络	13,702 B	12 KB	⚠ 超 1.4 KB
存储	7,072 B	12 KB	OK
UI	34,188 B	16 KB	⚠ 超 17.4 KB
RTOS 堆	57,376 B	56 KB	堆=配额
应用	15,552 B	8 KB	⚠ 超 7.2 KB
其它	10,553 B	—	参考

门禁：pre-commit mem-budget 钩子（scripts/ram_baseline.py --gate）—— RW_IRAM1 / RW_CCM 任一 >92% 即拦提交，并打印 Top-10 RW+ZI 对象定位增量；无 .map 时自适应跳过（CI 盲区登记在 docs/任务规划/测试与架构专项.md「体积门禁 CI 强制路径」残余）。
阈值依据：92% 由 2026-09 体系评审提出、2026-10-12 落地为门禁（提出时的报告条目已随销项删除，闭环说明见 RAM使用分析与优化方案.md §4 阶段 3「长效机制」与本文）——留 ~8% 给突发缓冲与栈抬升，触线即触发排期，而不是静默逼近溢出。
软提醒（不拦提交）：tsv 末行落后于 .map（忘跑 --update）、.map 早于最新源码（忘 @build）。
子系统归集为参考值：按对象名前缀归集（口径见 §2），合计与区域总量可差几十字节（链接器填充行与 UNINIT_CCM 等小区分段所致）；区域行才是门禁事实源。

2. 子系统配额口径

配额值（ram_baseline.py 的 QUOTAS，本文件即唯一权威； RTOS 堆 2026-10-12 B5 扩容 48→56 KB 见 §6）：网络 12 KB / 存储 12 KB / UI 16 KB / RTOS 堆 56 KB / 应用 8 KB。归集口径（按 .map 对象名，首匹配）：

子系统	计入对象（前缀/精确名）	不计入
网络	`ch395f` `net_` `lftpd` `ftp_task`	`ui_net_sink`（算 UI）
存储	`gd5f` `nand_` `ff` `diskio` `vol_lock*` + dhara 裸名（`map/journal/nand/fctl/era.o`）	`cfg_*`（算应用）
UI	`lv_` `ui_`（含 `ui_net_sink`、`ui_task`）	—
RTOS 堆	`heap_4.o`（CCM）——配额 = `configTOTAL_HEAP_SIZE` 本身	内核对象（`tasks/queue/timers/...` 归"其它"）
应用	`App/` 其余：采集 `adc_`、保护 `prot_`、相量 `phasor/sample_ring`、配置 `cfg_`、日志 `sys_/dbg_/console_log`、对时 `time_sync`、`sys_clock`、`task_watchdog`、`sha256`、`tpafe*`、`sd2506`、`default_task` 等	—
其它	内核对象、HAL、CMSIS、启动文件、C 库、链接器填充	—

现状判读（2026-10-12 建档）：

UI ⚠ 超配额 = 已知长期挂账，不是新增违规：LVGL 池 16 KB（2026-10-15 落地，由 40 KB 收缩）+ 帧/远显缓冲 ≈12.8 KB，实测 30,412 B。配额 16 KB 描述的是 把 UI 侧缓冲迁进 CCM 之后的目标态，而 该搬迁的后半已按用户裁定 2026-10-15 整簇暂缓（docs/任务规划/登记簿.md §5 保留重启条件）→ 这条 ⚠ 会长期挂着，判读时按已知挂账处理，别每轮当新问题追；重开条件 → RAM使用分析与优化方案.md §4。
RTOS 堆 = 配额本身：56 KB 即 configTOTAL_HEAP_SIZE（2026-10-12 B5 由 48 KB 扩容，见 §6； heap_4.o 另含 32 B 元数据，不计超）；改堆 = 改配额，必须先过本文件 §6 登记。
应用 ⚠ 小幅超：8 KB 为报告规划值；2026-10-10 栈整改把 3 处 FIL 从栈搬进 BSS （静态 +4,128 B，见 docs/内存管理/RAM使用分析与优化方案.md §4"2026-10-10 复测"）—— 属已评审的"以空间换栈安全"，差额在此如实体现。

3. CCM 分配台账（谁能用 CCM）

项	值	说明
CCM 容量	`RW_CCM` Max 见受管区	scatter `RW_CCM`；仅 CPU 可达，DMA 不可达（RM0090 §3.1.1）
现占用	仅 FreeRTOS 堆 `heap_4`（56 KB，2026-09-21 迁入；2026-10-12 B5 扩容 48→56 KB）	其余候选全部仍在 SRAM1
现余量	受管区 RW_CCM 容量 − 占用 = 7,904 B	不够迁 CCM 后半的 UI 侧待迁体量（缩池后 29,570 B）——⏸ 该搬迁已暂缓，见下行
迁 CCM 后半解锁链	⏸ 整簇暂缓（用户裁定 2026-10-15），本行保留作重开时的现状基线：① 缩池 ✅ 2026-10-15：`LV_MEM_SIZE` 40→16 KB → 待迁体量 54,146 → 29,570 B（SRAM1 74.9% → 56.1%，实测池峰值 6,568 B）→ ② ~~现在卡在这一步~~：堆 56→32 KB（`docs/内存管理/RAM使用分析与优化方案.md` §4.2.2（阶段 2 第 2 项"缩堆"），再腾 24 KB；⚠ 2026-10-12 B5 反向扩容至 56 KB——9 任务栈 + 队列实测需要，缩回 32 KB 前必须重跑 `stack_report.py` + 上板 min_ever 复测）→ ③ CCM 余 ≈31.9 KB ≥ 29,570 B → 迁入	暂缓期间不启动；重开条件 → `RAM使用分析与优化方案.md` §4。若重开，顺序不可颠倒；每步前后跑 `stack_report.py` / `ram_report.py`（铁律）
迁入前置	目标缓冲必须过 DMA 可达性清单（`内存内容分配策略.md`）	违例 = 静默传错（越界不校验的同类坑）；克隆芯片 CCM 可靠性风险见 `docs/内存管理/RAM使用分析与优化方案.md` §7

4. 趋势基线（`scripts/ram_baseline.tsv`）

每次 @build 后：& '.venv\Scripts\python.exe' scripts/ram_baseline.py --update 追加一行（Code/RO/RW/ZI + 三区水位 + Top-10 RW+ZI 对象；同日重跑覆盖当日行）。
看趋势 / 找增量：scripts/ram_baseline.py --trend——高亮较上一行 RW+ZI 增长 >1 KB 的对象，即 docs/内存管理/RAM使用分析与优化方案.md §4.0.3 "ZI 增量 >1KB 必须在提交说明中解释"的机械化；提交说明直接抄 --trend 输出行。

5. 超配额流程

新增/扩大静态缓冲导致子系统越过配额：先登记再动手——本文件 §6 加一行（日期 / 子系统 / 现值→新值 / 原因 / 决定人），提交说明引用该行。 92% 门禁拦的是总量，配额管的是结构（谁挤占了谁），两者不可互替。

6. 变更记录

日期	变更	原因 / 出处
2026-10-12	建档：三件套落地（本台账 + `scripts/ram_baseline.py` + `scripts/ram_baseline.tsv` + pre-commit `mem-budget` 钩子）	登记簿 N-27 前半
2026-10-12	RTOS 堆配额 48 KB → 56 KB（`QUOTAS` 同步）	B5 protectTask 立项：iec104Task(2.5KB)+protectTask(2KB)+TCB 入堆后 48KB 池 min_ever 预估跌破 3,072 B 告警线 → `.ioc` L1 参数 `configTOTAL_HEAP_SIZE` 49152→57344（CCM 水位 75.3%→87.9%，仍 <92% 门禁；CCM 空闲降至 ≈8 KB）。连带影响见 §3 迁 CCM 后半链注记
2026-10-12	任务栈 +1536 B（堆内用量，配额 56 KB 不变）：defaultTask 1024→1280 words（+1024 B）、timeSyncTask 512→640 words（+512 B）；产品任务栈合计 37,632→39,168 B	登记簿 N-33 栈收口：B7 定值持久化把 defaultTask 静态链推到 3016 B（余 1080 < 30% 线）、timeSyncTask 链 1264 B（余 784 < ISR 底线 1024）；B6 台架背书 min_ever=10000 → 抬后实测 `heap free=16400 / min_ever=8464`（与预算 −1536 完全吻合，>3072 告警线）；`stack_report` 9 任务 0 FAIL + `@test` PASS，见 `RAM使用分析与优化方案.md` §1.4

8.5 KiB Raw Blame History Unescape Escape