zouyang/phonerail
1
0
派生 0
代码 工单 合并请求 工作流 软件包 项目 发布 百科 活动
52 提交 2 分支 0 Git 标签
ca7435242fb3feecec8375e0ba9cf3b3d4b8f826
提交图
52 次代码提交
此分支
此分支
所有分支
作者 SHA1 备注 提交日期
zhou yang和Claude Opus 5.5 ca7435242f rack：自动恢复的平线判据按实测重定（p95−p05 + 中位数下限） 
原判据「窗口内 max − min < 5 mA」抓不到真卡死：10-04 第 1 路平在 520 mA 五个半小时，
偶发尖峰让 590 个窗口的 max − min 都在 17 mA 以上，一个都判不出来。

- 平线改成：p95 − p05 < flat_ua（30 mA）且中位数 ≥ flat_min_ua（100 mA，新增参数）。
  下限是给空闲低功耗留的：睡着的手机平在 ~10 mA 是正常的。
- 过低不变（窗内最大值 < 30 mA）：睡着的手机每 25 s 被长轮询叫醒，窗内最大值都在 213 mA 以上。
- 真实遥测回放：两次真卡死（10-04 第 1 路、10-05 09:40 第 5 路平在 382 mA）都判出；
  亮屏常醒 ~26 h × 4 路、空闲睡着 ~6 h × 5 路、试验 / OTA 期间零误判。
- 测试 +4（带尖峰的平线 / 睡着是健康的 / 睡下去再没醒 = 过低 / 低位平线不下结论），恢复页加「中位数不低于」。

依据和局限写在 recovery.py 模块头。已部署；五路的自动恢复开关仍然全关，还没真正触发过一次。

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-10-06 05:14:22 +08:00
zhou yang和Claude Opus 5.5 d1fab040cc kicad：.history 是 KiCad 本地历史（内嵌 git 仓库），不进仓库 
Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-10-04 19:25:01 +08:00
zhou yang和Claude Opus 5.5 324fef1fae 文档：PROGRESS 与需求文档更新 
Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-10-04 19:24:45 +08:00
zhou yang和Claude Opus 5.5 cf7cc9cf90 R2：底板 / 刀片布局布线脚本、快照、截图与规划文档更新（含外壳、打印件、布线归档） 
Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-10-04 19:24:45 +08:00
zhou yang和Claude Opus 5.5 cd01640c40 skill：solidworks-assembly 实测笔记与脚本、easyeda-sch-geometry 补充 
Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-10-04 19:24:42 +08:00
zhou yang和Claude Opus 5.5 22a255acd7 BOM：R2 物料清单与淘宝 / 立创比价（表格 + 抓价脚本与数据） 
Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-10-04 19:24:42 +08:00
zhou yang和Claude Opus 5.5 bfe094a5d7 kicad：EasyEDA→KiCad 工程（Board1/Board2）、库、脚本与评审文档（IC 引脚、风扇、热、EDL 供电、布局规则） 
Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-10-04 19:24:42 +08:00
zhou yang和Claude Opus 5.5 1d842cf45f rack：单板页 Hub 行与拓扑图、单路操作拆成 RailOps；开机按键改 5 s 
Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-10-04 19:24:32 +08:00
zhou yang和Claude Opus 5.5 c41d1ec931 固件 0.1.14~0.1.16-c5：Hub 按需启停（hubctl）、开机长按统一 5 s 
Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-10-04 19:24:31 +08:00
zhou yang和Claude Opus 5.5 92f38c2328 gitignore：kicad/out、kicad/datasheets、根目录 result.json 不进仓库 
Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-10-04 19:24:31 +08:00
zhou yang和Claude Opus 5.5 86d9e2a7d4 rack：刷机模式界面与事件；事件 21 新增 254「断电自动退出」 
- 单板页「更多 → 刷机模式（1 小时）/ 加钟 30 分钟」，chg>0 时蓝色「刷机模式 · 充电中」、FLT 显示为「反向阻断」
- 协议白名单 flash_mode；事件 21 命名：开 / 手动关 / 到期 / 加钟 / 断电自动退出
- ⚠️ 254 带 0x80 位，必须先于「加钟」判断，否则显示成「加钟 126 分钟」

48 例全绿，已部署。

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
 2026-09-29 08:16:48 +08:00
zhou yang和Claude Opus 5.5 9fb5bba367 固件 0.1.5~0.1.13-c5：刷机模式、多组 WiFi、热插拔初始化、总线锁误判、硬重启断 VBUS 
- 0.1.5/0.1.6：刷机模式（flash_mode，最多 2 路，60 分钟可加钟）——窗口内顶高按 4450 mV 绝对值判、不断 VBUS
- 0.1.7/0.1.8：反灌断 VBUS 阈值放宽到 -300 mA（adb reboot bootloader 过渡实测 -208 mA）
- 0.1.9：WiFi 最多存 4 组，连不上轮换；NVS v1 自动迁移并双写（OTA 回滚仍能上网）
- 0.1.10：热插拔进来的刀片重新初始化 PCA9555 + INA226（否则 VBUS 常开、电流恒读 0）
- 0.1.11：i2cbus 嵌套检测改看本任务持锁（原全局标志让 key 随机回 busy、vbus 随机回 io）
- 0.1.12：硬重启先断 VBUS，开机校验通过 60 s 后再接回（否则假重启 / 误判没开机 / 进关机充电）
- 0.1.13：这一路被安全判据断电时一并退出刷机模式（事件 21 arg 254）

26 ctest 全绿；新增用例均先在旧代码上确认变红。板 B 已 OTA 到 0.1.13-c5 并实测。

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
 2026-09-29 08:16:21 +08:00
zhou yang和Claude Opus 5.5 385d2f9c47 固件 0.1.4-c5：整片刀片不应答（INA226 + PCA9555 同时 NAK 200 ms）⇒ 关这一路 
- t_safety：eFuse 开着、本路两颗都 NAK 连续 10 圈 ⇒ abort + 关 eFuse，新事件 20 BLADE_MUTE；
  只关 eFuse，不再写刚 NAK 过的 PCA9555。只有一颗不答应仍按 §10.10 盲跑、保持供电
- 起因：板 B 第 2 槽 PRSNT2# 卡低，刀片挪走后空槽 eFuse 开了约 4 h，原判据一条没响
- 需求 §10.10 加一行 + 表后第 3 条；rack 事件 20 命名并标红
- 宿主机 26 ctest 全绿（test_t_safety_rules +4 例）

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-28 09:07:39 +08:00
zhou yang和Claude Opus 5.5 ef91daf07d 固件 0.1.3-c5：硬重启开机校验 + 重按（0.1.2）、status 上报上游电脑在不在（host） 
- 0.1.2：power_cycle 按完电源键后看电流，没开就重按，最多 3 次；新事件 19 BOOT_CHECK
- 0.1.3：UP_VBUS_DET（IO6）启动时配成输入，status 加 "host":true|false|null
- rack：单板页显示「上游：已连电脑 / 未连电脑」
- HANDOFF：损耗两档的来历（Hub 工作 ≈1.1 W）、板 B 第 2 槽 PRSNT2# 卡低

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-28 08:59:12 +08:00
zhou yang和Claude Opus 5.5 830b4cdff8 rack：主板 / 底板功率与功率曲线；底板曲线加电压电流、开机重按事件 
- 每路主板功率（V×I）：总览槽位、单板卡片、单路曲线新增「功率」一张
- 底板：单板页新增功率仪表（底板输入 / 五路主板合计 / 损耗），底板曲线加
  功率图（输入 vs 主板合计）；board_history 每点多回一列 rails_mw
- 底板曲线改为纵向 N 张（温度 / 风扇 / 输入电压 / 输入电流 / 功率），断档断线
- LOG_EV_BOOT_CHECK（19）事件命名，只有「没开起来」标红

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-28 08:39:47 +08:00
zhou yang和Claude Opus 5.5 1f6862ac38 固件 0.1.1-c5：硬重启后自动开机、MQTT 发布死锁、欠压放宽到 −250 mV 
- 硬重启等到 PG 后长按电源键 5 s（新状态 hr-boot）：电池端上电的小米8
  停在关机态，原来的 power_cycle 等于关机。ACT_KEY_MS_ON 2000 → 5000
  （实测 2 s 松手即掉电）。NO_PG 时不按。
- 修死锁：执行器持 s_mtx 等 esp-mqtt 的 api_lock，esp-mqtt 任务持 api_lock
  分发 DISCONNECTED 时等 s_mtx。热点一断 USB/WiFi 全失联、按键可能松不开。
  执行器现在只往 s_outbox 拷贝，由 t_link 交给 esp-mqtt。
- SR-5 欠压一侧 −100 → −250 mV（T_SAFETY_UNDER_MV），过压仍 +100 mV：
  带屏开机峰值 2.1 A 时实测 −115 mV 被误关。需求 SR-5 / SW-2 / SW-5 / 验收表同步。

板 B 上板：power_cycle → hr-boot → 手机开机，最低 3778 mV / 2.12 A 不再跳闸。

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-28 01:13:58 +08:00
zhou yang和Claude Opus 5.5 afc5e81299 rack：字体打包进前端（Noto Sans SC 可变 + Barlow），各端统一 
图表 init 前先 document.fonts.load 字形：zrender 按字体缓存文字宽度且不清空，
字体未到就量会让时间轴标签叠成一团。

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 16:54:47 +08:00
zhou yang和Claude Opus 5.5 82d10ffefc PROGRESS / HANDOFF：补 rack 推固件页、固件目录清理、界面改版、底板温度曲线 
- PROGRESS 顶部新增 rack 这一轮的汇总；C2 条目里「重启不断电待讨论」「rack 没 OTA 按钮」划掉
- HANDOFF：新增「rack 侧」一节；--reboot 的说明改为「≥c3 且目标认接管不断电」；下一步补手机窄屏检查

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 15:10:38 +08:00
zhou yang和Claude Opus 5.5 9858b6c98e rack：界面改版（仪器前面板风格 + 暗色模式）+ 底板温度曲线 
- 总览：每块板一块面板、五个刀片槽（状态灯 + DIN 读数 + 最近两分钟电流小曲线，平线 = 疑似卡死）；
  只有异常 / 故障 / 执行中上色；顶上一句话概况，有问题直接列出是哪几路
- 单板页：新增「底板温度」（两路 NTC + 风扇占空比，上下两块共用时间轴，10 分钟 ~ 7 天）；
  每路电流 / 电压去掉双 Y 轴，改上下两块，电压固定 3.5~4.1 V；名称 / 位置就地编辑
