Back in my earlier post, I wrote about bringing up a single JD79661 panel on this board with a driver built from scratch. That driver has since grown into epdsi, a published no_std, embedded-hal 1.0 Rust crate. I went back to the same ThinkInk Feather to see how far it reaches now.

Answer: seven panels, five controller ICs, one 24-pin FPC socket, no wiring changes. Swap the panel, reflash, done. All seven verified working on the first attempt:

Two things worth calling out. Colour panels have no fast path: narrowing the RAM window reduces what's redrawn, not what it costs, so a partial refresh on a Tri-Color panel takes exactly as long as a full one. Both UC8253 panels work fine here too, which is notable because an earlier bring-up on a different ESP32-C3 board logged them as non-functional. That module later turned out to be faulty hardware, and these clean first-try runs on the ThinkInk are the evidence the driver was never the problem.

Full code, wiring notes, and measurement methodology: adafruit-feather-thinkink-discovery.

Conclusion

If you're on this board, epdsi is worth a look regardless of which panel you're holding. One driver, one socket.

One thing I'd change on the hardware side, though. The 24-pin FPC connector is genuinely great: seven panels, zero wiring, swap and reflash. But this board ships with no SWD connector, so there's no RTT logging, the easy path everyone else on rp-rs gets by default.

The workaround: route defmt over USB CDC instead, via defmt-bbq. epd.refresh() blocks for seconds at a time and USB needs polling every few milliseconds to stay alive, so that meant splitting the two cores. Core1 services USB and drains the defmt-bbq buffer; core0 runs the actual panel logic. It works, and every example in this repo uses it. But it's real plumbing I shouldn't have had to build just to see a log line mid-refresh.

If there's a next revision of the ThinkInk Feather, please bring back SWD. RTT logging is the only sane way to see what's happening while a refresh is in flight, on a board that spends most of its time in long, blocking e-paper refreshes. Otherwise you're stuck inventing a second communication channel just to debug.