wandering1/STM32F4-Base
1
0
Fork 0
Code Issues 29 Pull Requests 1 Actions Packages Projects 2 Releases Wiki Activity

docs(部署): 删任务栈副本表改指针；纠 CCM/FPU 事实并刷新配图基线

Browse Source 
范围：AGENTS.md 一处指针、部署环境要求 §2.2/§3.1/§3.3、RAM 方案 6 处现状
数字、内存配图生成器 + 3 张 SVG、两份报告脚本的行尾与路径修正、新增两份
.map/.htm 数据快照。未改任何 .c/.h（仍跑 @build 复核：0 错误 0 警告）。

部署环境要求.md
- §3.3 删"任务栈预算"副本表、改为指针：该表已缺 adcTask/iec104Task/
  protectTask，defaultTask/timeSyncTask 两值停在旧数，注释却写"由
  gen_task_table.py 同源"——该钩子的校验面只有 README.md / AGENTS.md
  两处受管块，抄出来的副本没有门禁、改栈后必漂。指针指向 Src/freertos.c
  + 两份受管表 + RAM 方案 §2.3/§0.6，并留一条"别再抄"的成因说明。
- §2.2 链接布局补 `RW_CCM 0x10000000`（scatter 给 0x0000FF00 = 65,280 B，
  2026-10-11 起承载 FreeRTOS 堆；另有 256 B UNINIT_CCM 尾区），写明 CCM
  不可 DMA。原文"SRAM3/CCM 故意未映射"与 STM32F407-Demo.sct 直接矛盾。
- §3.1 MCU 行更正为**单精度 FPU（VFPv4-SP，无硬件双精度）、无 TrustZone**
  （原写"双精度 FPU / TrustZone"是芯片事实错误，也正是报告 F-6 双精度软
  浮点被长期误判的土壤）；SRAM 行改为"两块都在用，仅 SRAM3 未映射"。
- §3.3 资源预算表补 CCM 行，并把"主 SRAM 125,104 B / 95.4% / 极度紧张"
  更正为 75,264 B / 57.4%（余 55,808 B）；红线改标在 CCM（余 7,904 B）。
- 变更记录补 2026-10-22 行（含上一提交里的资源表刷新那一笔）。

AGENTS.md：任务表注里 "RAM使用分析与优化方案.md §1.4" 是**指错小节**——§1.4 确实
存在（该文档 §4「方案」下的阶段 1 子项，讲 lftpd 大局部缓冲静态化），但栈余量
台账在 §2.3（任务栈配置与实测峰值）与 §0.6（静态最坏链与判定），故改指这两处
再加 内存内容分配策略.md §6。根因是该文档里 §1（背景）与 §4 下的 1.1~1.5 同号
撞面，人和 doc-links（自引用放过）都会看错——本会话我上一轮就被它带错过一次。

配图与数据（draw-diagram 流程：改生成器顶部数据 → 重跑 → 逐文本核越界）
- 新增 data/ram_report_20261022.md、data/stack_report_20261022.md；后者
  运行时水位取自 2026-10-22 真机 [STACK] 心跳（8 任务高水位 + heap
  free=15,800 / min_ever=8,464），静态侧来自同日 .htm（全局最深链 3,024 B）。
- gen_memory_svg.py：三组图数据从 2026-09-21 / 10-10 快照换成 2026-10-22
  实测；任务栈 6 → 9 行，堆总量 48KB → 56KB，判定 6/6 → 9/9 PASS，新增
  AboveNormal 配色；Flash 子条改为"窄段不压字 + 下方四列图例"；任务栈
  画布 440 → 620 高。CCM 段总量按 scatter 用 65,280 B（与台账同口径）。
- 三张 SVG 重生成；用"CJK≈1.0em / 其余≈0.58em + 锚点"逐文本估算边界，
  修掉 5 处文字越界/压字（生成器内置 ElementTree 自检亦通过）。
- ram_report.py / stack_report.py 两处工具性修正：write_text 未指定 newline
  参数 → Windows 下把 data/ 快照写成 CRLF（与 .gitattributes 及既有快照
  不符）；stack_report 的 relative_to 在传相对 -i 时抛 ValueError，且会把
  本机绝对路径写进入库快照 → 统一走 resolve+relative_to 的相对路径回退。

RAM 方案：6 处"当前状态"随 .map/[STACK] 更正——RW_IRAM1 89,168 → 75,264、
RW_CCM 49,184 → 57,376、FreeRTOS 堆 48KB → 56KB（两处）、CCM 余量 ~16KB →
7,904 B、min_ever 4,848 → 8,464 B、6 任务全过 → 9/9 PASS；S-1 历史句保留。