- 主题：theme.css 亮 / 暗两套变量（跟随系统，Element Plus 暗色变量同挂 html.dark），图表切换时重画；
  读数用系统自带 DIN 系字体（不加载网络字体）；温度两色按本页亮暗底色跑过 dataviz validate_palette.js 全通过
- 后端：board_tele_min 分钟聚合（温度带 min/max，留 90 天）+ GET /api/boards/{id}/history（Db.board_history）
- 修一个偶发失败的测试（test_ota_events_are_named_by_arg：只推一次遥测，赶上 Hub 正在同步时会漏触发）；
  后端 42 例本机 + 服务器全绿，已部署；线上已取到板 B 温度 24.4 / 26.0 °C

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 15:03:24 +08:00
zhou yang和Claude Opus 5.5 1cd4fd4082 rack：固件下载目录自动清理（每小时，FwStore.prune） 
- 固件库里登记过的（界面上传）不自动删；没登记的（ota_push.py 直传、台架镜像）放满 7 天删；
  上传中断的 .tmp 1 小时删；非 <16 hex>.bin / .tmp 的文件名一律不碰
- 板子下载一次几秒就完、回滚用的是板上另一个槽，删旧文件不影响任何板子
- main.py：有 --fw-dir 时起清理循环，出错只记日志；test_firmware.py 加 2 例，共 41 例（本机 + 服务器）
- 已部署；本机模拟板实测放一个 8 天前的孤儿镜像，启动即被清掉

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 14:48:12 +08:00
zhou yang和Claude Opus 5.5 284571de20 固件 0.1.1-c3：I²C 不应答不再被报成「没初始化 / 忙」（关电回 busy 的根因） 
- 根因：IDF 5.4 的 i2c_master_transmit / receive / transmit_receive 在从机 NACK / SCL 超时时返回
  ESP_ERR_INVALID_STATE，HAL 照翻成 HAL_ERR_STATE（= 没 init）；命令层 from_hal 又把 STATE 当成
  「执行器忙」⇒ PCA9555 不应答时 power off 回 busy（eFuse 其实已关、意图已清），I2C_LOST 错误码是 5
- hal_i2c_esp.c：传输函数用 map_xfer_err（INVALID_STATE → NAK）；总线没建起来仍单独报 STATE
- cmd_exec.c：新增 from_bus，set_voltage / vbus / power 的器件失败一律 io；from_hal 只留给执行器
- sim：sim_i2c_inject_err_ch() 可指定注入的错误码；test_cmd 加 STATE 注入 ⇒ 必须 io 不是 busy
  （改回 from_hal 时这段确实红）。26 个 ctest 全绿
- 板 B（台架镜像，CH1 强制在位，未提交）：power off 回 io、CH1 关掉；I2C_LOST 错误码 5 → 2。现跑 0.1.1-c3

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 14:45:38 +08:00
zhou yang和Claude Opus 5.5 7bf30e3c38 固件 0.1.0-c3：计划内重启不断电（OTA / 回滚锁住 EFUSE_EN，新固件接管；SR-6 改写） 
- warm_esp.{h,c}：warm_restart() 记下开着的路（RTC_NOINIT，魔数 + 掩码 + 反码）→ gpio_hold 锁五根 EN → 重启；
  目标镜像没有能力标记（第 288 字节 PRCAPS1，.rodata_custom_desc）就不锁 —— 老固件写不动锁住的 EN。
  warm_take()：软件复位 + 标记对得上才接管，一次性；再读 EN 真电平核对
- bringup：adopt 掩码；rail_en_init_keep() 接管的路写高、五根一律放开 hold（崩溃时旧锁可能还在）；
  刀片不在 / mux 失联的接管路立刻关（SLOT_EMPTY arg 1）；第二段已开着的路不重开、不等 PG
- pca9555_init_keep()：方向寄存器是本固件写的才留 VBUS（掉过电的片子锁存器是 0xFF），键 / EDL 清零
- HAL：hal_gpio_hold()；ESP 输出脚配 INPUT_OUTPUT（读得到真电平）；sim 给 hold 建模
- 事件 LOG_EV_OTA arg 7 = 接管；兜底定时器回滚故意不走接管
- 顶层 CMake：phonerail.h 进 CMAKE_CONFIGURE_DEPENDS（否则镜像头版本停在旧值）；-u g_phonerail_caps 防 gc
- test_bringup 加 6 例（接管 / 非计划复位全关 / 空槽 / mux 失联 / PCA 掉过电 / hold 冻结），全工程 448 例全绿
- rack：固件库识别能力标记，推送对话框按「支持 / 不支持重启不断电」给不同提示（已部署）
- 需求文档：SR-6 改为「非计划复位全关」+ 计划内重启例外；§10.9 新增「重启不断电」
- 板 B：台架镜像（空槽强制 CH1 在位，未提交）开 CH1 → OTA 带重启 → 事件 18/7 mv=1，CH1 一直开着；
  现跑 0.1.0-c3。未测：示波器看重启期间 EN / 输出毛刺（要插刀片）

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 14:35:52 +08:00
zhou yang和Claude Opus 5.5 271c649f66 rack：「固件」页 —— 上传 .bin、选板推送 OTA、实时看进度 / 待验证 / 回滚 
- firmware.py：固件库。上传时核 ESP 镜像头（0xE9 + app 描述 + project_name == phonerail + ≤3 MB），
  存成 /root/phonerail/fw/<sha 前 16 位>.bin（nginx 7765 放出去），库里记版本 / 编译时间 / 上传人
