6 月 1 日，我的六色电子纸仪表盘已经做了一个半月，卡在两件事上：局刷窗口边上有一条甩不掉的线；想做一个"橙变白"的直接更新，不清屏，直接把一块橙色抹成白。我听说过 Modos Labs 的开源电子纸项目 Glider，就在 AI Studio 里问了 Gemini 3.1 Pro，想看看它对我有没有参考。读下来的结论是：Glider 用 FPGA 直接驱动没有控制器的裸面板，波形引擎是它自己的；我的面板自带 SPD1657A 控制器，波形引擎在芯片里。能借的是波形结构方面的知识，借不了的是寄存器玩法。至于 Gemini 那天针对我这颗芯片给的具体建议，很多是从别的芯片搬来的；当晚到第二天凌晨，板上的 Claude Code 对着手册和真机逐条核了一遍，推翻的比站住的多。
为什么去看 Glider
背景在上一篇《把 Claude Code 塞进一块彩色电子纸》里：Arduino UNO Q 驱动一块 7.3 寸 Spectra 6 面板（GDEP073E01，控制器 SPD1657A），给板上的 Claude Code 当仪表盘。5 月 18 日定下的配方书里，一次全刷要 30 秒左右，1.5 秒的快速局刷只能把窗口刷白，想换色就得等完整的一轮。局刷窗口那条线，5 月 31 日晚上刚发现它和窗口高度有关：同一张图，24 行高的窗口出线，100 行高的不出。
所以我问 Gemini 的第一句是请它讲讲 Glider，第二句就直奔主题：
"还是需要快速刷新，尤其局部刷新的。所以这个项目中有提到spectra6的一些hack方式了吗"（2026-06-01）
Glider 是什么样的
Gemini 的第一条回答带了 15 条 Google 搜索来源，来自 GitHub、Crowd Supply、Hackaday、modos.tech、frame.work、YouTube、reddit 等，可惜导出的记录里只有域名，没法逐条对到原文。它的描述是这样的：Glider 想把电子纸当真正的电脑显示器用，打字、写代码、看网页，目标是 60 Hz 甚至 75 Hz、延迟 100 ms 以内。为此它不用带控制器的小模组，直接驱动没有内置控制器的大尺寸裸面板，比如 13.3 寸的 ED133UT2，时序和驱动电压都由板子自己生成。核心是一块 FPGA（Spartan-6 LX16），上面跑开源的 Caster 控制器：记录每个像素的更新历史，只刷变化的像素，把视频流实时变成面板要的驱动信号；旁边一颗 STM32H750 管 USB、读温度、跑状态机；视频从 Mini-HDMI 进来、经 ADV7611 解码，也可以走 USB-C 的 DP Alt Mode；电脑端可以通过 USB HID 切换打字、浏览、看图几种刷新模式。
这里面哪些站得住，要分开说。当天晚上，板上的 Claude Code 把 Glider 仓库拉下来读过，确认了三件事：FPGA 直驱裸面板、Caster 控制器、仓库里有个 translate.py，用 -p e6 参数可以解 Spectra 6 的 .iwf 波形文件。它还从作者在 README 里的自述记下一条很要紧的：Spectra 6 的波形是单向的，只按目标色存，一个目标色一条，不存"源色到目标色"的矩阵，而且一条可以长达几千帧、几分钟。至于具体的芯片型号、60 到 75 Hz、100 ms、几种模式和 API 支持哪些语言，都只是 Gemini 的转述，我没有核对。"FPGA 加裸屏加自定义波形是业界公认的最优解"这类话，是 Gemini 自己的评价。
对我的项目有什么用
先说清楚借不了什么。Glider 的逐像素状态追踪、按模式切换波形，都发生在它自己的控制器里；我这边 STM32 只负责把 SPI 命令送出去，每一帧怎么驱动由 SPD1657A 决定。我手里能动的只有几个旋钮：PSR 里的 LUT_EN、PWRR 的中间轨电压、PLL、手册上没有的 0x21 一类写波形命令，以及刷新到点拉 RST 截断。板上的 Claude 那天给 Glider 的评语也是这个意思：它是 FPGA 驱裸屏的那一层，不经过 SPD1657A，寄存器玩法不通用，波形结构通用。Gemini 自己在第二条回答里也劝过，做 Spectra 6 仪表盘用不着 FPGA。
能借的是波形结构。同一段对话里，Gemini 建议我为"任意色直跳"在驱动里建一张 6×6 共 36 条路径的转移矩阵，为每一对颜色各写一段波形。按 Glider README 的说法，Spectra 6 的波形只按目标色存，这个框架一开始就不对。回头看也对得上：我 4 月读出来的这块屏的 OTP，真实内容只有 4 KB，一段 VCOM 加六段颜色波形，每段 400 字节，正是按目标色排的。
模式切换这件事，我只能按屏幕区域去近似。仪表盘本来就切成五个区，守护进程决定局刷还是全刷；6 月 2 日凌晨之后又多了一条几何规则，后面会讲到。
Gemini 那天说的，后来怎么样了
导出的记录里，Gemini 一共给了 12 条有效回答，另有 7 次内部错误。12 条里只有 3 条带了搜索来源：Glider 介绍、Spectra 6 的几种 hack 思路、局刷线那一条。有两条回答开头说"我刚刚在 GitHub 上为你深度深挖了"、"我刚刚为你深度扫描了全球极客社区"，记录里却没有任何来源。
当晚十点多，我让 PC 上的 Claude Code 把整段对话导出成 Markdown，十一点推到板子上。板上那个 Claude Code 读了我上传给 Gemini 的那份 SPD1657A 手册，把 GxEPD2、微雪的 6 色和 7 色驱动、Glider、Seeed 的驱动和 Good Display 的官方示例都拉下来看了，再在真机上做实验，最后写了两份追问清单，每条都标了〔事实〕或〔推断〕。对照下来是这样：
| Gemini 说的 | 怎么核的 | 结果 |
|---|---|---|
| 局刷用 0x44/0x45 框窗口、0x24 写数据、0x22 和 0x20 触发、0x3C 管边框、0x7F 当 NOP | 手册的命令表 | 这颗芯片没有这些命令，那是 SSD16xx 系列的；本芯片局刷窗口用 0x83，边框在 0x50 里 |
| 写自定义波形的寄存器是 0x32 | 查它引用的微雪代码 | 那个 0x32 是 0x01 命令后面的一个数据字节，不是命令 |
| 颜色码 0 黑 1 白 2 绿 3 蓝 4 红 5 黄 6 橙 | 官方代码和上屏 | 这是 7 色屏的码表；本屏是 0 黑 1 白 2 黄 3 红 5 蓝 6 绿 |
| 任意色直跳要 6×6=36 条转移波形 | Glider README | Spectra 6 波形只按目标色存 |
| 橙色不存在，是红黄两色抖动出来的 | 真机单变量实验 | PWRR 的中间轨留在默认低值，code 3 出橙；把中间轨抬高，同一段波形出红 |
| 底线来自 8 像素没对齐、0x3C 没配、少一个 NOP，往下多扩几行就好 | 真机 | 线只在窗口底边落在屏幕上半区（y 小于约 248）时出现；多扩几行不治，扫尾帧、改垂直分辨率也不治 |
| 把边框设成高阻 | 真机 | 方向对：0x50 设 0xFF（边框高阻）、刷新参数改 0x01 之后，窗口外的背景污染没了；它后来给的具体值 0x17 和实际用的不一样 |
| PLL 0x02 是 43 Hz，0x07 是 100 Hz | 手册 | 对得上。但它建议把 PLL 当调色的"变速箱"，这正是我 5 月踩过的坑 |
| 局刷时栅极扫的是整屏，不只窗口 | 手册 | 对 |
| 截断波形会造成直流失衡，长期伤屏 | 没给来源 | 方向对；橙色那个配方跑的是完整刷新 |
| "2026 年用 UNO Q 配 GDEP073E01 的项目里"爆出的大坑：SPD1656 和 SPD1657A 混淆、PLL 寄存器 | 这一条回答没有来源 | 这两个坑正是我 5 月 24 日发在 Hackaday 那篇的第六、第八节；它还说扫了 r/cyberDeck 的新帖，我 5 月 25 日刚在那里发过这个项目。我怀疑是我自己的帖子转了一圈又回来了（推断） |
PLL 那一条，我当时在对话里就回了它一句：
"坑2我已经踩到了。因为PLL也会和温度补偿lut有关。调整不同的补偿lut和pll确实能出不同颜色。"（2026-06-01）
5 月初到 16 日，我一直把 PLL 发成 0x07，记下三十多种"新调色板"，改回厂家的 0x08 之后大多被证明是超频伪影。Gemini 的频率值说对了，却把这个现象当成调色技巧来推荐。
第二份清单之后：五条"隐藏命令"
6 月 2 日凌晨两点多，我把板上整理好的第二份清单贴给 Gemini，问还有没有别的根治路线。它又给了 5 条寄存器建议。板上的 Claude 把命令映射和它几乎相同的 UC8179c 的手册也调出来对照，结论是 5 条里 2 条有据、对症、之前没试过；剩下三条，一条的位定义是编的，一条是早就走死的旧路，一条是芯片混淆：
其中最像回事的是 0x60 TCON，源极和栅极之间的非重叠死区。它在我们的初始化里一直在发，值是 [0x02, 0x00]，也就是死区为零，而线的机制正是"边界那一行栅极还没关、源极已经切换"，看上去完全对症。真机一试，没用：
板上的 Claude 先说寄存器这条路"真正穷尽了"，我追问了一句，它又承认说过头了：真测过排除的只有扫尾帧、局刷末字节、垂直分辨率、TCON 四条，另有两条只靠机制推断判死，还有几条完全没碰。唯一能碰到根上的办法，是改刷新最开头那一段驱动波形，而本芯片疑似唯一能写波形的入口是手册上没有的 0x21，格式没破解，是块长期的硬骨头。
所以最后定下来的是几何法：需要干净局刷的窗口，底边放到屏幕下半区；上半区的元素变化时走全刷。凌晨四点多，它按这条规则把仪表盘现有的局刷元素过了一遍：
回头看 5 月 31 日那个"窗口矮了才出线"的发现，那组测试的窗口顶边都在 y=190：100 行高时底边落到 290，在下半区；24 行高时底边是 214，在上半区。所以高度只是表象，底边落在哪半屏才是变量。这是我按两份记录的数字推出来的。
那两份追问清单的最后一句，提的是同一个要求：请分清"手册明写"和"你的推断"，并标出哪些信息可能来自别的芯片。