 zhou yang和Claude Opus 5
|
18d3d69856
|
A11：事件日志（环形缓冲 + 落盘）
事件从 evlog_put*() 进一个 256 条的 RAM 环（临界区里两条指令，**不阻塞、
不碰 flash**），由最低优先级的 t_log 攒够 16 条或最老那条等满 1 s 时批量写进
新的 `evlog` 分区（17 扇区 × 4 KB = **4335 条**）。A10 的事件出口原样接上，
判据那一层一个字没动。
八条实现约定（详见需求文档 §10.7）：
· 落盘不用 NVS 也不用 SPIFFS，是一块裸 data 分区 —— NVS 的页式 GC 会把
「写一条事件」变成一次不可预测的搬移。HAL 因此多出第六样 hal_store；
· 17 个扇区不是 16：每扇区要拿一个 16 B 的槽当扇区头，4 KB 只装 255 条，
16 扇区 = 4080，差 16 条不到 §10.7 要求的 4096；
· 序号 = flash 里的位置（epoch × 255 + 槽号），不是自增计数器 —— 重启接着数
不用存计数器；代价是没落盘的事件还没有序号，A12 读之前要先 flush；
· 入队走关中断的临界区，**不是第三把锁**：入队方是最高优先级的 t_safety，
停在一把 t_log 持着的锁上等于让最低优先级的任务决定巡检节拍；
· 丢事件可以，悄悄丢不行 —— 缓冲满了盖最旧的，但补一条 LOG_EV_LOST 记着丢了几条；
· 每条记录带 CRC-8（见下），写失败就放弃该扇区剩余部分，被放弃的那段在序号
空间里是个洞，读回时给一条空记录占位（跳过的话上位机游标会卡住）；
· 每次上电记一条 LOG_EV_BOOT：时间戳上电从 0 计，没有它两次上电的记录会穿插。
事件类型的数字是 flash 格式的一部分，只许往末尾加；safety_ev_t → log_ev_t
是显式 switch 不是加偏移。§10.7 里还没人产生的六类号已占住（A12/A15/A16 去填）。
27 个用例；23 条注错逐个跑过，21 条变红。第一版校验和用异或，漏掉的正是最常见
的那条：payload 全 0 的记录被掉电切在第 8 个字节上时，后 8 个字节留在 0xFF，
而 8 个 0xFF 的异或恰好是 0 —— 半条的校验和与整条一模一样，扫描把半条当成
一条真事件。换成 CRC-8 之后拦住。另外两个只在这里才踩得到的坑：「掉电重启」
不能用 sim_hal_reset()（那是换新板子，flash 一起擦，测试永远绿），为此加了
sim_hal_reboot()；「读到洞就跳过」这个错被测试里 static 数组的零初始化掩盖过
一次，缓冲要先填成非零。
Co-Authored-By: Claude Opus 5 <[email protected]>
|
2026-09-07 09:20:02 +08:00 |
|
|
zhou yang和Claude Opus 5
|
b3206005ab
|
A9：三个执行器状态机 + 互斥
需求 §10.6 的三个序列，每路一份状态机，全部以「收尾」收口：
硬重启 EFUSE_EN↓ → 4 s（§7.4 的 3~5 s 窗口）→ EFUSE_EN↑ → 17 ms
（tON 5.1 + 缓启动斜坡 11.5）→ 等 PG
按键 按下 → 保持 T（100 ms / 2 s / 10 s）→ 松开，组合键一帧发完
EDL EDL_EN=1 → VBUS_EN=1 → 等枚举 → EDL_EN=0（SW-6 的顺序）
一个函数一步，不写 while(1)：t_actuator_step() 只看时钟、推状态、返回「下次
最晚多久再来」，任务体在 app_main.c 里还是三行。放电由硬件联锁做（SR-7），
本文件里没有任何放电接口。
四条关键判断：
· 按下去的东西一定要松开 —— 正常结束 / 超时 / 出错 / abort 走同一条收尾路径，
写不进 595 就一直重试，不设放弃上限（放弃 = 电源键永久按住，而遥测正常）；
· 等不到 PG 不许再断电（§10.10：PCA9555 不应答不关输出）；
· PG 由 t_safety 的快照喂进来，执行器不碰 I²C ⇒ 两把锁永远不会嵌套；
· 不可重入直接拒（HAL_ERR_STATE），被拒的请求一个字节都不发。
23 个用例；21 条注错逐个跑过全部变红。其中一条第一遍没抓住 ——「等 PG 时一觉
睡满 500 ms」：测试自己掌握节奏就测不到 step 返回的睡眠时长，补了一个完全听
step 的任务循环测试。
Co-Authored-By: Claude Opus 5 <[email protected]>
|
2026-09-07 08:08:28 +08:00 |
|
|
zhou yang和Claude Opus 5
|
ec31891429
|
A8：任务骨架与调度（5 个任务、两把锁）
需求 §10.3 落地。四件事：
1. 五任务表（tasks.c）：周期与优先级写在一张 const 表里，开机自检查的是
相对顺序（safety 唯一最高、log 唯一最低、thermal 与 actuator 同级），
外加「巡检周期必须长于 INA226 一帧转换 8.8 ms」。不过就 abort。
2. 节拍器（sched.c）：记下一次该醒的绝对时刻，回绕安全（int32_t 差判先后）。
过载时跳过错过的整周期、保住相位，不补跑。
3. 两把锁（hal_lock）：I²C 与 74HC595，禁止嵌套持有 —— 这块板上两者没有交集，
「拿着 A 去拿 B」永远是写错了。ESP 侧用 mutex 取优先级继承。
4. t_safety 的一个周期：拿锁 → 6 片 INA226 的 V+I + PCA9555 两端口 → 放锁。
不死等锁（5 ms 超时就跳过这圈），一片读失败不中断整圈、保留上一圈的值。
I²C 占用由 HAL 按线上真实字节数记账（两个目标同一份代码），静态预算与实测
必须相等：一次寄存器读 48 位，一圈 13 次事务 = 1560 µs / 20 ms = 7.8 %，
与 §10.3 手算的「约 1.5 ms / 约 8 %」相符（本节的 46 位没数 STOP 和重复 START）。
sim 侧配套两样：假 I²C 事务真的把虚拟时钟花掉（否则时序测试是空话），
以及可强制的加锁纪律检查（配一条反向测试，防止检查本身失灵）。
11 条 ctest（161 例）全绿，idf.py build 通过；16 个注错实验全部变红。
Co-Authored-By: Claude Opus 5 <[email protected]>
|
2026-09-07 07:35:39 +08:00 |
|
|
zhou yang和Claude Opus 5
|
45de84ed3c
|
A7：五路配置表 + 表驱动遍历 + 启动自检
六组编号（INA 地址 / DAC 片通道 / 三个按键位 / EDL 位 / 两根 EN 的 GPIO）拼成
一张 const 表 rail_cfg(1..5)，没有一列是顺排的。开机 rail_selftest() 把它和
A3~A6 四个驱动的表逐格对账，再查全板引脚重复 / 越界，不过就 abort ——
那四个自检谓词至此全部有了调用点。
判据拎成 rail_selftest_table(t) 单独可调：真表是 const 的，不这么做就没法证明
「真有事的时候查得出来」。测试复制一张表出来逐样改坏，六种坏法都验过。
顺带修一个真 bug：HAL 两侧 GPIO 边界写的是 pin < 48，而 EFUSE_EN2 就在 IO48
上 —— CH2 的 eFuse 既开不了也关不掉。sim 与 ESP 两份都改成 0~48 含。
9 条 ctest（131 个用例）全绿，idf.py build 通过，16 条注错 15 条变红
（唯一没红的那条与原因记在 HANDOFF.md）。
Co-Authored-By: Claude Opus 5 <[email protected]>
|
2026-09-07 07:13:04 +08:00 |
|
|
zhou yang和Claude Opus 5
|
9eb1b39da6
|
A4：DAC63204 驱动 + rail_set_mv()
调压是**反向**的（DAC 码越大输出越低），所以整块换算只在 rail_mv_to_code()
里出现一次那个减法，除 rail.c 外任何地方都不许碰 dac63204_write_code()。
范围 3524~4010 mV，越界即拒（SR-13，第四道限制），4010 = Vd 0。
通道映射按 §26.18 重排过，五路里四路对不上「前三路在 U6、通道号 = rail−1」：
CH1→U6.OUT2 / CH2→U6.OUT0 / CH3→U7.OUT0 / CH4→U6.OUT1 / CH5→U7.OUT1。
四通道电气对等 ⇒ 接错了板子照样正常工作，只是调错了路。设计文档 §17.2 那张
过期的通道表一并改掉了。
驱动只经 hal_i2c_*：认件（DEVICE-ID=01h，53204/43204 当 BUS 错拒掉）、
开内部基准 → 写增益 2× → 写安全码 → 才给用到的通道上电（COMMON-CONFIG 因此写两次：
复位码 0 就是输出上限 4.010 V），未用通道 FBx 悬空一律保持 Hi-Z。
三个「一定会被写出来的错」逐个改进去验过测试拦得住：反向关系写反 → test_rail 红；
忘了码左对齐、通道按 rail−1 算 → test_dac63204 红。
留给下次的两条：越界请求还没记事件（TODO(A11)）；两点标定还没做，
现在走理论公式，将来顶替的是 RAIL_VOUT0_UV / RAIL_DAC_SPAN_UV 两个常量。
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QYuExfgyYa6DzRRcUso8M8
|
2026-09-06 19:11:10 +08:00 |
|
|
zhou yang和Claude Opus 5
|
ceadf08345
|
A3：INA226 驱动 + 六片地址表
地址表按设计文档 §8.2 钉死（0x40/41/44/45/42 + 输入侧 0x43），只走
ina226_rail_addr()，并有一条测试专门拦「ina_addr = 0x40 + ch」这一手
（CH3/CH4/CH5 三路全错，需求 §10.4）。
驱动只经 hal_i2c_*：认件（MFG/DIE ID）、写 Config 0x4327 + CAL 2048 并
回读校验、读 V/I/分流/功率。电流有符号，反灌为负（SW-8 判据）。
巡检走 read_vi()，每片两次事务，对应 §10.3 的 8% I²C 占用。
两条留给下次的坑：寄存器指针不依赖自增（sim 会自增、真件不会，靠自增
在宿主机上测不出来）；CAL 丢了不报错只让 Current/Power 恒读 0，所以
有 ina226_check()。
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QYuExfgyYa6DzRRcUso8M8
|
2026-09-06 18:43:34 +08:00 |
|
|
zhou yang和Claude Opus 5
|
cac6ce47ce
|
A2：HAL 接口（i2c/gpio/pwm/time）+ sim 与 ESP 两套实现
接口在 components/phonerail_hal/include/，宿主机链 sim/、ESP32-S3 链 esp/
（IDF v5.4 新版 i2c_master / gpio / LEDC / esp_timer）。
sim 提供 A3 起要用的假板子控制面：假 I²C 器件（寄存器表 + 大端 + 指针自增）、
可注入 NAK / 器件失联、GPIO 外部驱动与写计数、虚拟时钟。
组件名不叫 hal —— ESP-IDF 自己有 components/hal（driver 依赖它），同名会盖掉。
验收：bash host/test.sh → 3 条 ctest 全过；build_idf.ps1 → 编过且零警告。
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QYuExfgyYa6DzRRcUso8M8
|
2026-09-06 18:33:26 +08:00 |
|
|
zhou yang和Claude Opus 5
|
2bfe308b30
|
初始导入：PhoneRail 五路手机直供电源板
原理图/PCB 已在 EasyEDA 里做到 12 页跨页 0 漏接，固件刚完成骨架包 A1。
这次是把已有的一切一次性纳入版本控制，没有改动任何设计内容。
纳入：
- 设计与需求文档、PROGRESS.md、小米8 参考原理图 PDF 与追脚脚本
- .claude/ 下的 EasyEDA 桥接工具链与几何/网表缓存（eda-parts.json、
pcb-parts.json、pcb-pads.json、p2-ch1.json 等，是重画各页的唯一事实来源）
- 117 张验证截图（本项目所有方向问题都是靠人眼看截图发现的，属于证据不是垃圾）
- firmware/ 的 A1 骨架与 site/ 文档站源码
.gitignore 排除：构建产物（firmware/build、host/build、sdkconfig）、
site/node_modules、__pycache__、桥接日志 _bridge.log、脚本自标的 *.stale。
.gitattributes 默认 `* -text`：现有 .py/.json 大多是 CRLF，原样存，
不让 git 重写行尾。唯一例外是 *.sh 强制 LF —— 带 \r 的 shell 脚本 bash 跑不了。
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QYuExfgyYa6DzRRcUso8M8
|
2026-09-06 18:18:14 +08:00 |
|