- api：GET/POST/DELETE /api/firmware（请求体即 .bin，不引 multipart）、POST /api/boards/{id}/ota（进审计）；
  通用 /cmd 不放行 ota —— URL 与哈希只能由固件库生成；OTA 事件按 arg 显示中文、失败 / 回滚标红
- 前端：Firmware.vue + OtaState.vue；推送对话框默认不重启，勾「立刻重启」时列出每块板会断电的路并二次确认；
  单板页显示 OTA 状态
- simboard 模拟 ota（下载进度 / 就绪 / 重启 / 自证）；test_firmware.py 13 例，后端共 39 例（本机 + 服务器 3.8）
- service 加 --fw-dir；已部署。板 B 实测：上传 → 推送 → 就绪 → 同镜像带重启 → 不重下直接重启 → 自证健康

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 14:14:06 +08:00
zhou yang和Claude Opus 5.5 ae1aad3b7c 固件 C2：OTA 双槽 + 失败回滚（已上板实测正常 / 哈希错 / 回滚三条路径） 
- 分区重排（16 MB，nvs 0x9000 不动）：ota_0 / ota_1 各 3 MB、otadata 0x610000、evlog 挪到 0x612000；
  flash 大小改正为 16 MB；开 CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE
- ota.{h,c}（宿主机可测）：URL / sha256 校验、判定（下载中 busy、待验证拒、同镜像不重下）、健康判据
- ota_esp.{h,c}：t_ota 任务经 HTTP 下载、边下边算 sha256、核 project_name 后切启动分区；
  新固件 120 s 内连不上 broker 就回滚（t_link 判 + esp_timer 兜底）；重启前等回应发出、事件落盘
- 新命令 ota = 13（两条链路都收，reboot 默认 false：复位 = 五台手机断电一次）；status 加 ota 一块；
  新事件 LOG_EV_OTA = 18；PROJECT_VER 取 PHONERAIL_FW_VERSION
- test_ota.c 13 例，全工程 442 例全绿；版本 0.1.0-c2
- 服务器：nginx 7765 只放行 /fw/<16 hex>.bin（不过门户，路由器转发已加）；tools/ota_push.py 推送；
  rack protocol.py 加事件 18 / 命令 13（已部署）
- 板 B：推送到自证健康 19 s；错哈希不切分区；删掉 broker 账号后 120 s 回滚，bad 报出被回滚的版本

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 14:03:13 +08:00
zhou yang和Claude Opus 5.5 c37c08aa43 固件 A16：风扇闭环接进任务体 + NTC / TACH 真实采样（已上板） 
- ntc.{h,c}（宿主机可测）：分压端 mV → Ω → NCP18XH103F03RB 的 R-T 表插值；
  开路 / 短路 / 表外一律「读不到」（t_thermal 因此满速）
- thermal_esp.{h,c}（仅 IDF）：ADC1 oneshot + 曲线校准读两路 NTC；两个 PCNT 单元数 TACH 边沿
- app_main：task_thermal 任务体、t_thermal_init 放在上电恢复之前、status 带热管理快照
- test_ntc.c 4 例；全工程 429 例全绿；版本 0.1.0-a16
- 板 B：两路 NTC 38.2 / 34.0 °C；风扇两路 rpm 0 报停转（拉满电流不涨，疑未插风扇，待确认）

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 13:31:32 +08:00
zhou yang和Claude Opus 5.5 c85eec53e6 固件 A15：启动顺序 + 降级矩阵（bringup.{h,c}，已上板） 
- 启动序列从 app_main.c 拆进 main/bringup.{h,c}，宿主机可测：
  bringup_devices()（§10.9 第 1~4 步）→ 起 t_safety → bringup_power_restore()（第 5~6 步）
- 六片 INA226 写 Config/Calibration（之前没做，电流恒 0）；输入侧 0x43 登记对调接
- 按「意图」逐路上电、错开 100 ms、每路等 PG 500 ms，等不到关回去并记 LOG_EV_PG_TIMEOUT(17)
- 意图只由 power 命令改（cmd_env_t.intent → NVS phonerail/rail_want）
- §10.10 逐行降级：INA/DAC/PCA9555/mux/PRSNT#/CH224A；mux 失联时不碰主干
- BOOT 事件 arg = 复位原因；HUB_RST# 仍只在上电复位时脉冲
- rail_volt_init() 一片失败不再放弃另一片；CH224A 主干 / 通道 5 两处都找
- sim：sim_gpio_rise_us / sim_gpio_set_hook，sim_gpio_drive 可在配置前调
- test_bringup.c 24 例 + test_cmd 意图 1 例，共 425 例全绿；版本 0.1.0-a15
- rack：事件表加 17 PG_TIMEOUT（已部署）

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 13:24:17 +08:00
zhou yang和Claude Opus 5.5 da6af4ef1c 需求文档：§10.12 的「MQTT broker 与 topic」一行挪回原位 
上一个提交只暂存了本会话在需求文档里的几块改动（文档里另有会话前的未提交改动，没带进来），
用的是不带上下文的补丁，这一行被插到了 §11.2 表头与分隔线之间、把那张表弄坏了。

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 12:34:04 +08:00
zhou yang和Claude Opus 5.5 26c04ce878 机架管理前后端（rack/）：FastAPI + SQLite + Vue3，经统一门户上线 
- 后端 prrack：MQTT（phonerail-backend @ 127.0.0.1:1884）↔ 遥测入库 / 事件增量同步 / WebSocket 推送；
  命令白名单 + 重传同 seq；审计记门户 X-Auth-User（只绑 127.0.0.1，main.py 拒绝非回环）。
