 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
|
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
|
eb3df9ff49
|
A6：PCA9555 驱动 + 「接地脚永远是输入」的硬约束
U23 @ 0x20，16 个脚全部是输入：5×EFUSE_FLT# + 5×EFUSE_PGOOD + BUCK_PG
+ INA_ALERT + 4 个焊死在地上的备用脚（P0_7 / P1_5~7）。位表与地址从
.claude/pcb1-parts.json 的真实焊盘网络逐脚核回来，与设计文档 §17.2 一致。
驱动根本不提供「把某个脚配成输出」的接口（和 sr595.h 不提供「抬 OE#」同一条
规矩），方向字一律过 pca9555_dir_safe()，不安全直接 abort。原因是 PCA9555 的
Output Port 寄存器复位值是 0xFF —— 把接地脚配成输出的那一刻它就输出高电平，
而真器件既不报错也不 NAK，只是发烫。
三种极性（FLT# 低有效 / PGOOD 高有效 / INA_ALERT 低有效）各自只在一个函数里
出现一次；上层问「有没有故障」，不许自己去 & 位。
sim 侧新增按 datasheet 建模的假 PCA9555：Output 复位 0xFF、输入按位合成、
接地脚被驱动时记短路、INT# 只被「读输入端口」清除。为此给假 I²C 总线加了一个
窃听钩子（POST_WRITE / PRE_READ）—— 通用寄存器表模拟不了「配成输出就对地
短路」这类事，以后再有这种器件照这个挂。
验收：8 条 ctest（81 用例）全绿；idf.py build 通过，pca9555.c.obj 在。
12 个「一定会被写出来的错」逐个注进去跑过，全部变红。
Co-Authored-By: Claude Opus 5 <[email protected]>
|
2026-09-07 06:28:11 +08:00 |
|
|
zhou yang和Claude Opus 5
|
ab37f9dc49
|
A5：74HC595 24 位链 + 影子寄存器单一写入点
15 路侧键 + 5 路 EDL_EN + HUB_RST 在一条 24 位链上，内存里只有一份影子，
唯一写入点是 sr595_flush()。发送顺序 U33 → U22 → U21，每字节 QH 先发。
位表是从 .claude/pcb1-parts.json 的真实焊盘网络逐脚核回来的，不是照文档抄 ——
设计文档 §17.2 那张是 09-04 的两片版，§26.18 重排后 15 路里有 12 路对不上。
顺手把 §17.2 与 §8.2 里过期的两张表都改了。
sim 侧新增按 datasheet 建模的假移位链（SRCLK 上升沿移一格、RCLK 上升沿锁存），
只看线上真实发生的边 —— 对着驱动自己的影子变量断言等于自己证明自己。
四个注错进去的 bug（字节序反、OE# 先使能、安全影子写 0、位表写成算式）全被拦住。
上电顺序按「先锁存安全值、再使能 OE#」写死：三片 MR# 接死在 +3V3，
上电时移位寄存器内容不确定，先拉低 OE# 就是把随机值放到 15 个栅极上。
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QYuExfgyYa6DzRRcUso8M8
|
2026-09-06 19:33:51 +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 |
|