门禁：pre-commit 对全部改动文件 Passed（doc-links --sections-strict、
task-table、mem-numbers、mem-budget、id-check 增量拦截）；字节卫生自查
BOM / CR / U+FFFD / 行尾空格全清。已提交本地，未推送。
This commit is contained in:
Wanderingss
2026-10-22 12:09:54 +08:00
parent d4867ddbe2
commit f4b9bd57d5
11 changed files with 606 additions and 191 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/内存管理/RAM使用分析与优化方案.md
+6 -6
View File
@@ -18,7 +18,7 @@
- F407 另有 **64KB CCM RAM**：**已于 2026-09-21 启用**并把 FreeRTOS 堆迁入（§1.2）
- 起步时没有任何运行时测量手段：不知道每个任务实际用了多少栈，改栈全靠拍脑袋
当前状态（**以 §2.1 受管快照为准**，由 `.map` 自动生成）：RW_IRAM1 **89,168 / 131,072 B（68.0%）**、RW_CCM **49,184 / 65,280 B（75.3%）**。✅ **任务栈：2026-10-10 削链后 `defaultTask` 实测峰值 2152B/4096（余 47%）、静态最坏链 2776B（余 32%）**，6 任务全过 `stack_report.py` 判据（曾于 2026-10-04 升至 3664B/4096 ≈ 10%，登记为 S-1，现已销项），详见 §2.3 与"2026-10-10 复测"小节。
当前状态（**以 §2.1 受管快照为准**，由 `.map` 自动生成；2026-10-22 `@build`）：RW_IRAM1 **75,264 / 131,072 B（57.4%）**、RW_CCM **57,376 / 65,280 B（87.9%）**。✅ **任务栈：`stack_report.py` 9/9 PASS**（2026-10-22 静态最坏链 + 同日真机 `[STACK]` 水位，`defaultTask` 最坏 3024B/5120（余 40%）、`protectTask` 872B/2048（余 57%），见 `data/stack_report_20261022.md`）；**卡点已从 SRAM1 移到 CCM**（余 7,904 B）。历史：`defaultTask` 曾于 2026-10-04 达 3664B/4096 ≈10%，登记为 S-1，2026-10-10 削链后销项（详见"2026-10-10 复测"小节）。
本方案三个目标：
@@ -121,7 +121,7 @@
| idle（内核） | `configMINIMAL_STACK_SIZE=128` | 0.5KB | 空闲 | 未观测（未取句柄） |
| timer（内核） | `configTIMER_TASK_STACK_DEPTH=256` | 1KB | 软定时器 | 未观测 |
> 任务栈全部从 FreeRTOS 堆（48KB，2026-09-21 已迁 CCM）分配。**"配置栈"列以 `Src/freertos.c` 为唯一来源；实测峰值/余量判定以 §0.6 的 `stack_report` 基线为准**（本表数值同步自该基线）。
> 任务栈全部从 FreeRTOS 堆（56KB = `configTOTAL_HEAP_SIZE` 57,344 B；2026-09-21 迁 CCM、2026-10-12 扩容）分配。**"配置栈"列以 `Src/freertos.c` 为唯一来源；实测峰值/余量判定以 §0.6 的 `stack_report` 基线为准**（本表数值同步自该基线）。
### 2.4 动态分配点与隐患
@@ -135,12 +135,12 @@
|---|---|---|
| ① LVGL 内存池 40KB 对 1bpp 小屏菜单过大 | 40KB → **16KB ✅ 2026-10-15** | 高（目标 8~16KB；**开机实测 UI 仅用 ~3KB**，见 §2.6.2） |
| ② 任务栈"往大了给"，无实测依据 | 38,912 B（38 KB 现值，§2.6.1） | 高（§0.6 已有实测：uiTask 3.8/16KB、netTask 0.6/4KB → 阶段 1.3 缩减） |
| ③ 64KB CCM 曾完全未利用，缓冲挤在主 SRAM | — | ✅ 2026-09-21 已启用（堆迁入 CCM），CCM 余量 ~16KB |
| ③ 64KB CCM 曾完全未利用，缓冲挤在主 SRAM | — | ✅ 2026-09-21 已启用（堆迁入 CCM）；2026-10-22 CCM 余量 7,904 B（**全局卡点**）|
量化补充（来源：2026-09-11 审计快照，口径与方法见 §8.4）：
- 两池（FreeRTOS 48KB + LVGL 40KB）曾占主 SRAM 的 **68%**，是当时"SRAM 几乎耗尽（95.4%，余 5.8KB）"的直接原因；**堆迁 CCM 后该结构性压力已解除**（现 RW_IRAM1 66.4%，见 §2.1）
- heap_4 **不合并相邻空闲块** → 长期运行需盯碎片，`min_ever`（现 4,848 B）是硬指标而非 `free`
- 两池（FreeRTOS 48KB + LVGL 40KB）曾占主 SRAM 的 **68%**，是当时"SRAM 几乎耗尽（95.4%，余 5.8KB）"的直接原因；**堆迁 CCM 后该结构性压力已解除**（2026-10-22 RW_IRAM1 57.4%，见 §2.1）
- heap_4 **不合并相邻空闲块** → 长期运行需盯碎片，`min_ever`（2026-10-22 实测 8,464 B，56KB 池）是硬指标而非 `free`
- 未映射资源：SRAM3 64KB（scatter 未映射；clone 芯片可能无此区）；CCM 已用
- 曾经的三条中风险项：新任务无处安置（已缓解）、堆碎片（仍存）、栈溢出检测缺失 → **已于阶段 0 开启 `configCHECK_FOR_STACK_OVERFLOW=2` 并实测抓到过溢出**（§0.1）
@@ -148,7 +148,7 @@
### 2.6 堆 / LVGL 池 / C 库 / Flash 明细
#### 2.6.1 FreeRTOS 堆（48 KB；2026-09-21 已迁 CCM `RW_CCM`）
#### 2.6.1 FreeRTOS 堆（56 KB；2026-09-21 已迁 CCM `RW_CCM`）
`configTOTAL_HEAP_SIZE = 49,152`（heap_4）。内部构成：