- 自动恢复：只看电流（平线 / 过低，服务器够不到手机 adb），先长按电源再断电重启，
  每小时限次后停手；默认逐台关闭。adb 探活接口 recovery.Prober 预留。
- 前端：总览 / 板子页（五路操作、电流电压曲线）/ 事件 / 操作记录 / 自动恢复；手机宽度可用。
- 部署 deploy/deploy.sh：服务器 Python 3.8 上先跑测试再替换；systemd phonerail-rack，每日备份。
- 门户应用 id 16、key rack（phonerail 已被需求文档站占用），授权 admin + staff。

测试 26 例（本机 3.14 / 服务器 3.8 均过）。线上板 b81f3fc9c8bc 在线，WS 经门户 101 + 1 条/s 遥测。

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 12:33:28 +08:00
zhou yang和Claude Opus 5.5 a32fa06c43 固件：A12 命令处理器 + A13 USB 分帧 + A14 WiFi/MQTT（含 C1 配网） 
- A12 单一命令处理器（cmd*.c）：一行 JSON 进出、seq 全局判重（32 条按值）、
  限幅 / 空槽一律拒 / 拒绝记事件；命令号与错误码冻结（进 flash）。新增 power 命令，
  fan 改为只抬不压的下限（t_thermal_set_floor）。rail_set_mv 注明不拿锁，调用方包 xact。
- A13 USB-Serial-JTAG 分帧（ulink*.c）：@C / @R 前缀 + CRC-16，日志行首 @ 垫空格，
  任意切块可切；关掉 USB 副控制台（它绕开驱动写 FIFO）。PC 端客户端 tools/prlink.py。
- A14 + C1（netcfg / mlink / cmd_net）：topic phonerail/<mac>/{cmd,rsp,tele,state}，
  mqtts（evse-ca 编进固件）、1 s 遥测、遗嘱离线；wifi / mqtt 配置只收 USB、存 NVS，
  net 永不回显密码。
- 协议定稿写进需求文档 §10.8（A12 / A13 / A14 三节）；N7 撤销改 D7（机架管理前后端）。

宿主机 23 个 ctest / 400 例全绿；板 B 已烧 0.1.0-a14，经 WiFi → 公网 → 8883 TLS 真连网验过。
固件 0xE2220 / 1 MB 分区只剩 12%，C2 前要重排分区表。

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 12:33:18 +08:00
zhou yang和Claude Opus 5.5 cae567dfd8 R2 焊接：丝印临时换成器件值 + 摆放优化 + 1:1 器件值打印稿 
2026-09-25 为焊接底板与旧版刀片（BLADE-PCB 3b9c4e39c8d164db）：

- silk_value.py：隐藏位号、在原位建自由丝印写器件值（Value，没有就用型号），
  --restore 按 _silk_value_restore.json 删字并恢复位号。⚠ 再出 Gerber / 下单前必须先 --restore。
- silk_value_plan.py：器件值摆放优化（不压焊盘 / 不重叠 / 不出框 / 避开开槽与金手指区；
  软代价：压过孔、压他件本体、离本件远、缩字号）。EDA 默认字体实测字宽 ≈0.78×字高。
- print_value.py：两块板背面镜像 1:1 画在同一张 A4，红框标 1 脚；
  print/print_1to1.ps1 按 210×297 mm 直送打印机（不经 PDF 阅读器缩放）。
- 数据：_silk_value_geom/_extra（板上读回几何）、_dump/_plan（排位结果）。

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 10:27:20 +08:00
zhou yang和Claude Opus 5.5 dc0395fde0 固件：首次上板修三处（Hub 复位 / 空槽不走总线 / 关 I²C 驱动日志）+ I²C 扫描工具 
2026-09-27 底板上板（未插刀片）发现：

- HUB_RST 只在上电复位（ESP_RST_POWERON）时脉冲。原先每次重启都脉冲，
  esptool 经 USB 复位芯片即把自己的 COM 口断掉，只能走 J33 手动下载。
  实测：USB 复位（原因 11）后日志「不动 HUB_RST#」，COM 口全程不掉。
- t_safety 空槽不走总线。原先五路无条件读，空槽 NAK 每次十几 ms，
  槽 1 就吃光 10 ms 整圈预算，槽 2~5 与主干输入侧 0x43 一圈都没读到。
  新用例 test_empty_slots_are_never_touched_and_the_input_still_reads（去掉修复即红）。
- 关掉 i2c.master 驱动日志：NAK 日志在持锁期间同步打印，拖垮 20 ms 节拍。
  失败仍计入 t_safety 的 i2c_err。
- 上板结果：空机 skipped=0 i2c_err=0 过载 0 最迟 0 ms。

