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:

Panel	Controller	Full refresh	Partial/fast
1.54" Tri-Color	SSD1681	17,881 ms	17,881 ms (windowed, no saving)
2.13" Mono	SSD1680	3,893 ms	1,017 ms (differential)
2.13" Quad-Color	JD79661	20,041 ms	—
2.66" Tri-Color	SSD1680	20,044 ms	16,176 ms (FastFull)
3.52" Tri-Color	UC8253	17,366 ms	—
3.7" Mono	UC8253	2,615 ms	410 ms (FastPartial)
4.26" Mono	SSD1677	3,744 ms	500 ms

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.

Following my previous exploration with the Adafruit RP2040 Feather and custom ThinkInk e-paper drivers, I wanted to take the next logical step in embedded Rust: building cross-platform, hardware-agnostic drivers that can jump between entirely different architectures without breaking a sweat.

I recently received the Adafruit ESP32-C6 Feather (PID 5933), featuring a single-core RISC-V SoC. To pair with it, I developed the modulino Rust library—a pure no_std driver that currently supports all 12 modules in the Arduino Modulino family.

Thanks to the Feather's built-in STEMMA QT / Qwiic connector, getting this setup running requires absolutely zero soldering. You can hardware-verify your embedded apps by simply daisy-chaining the modules together over a standard 100kHz I2C bus.

1. Setting Up the RISC-V Environment

Unlike ARM Cortex-M or RP2040 targets, the ESP32-C6 utilizes a 32-bit RISC-V core. We can easily configure our environment using standard Rust toolchains and espflash:

Make sure your project's .cargo/config.toml is configured to leverage espflash for seamless flashing and serial monitoring over the built-in USB-JTAG connection: