[{"element_type":"markdown","content":"\u003cp\u003eBack in \u003ca href=\"https://adafruit-playground.com/u/melastmohican/pages/rust-on-adafruit-rp2040-feather-thinkink-jd79661-e-paper\"\u003emy earlier post\u003c/a\u003e, I wrote about bringing up a single JD79661 panel on this board with a driver built from scratch. That driver has since grown into \u003ca href=\"https://crates.io/crates/epdsi\"\u003e\u003ccode class=\"inline\"\u003eepdsi\u003c/code\u003e\u003c/a\u003e, a published \u003ccode class=\"inline\"\u003eno_std\u003c/code\u003e, \u003ccode class=\"inline\"\u003eembedded-hal\u003c/code\u003e 1.0 Rust crate. I went back to the same ThinkInk Feather to see how far it reaches now.\u003c/p\u003e\n\n\u003cp\u003eAnswer: \u003cstrong\u003eseven panels, five controller ICs, one 24-pin FPC socket, no wiring changes.\u003c/strong\u003e Swap the panel, reflash, done. All seven verified working on the first attempt:\u003c/p\u003e\n\n\u003ctable\u003e\n\u003ctbody\u003e\u003ctr\u003e\n\u003cth\u003ePanel\u003c/th\u003e\n\u003cth\u003eController\u003c/th\u003e\n\u003cth style=\"text-align: right\"\u003eFull refresh\u003c/th\u003e\n\u003cth style=\"text-align: right\"\u003ePartial/fast\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e1.54\" Tri-Color\u003c/td\u003e\n\u003ctd\u003eSSD1681\u003c/td\u003e\n\u003ctd style=\"text-align: right\"\u003e17,881 ms\u003c/td\u003e\n\u003ctd style=\"text-align: right\"\u003e17,881 ms (windowed, no saving)\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e2.13\" Mono\u003c/td\u003e\n\u003ctd\u003eSSD1680\u003c/td\u003e\n\u003ctd style=\"text-align: right\"\u003e3,893 ms\u003c/td\u003e\n\u003ctd style=\"text-align: right\"\u003e1,017 ms (differential)\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e2.13\" Quad-Color\u003c/td\u003e\n\u003ctd\u003eJD79661\u003c/td\u003e\n\u003ctd style=\"text-align: right\"\u003e20,041 ms\u003c/td\u003e\n\u003ctd style=\"text-align: right\"\u003e—\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e2.66\" Tri-Color\u003c/td\u003e\n\u003ctd\u003eSSD1680\u003c/td\u003e\n\u003ctd style=\"text-align: right\"\u003e20,044 ms\u003c/td\u003e\n\u003ctd style=\"text-align: right\"\u003e16,176 ms (FastFull)\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e3.52\" Tri-Color\u003c/td\u003e\n\u003ctd\u003eUC8253\u003c/td\u003e\n\u003ctd style=\"text-align: right\"\u003e17,366 ms\u003c/td\u003e\n\u003ctd style=\"text-align: right\"\u003e—\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e3.7\" Mono\u003c/td\u003e\n\u003ctd\u003eUC8253\u003c/td\u003e\n\u003ctd style=\"text-align: right\"\u003e2,615 ms\u003c/td\u003e\n\u003ctd style=\"text-align: right\"\u003e410 ms (FastPartial)\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e4.26\" Mono\u003c/td\u003e\n\u003ctd\u003eSSD1677\u003c/td\u003e\n\u003ctd style=\"text-align: right\"\u003e3,744 ms\u003c/td\u003e\n\u003ctd style=\"text-align: right\"\u003e500 ms\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\n\n\u003cp\u003eTwo 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.\u003c/p\u003e\n\n\u003cp\u003eFull code, wiring notes, and measurement methodology: \u003ca href=\"https://github.com/melastmohican/adafruit-feather-thinkink-discovery\"\u003e\u003ccode class=\"inline\"\u003eadafruit-feather-thinkink-discovery\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n\n\u003ch2\u003eConclusion\u003c/h2\u003e\n\n\u003cp\u003eIf you're on this board, \u003ccode class=\"inline\"\u003eepdsi\u003c/code\u003e is worth a look regardless of which panel you're holding. One driver, one socket.\u003c/p\u003e\n\n\u003cp\u003eOne 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 \u003ccode class=\"inline\"\u003erp-rs\u003c/code\u003e gets by default.\u003c/p\u003e\n\n\u003cp\u003eThe workaround: route \u003ccode class=\"inline\"\u003edefmt\u003c/code\u003e over USB CDC instead, via \u003ccode class=\"inline\"\u003edefmt-bbq\u003c/code\u003e. \u003ccode class=\"inline\"\u003eepd.refresh()\u003c/code\u003e 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 \u003ccode class=\"inline\"\u003edefmt-bbq\u003c/code\u003e 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.\u003c/p\u003e\n\n\u003cp\u003eIf 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.\u003c/p\u003e\n","metadata":{"markdown":"Back in [my earlier post](https://adafruit-playground.com/u/melastmohican/pages/rust-on-adafruit-rp2040-feather-thinkink-jd79661-e-paper), 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`](https://crates.io/crates/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.\n\nAnswer: **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:\n\n| Panel | Controller | Full refresh | Partial/fast |\n|---|---|---:|---:|\n| 1.54\" Tri-Color | SSD1681 | 17,881 ms | 17,881 ms (windowed, no saving) |\n| 2.13\" Mono | SSD1680 | 3,893 ms | 1,017 ms (differential) |\n| 2.13\" Quad-Color | JD79661 | 20,041 ms | — |\n| 2.66\" Tri-Color | SSD1680 | 20,044 ms | 16,176 ms (FastFull) |\n| 3.52\" Tri-Color | UC8253 | 17,366 ms | — |\n| 3.7\" Mono | UC8253 | 2,615 ms | 410 ms (FastPartial) |\n| 4.26\" Mono | SSD1677 | 3,744 ms | 500 ms |\n\nTwo 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.\n\nFull code, wiring notes, and measurement methodology: [`adafruit-feather-thinkink-discovery`](https://github.com/melastmohican/adafruit-feather-thinkink-discovery).\n\n## Conclusion\n\nIf you're on this board, `epdsi` is worth a look regardless of which panel you're holding. One driver, one socket.\n\nOne 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.\n\nThe 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.\n\nIf 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.\n"}}]