tools/i2c_scan：独立的只读扫描固件（主干 + mux 8 通道，读身份寄存器，不写任何输出）。
实测主干 0x22/0x23/0x43/0x4A/0x4B/0x70 全在，另有 0x47 应答（推测 DAC63204 广播地址）。

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 10:26:55 +08:00
zhou yang和Claude Opus 5.5 b8ad69681f 固件：R2 迁移 R-0 ~ R-6（底板 + 5 片同构刀片） 
2026-09-16 完成、当时未提交，这里补提交（原样，不含 09-27 上板的修改）。

- 器件层 / 拓扑层整体从 R1 换到 R2：TCA9548A 分通道、五路同址 INA226 0x40 + 输入侧 0x43、
  刀片 PCA9555（VBUS_EN 挪到 P0.4）、CH224A 只读驱动、风扇闭环 t_thermal
- 新增 i2cbus（mux 原子事务）、slot（刀片 I/O 门面）、host/qtest.sh
- 74HC595 链退役（代码与测试保留）
- 判据阈值与时间常量未动；19 个 ctest 全绿，idf.py build 通过

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 10:26:24 +08:00
zhou yang和Claude Opus 5 5a80d8a872 写交接：SolidWorks 装配的接手点 + 本会话成果汇总 
用户已在 SolidWorks 里手工把两块板载入同一装配体，刀片尚未摆位。
在 PROGRESS 顶部加「新会话从这里开始」作为唯一入口：当前装配体状态、
下一步（刀片绕 X +90° 竖起 + 平移到槽位）、卡点（CreateTransform 封送）、
本会话七项成果与对应提交、四条待办。

装配体状态快照存 .claude/r2/3d/_sw_assembly_state.json：
- 活动文档 D:\DCDC\新建文件夹\3D_BASE-PCB_2026-09-12.SLDASM
- 底板包围盒 x 0.01~97.99，变换为单位阵 ⇒ 原点 = 板左下角（可直接套板坐标）
- 刀片无旋转、平放，引用 PhoneRail_blade.SLDASM（实体文件）

NOTES 两处更正：
- §14 二次更正：坐标系取决于插入方式 —— AddComponent4 插的会重心归零，
  用户 GUI 手工插的保留板左下角原点。动手前先 GetBox 看一眼，别假设。
- §19 新增：三个磁盘文件各是什么、底板零部件引用的是临时件（一清理就断链），
  并写明新会话第一件事不要 CloseAllDocuments。

新建文件夹/（126 MB STEP/SLDASM）加进 .gitignore。

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_0168Bu6SEx3cXXCJLkdnE6zB
 2026-09-12 14:48:48 +08:00
zhou yang和Claude Opus 5 ff50ccd4b0 新增 solidworks-assembly skill：EasyEDA STEP → SolidWorks 装配与干涉检查 
本机环境已实测：SOLIDWORKS 2025 SP01.1（RevisionNumber 33.1.1）、
Python 3.14.3 64 位 + pywin32，GetActiveObject 可挂已开实例。

已跑通的链路：
- EasyEDA get3DFile 导 STEP —— 桥有 30s 硬超时，必须异步启动+轮询；
  4MB 分块 base64 取回（刀片 31.2MB/25s，底板 53.9MB/44s）
- GetImportFileData + LoadFile4 导入（得到带位号的装配树，一块板 95 个文档）
- 遍历 GetDocuments 拿临时顶层 SLDASM → AddComponent4 插入（⛔ AddComponent5 恒返回 None）
- ToolsCheckInterference2(0, EMPTY, False, pc, pf) 5 参形式可调
- CloseAllDocuments(True) 清理（295 文档 0.9s）

⛔ 未完成：刀片摆位（CreateTransform 卡在 pywin32 封送）、
坐标系（插入后两板被重心归零，§14 的平移量不能直接用）。
⇒ 现状能装能查，但两板堆在原点，干涉结果无工程意义。

NOTES-probed.md 记了 18 节实测坑，包括：
- 无参成员是属性不是方法（含 GetMathUtility 这个例外）
- SaveAs3 返回 True 但写出的是废件（外部引用断链）
- LoadFile4 不会插进当前装配体
- 动态派发"找不到成员"时用 _oleobj_.GetIDsOfNames + Invoke 绕行

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_0168Bu6SEx3cXXCJLkdnE6zB
 2026-09-12 14:08:36 +08:00
zhou yang和Claude Opus 5 cdb63fd497 R2 刀片：台阶的连带影响 —— 金手指 J1 位号挪出被切区 
开台阶时只查了铜/过孔/焊盘/器件，漏了丝印。补查 82 条（自由丝印 + 可见位号）：
- J1 位号锚在 (26.45, 8.38)、框 x 25.74~27.16，左半截落在切掉的板材上（1.44 mm²）
  ⇒ 已挪到 (28.50, 8.378)，左下对齐与居中两种口径都在舌头 27~63 内；板上已下发并读回核对。
- 丝印层的线 0 段越界。
- 封装自带的 NOT PCIe - PhoneRail blade 读不回来（PCB 文档不列封装内部图元），
  按锚点 28.50 + alignMode 默认 3（左下）推算 x 28.50~44.62，截图实测左端 ≈28.7 mm 佐证，安全。

⇒ 以后改板框（尤其切掉板材）时，检查清单必须包含丝印与位号，不能只查铜层。

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_0168Bu6SEx3cXXCJLkdnE6zB
 2026-09-12 12:52:49 +08:00
zhou yang和Claude Opus 5 22d9f31e9b R2 底板：补 6 条自由丝印（插槽 NOT PCIe 警告 + J1/J23 接口标注） 
板上 pcb_PrimitiveString 原本 0 条 —— 方案 §5.2 要求的插槽警告、J1/J23 的接口标注
一直只写在原理图说明文字里，从没落到 PCB。

已补并读回核对 6/6：
- PWR 20V  L4 (12.500, 1.800)    J1 与 J23 同一颗 USB-C 座，插错要能看出来
- USB      L4 (84.250, 1.800)    J23 是 Hub 上行口
- NOT PCIe - PhoneRail blade only  L3 (49.000, 79.480)
- NOT PCIe ×3  L3 (36.000,18.520) / (62.000,38.840) / (45.000,59.160)
  完整句只放得下一条，其余槽间放短标 ⇒ 五个槽每个都邻着一条。

三条坑（已写进 R2 §39.5）：
- ⛔ 丝印压铜不算冲突（铜上有阻焊）。第一版把压铜也当冲突，六个候选位全军覆没，
  看着像「板上没地方放字」。真正要避的只有 焊盘 / 过孔 / 位号 / 安装孔 / 板框外。
- ⚠ alignMode 要显式传 5（CENTER），不传默认不是居中，字会整体偏出去；
  位号 Attribute 用的 3 是另一套口径。
- ⚠ 核对不能拿文案当字典 key：NOT PCIe 有三条，同名互相覆盖 ⇒
  「6 条都建上了」却报成「4/6 对上」。按 文案+坐标+层 配对。

新工具 silk_str.py：自带落点搜索（0.25 步长 + 偏移上限）、幂等下发、--verify 只读核对。

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_0168Bu6SEx3cXXCJLkdnE6zB
 2026-09-12 12:48:15 +08:00
zhou yang和Claude Opus 5 dc4f9b9d1c R2 刀片：金手指两侧开台阶（插不进插槽）+ 铺铜补齐并跟着台阶重画 
⛔ 根因：禁布区 ≠ 板材。ZONES['finger'] 早写着「槽体 ~9mm 要让开」，但那只是
   「别放件」，板框从来没开台阶 —— outline_pts() 第一段就是 (r,0)→(BW-r,0)，
   90 mm 宽的板材一直到 y=0。插槽塑料体只有 39 mm 且两端封闭 ⇒ 插不到底。

板框（用户拍板）：舌头 36.0 mm（x 27~63）/ 台阶高 12.0 / 内凹角 R1.0，切掉 648 mm²（10.6%）。
放行核算：被切区里铜 0 / 孔 0 / 焊盘 0 / 器件 0（板上读回与缓存两种口径一致）；
7 个定位孔最南 y=14.46 全在板材上；铣穿槽 y 56.86 不受影响。
代价：主板投影底边在舌头两侧悬空 1.0 mm，靠 7 个 M1.6 尼龙立柱压住，无害。

铺铜：抓板发现板上只有 11 块（L1/L4 的 GND 底填整层缺失，而记录写的是 25/25）。
补齐后按台阶重画成 31 块（L2 11 + L1 9 + L4 9 + L3 两岛），填充 31/31，DRC 间距 0 条。
+12V 岛改成阶梯形单环：舌头段仍下探 y=9.0 接 12V 三指 launch 孔，东段抬到 12.5，
断面 11.0 → 7.5 mm（1 oz 内层约 5.1 A，需求 1.5 A 峰值）。

两条判据上的坑：
- 阶梯形多边形不能按包围盒判越界（+12V 岛会误报）⇒ 改成逐边 0.25 mm 采样。
- pcb_pour.inner_poly()/outer_poly() 是死函数，plan() 只用 gnd_tiles()。

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_0168Bu6SEx3cXXCJLkdnE6zB
 2026-09-12 12:36:36 +08:00
zhou yang和Claude Opus 5 312089326e R2 底板：按用户布局重布风扇窗口 + L1 走廊重开 + 位号丝印重排 
布线（窗口整体重布，已下发）：
- 拆窗口内 43 段（用户手布的那批，用户选「拆掉重来」），补 139 段 / 7 孔，
  GND 回流孔 10 个；fan_check 对板上真实快照逐项净距达标（含「新孔 vs 内层线」）。
- ⛔ 根因：pcb_base.PD_L1 里的 L1 走廊是按**旧摆位**开的（注释坐标全是旧的），
  用户重摆后与件对不上 ⇒ 四条长途网必然布不通。重开六条走廊后未完成 4 → 2。
  走廊必须盖住焊盘正上方，只盖沿途不行。断面：几何 11.80 / 铺铜后实测 9.82（要 8.0）。
- 与拆线前逐网对比：没引入任何新的连通性问题（GND 未接 58→48、+3V3 2→0、
  两路 TACH 2/1→0、+12V 一字不差）。

定版：板上铜以**用户自己布好的那版**为准，不再改动。

丝印（silk_base.py，已下发并读回核对 150/150）：
- 压焊盘 128→4、压过孔 48→8、越框 8→3、互相重叠 34 对→0；字号不变。
- 三条坑：rotation 是度且不归一化（900=180°）；别拿「本体≥5mm」当保留白名单
  （会豁免掉 R9A/D3/U13 这些该重排的件）；「离本体」必须设硬上限 + 降级策略。

新工具：silk_base.py（丝印重排）、l1_section.py（L1 12V 主块逐 y 断面核算）、
fan_rip.py（按窗口拆线，拆前后比对全板线/孔总数防连带删除）。

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_0168Bu6SEx3cXXCJLkdnE6zB
 2026-09-12 12:02:32 +08:00
zhou yang和Claude Opus 5 51b570a59f R2 底板：删 J1 通孔地脚里的 12 个过孔、天线缺口东移 0.3，写交接 
- 板上与布线缓存同步删掉 J1.2 / J1.3 里误打的 12 个 GND 过孔（TH_KEYS 改名 bug 已在上一提交修）
- 天线缺口西沿 90.5 → 90.8：U20 地脚 1/40 到缺口边 0.155 → 0.454 mm，板框已重画并校验
- PROGRESS 顶部加「下次从这里开始」：填铜、DRC 挖槽区域、37 个网手工补线的顺序

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_0168Bu6SEx3cXXCJLkdnE6zB
 2026-09-10 21:04:07 +08:00
zhou yang和Claude Opus 5 efcba30a0c R2 底板改 4 层（D15）：规则 / 几何 / 背面摆位 / 4 层布线与铺铜，已下发 
- 规则：铜层 2→4，差分 0.28/0.18，间距 0.15，过孔 0.3/0.2（rules_base）
- 几何：98×98 板框 + 4×M3，槽阵居中，L1 12V 大铜 + 指头（pcb_base）
- 摆位：五插槽留 L1，其余 133 件翻到 L4；背面镜像规则实测；Hub 放走廊 2、
  东移 2.5 mm；扇出圈 / 小件间距 1.5（去耦例外）/ 9 A 过孔阵禁区（place_base）
- 叠层按用户决定改为 L1 槽面 / L2 整层 +3V3 / L3 整层 GND / L4 器件面
- 布线：D± 七对按构造布通（USB3 掉头、USB1/2 北去掉头、USB4/5 东绕、
  J23 桥），+3V3 / GND / +12V 平面网每脚一孔，0.125 网格 + PathFinder
  开关（route_base、remote_route.ps1）；剩 37 个网待手工补
- 铺铜：4 层重写，入口链自南向北切段 + 断面校核（pour_base）；
  已下发布线 / 缝合孔 / 铜面轮廓，填铜未成功（待查）
- 工具：plot_base / plot_routes / shot_base，board_check 通孔两层都算

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_0168Bu6SEx3cXXCJLkdnE6zB
 2026-09-10 21:02:10 +08:00
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 273c53347e A10：安全巡检的判据（SR-5 / SW-8） 
判据全在 t_safety_step() 里、**放锁之后**、直接写引脚（§10.3 原话：不经任何
队列或抽象层）：

  SR-5   |实测 − 该路设定值| > 100 mV **连着两圈** → 先断 VBUS 再关 eFuse
  SW-8   I < −50 mA，或 VBUS 期间电压被顶高 > +100 mV → **一圈就断 VBUS**

七条实现约定（详见需求文档 §10.2）：

· 「持续 20 ms」数的是圈，不是墙钟毫秒；
· 反灌不设确认窗口，与过压那 20 ms 的不对称是有意的 —— 误断 VBUS 只丢一次
  USB 数据，漏判会把能量泵回 12V 母线连累另外四台（设计文档 §15.2）；
· 判据只在「该路该有电 + 这一圈的值新鲜 + 过了 60 ms 缓启动窗口」时武装
  （对应 §10.10 的「盲跑 → 保持供电，禁用该路判据」）；
· 比的是该路 DAC 设定值的影子，不是 3900 这个常数（SW-4 要单路微调）；
· SR-5 关路关干净（不留「只靠 USB 供着电」的窗口），SW-8 只断 VBUS 不碰 eFuse；
· 断电之前先 t_actuator_abort()，断 VBUS 时只打断 EDL（只有它写 VBUS_EN）；
· 动作在前、记录在后，事件走回调出去，A11 在那儿接环形缓冲。

判据一条 I²C 事务都不发（设定值、两根 EN、正在跑的序列全部走影子），
§10.3 那 7.8 % 的预算不变。顺带新增两处影子：rail_efuse_is_on()/rail_vbus_is_on()
与 rail_setpoint_mv()，都**只在写成功时更新**，两个方向都倒向安全的那一侧。

29 个用例；25 条注错逐个跑过，24 条变红。第一版把「持续 20 ms」按墙钟算，
测试一半红一半绿 —— 巡检的采样时刻带亚毫秒残差（一圈占 1.56 ms 总线，
而睡到下一拍按整毫秒算），相邻两次判据的时刻是 21/19 ms 交替，19 ms 那一半
要拖到第三圈 = 40 ms，超验收且间歇性。改成数圈之后一次不飘，
并留了一条跑 20 轮、两种相位都踩得到的回归拦网。

Co-Authored-By: Claude Opus 5 <[email protected]>
 2026-09-07 08:41:53 +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 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 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 1b5bd159ec HANDOFF：git 仓库已建，更新那条遗留项 
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QYuExfgyYa6DzRRcUso8M8
 2026-09-06 18:18:23 +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