We (Pimoroni) actually shipped this technique in PicoVision, used to load the “GPU” firmware (an RP2040 used to offload the HDMI signal generation) at runtime-
I could believe you feel less latency, but suspect that’s more a symptom of matrix scanning working for the general case rather than being optimised for your layout. Scan with an RP2040’s PIO [1] and after debouncing I’d challenge you to measure the difference, much less notice it.
(Of course if you’ve got the pins, you should use ‘em!)
This sounds like it could port well to an RP2040-based display. Though I am forever battling against its very constrained RAM for network stuff (not helped by MicroPython needing a chunk for buffers, an GC bitmap for mark/sweep and some other network mystery meat). That said our (Pimoroni) larger Pico W-based Inky has an 8Mbit PSRAM to act as a back buffer for the display. It’s “slow” but when updates take 30s+ anyway that’s kind of redundant. Very little of that 8Mbit is actually used, so with a little tinkering it might be able to cache multiple images for sequential display without having to faff about with SD cards.
Currently I transmute some images (XKCD and NASA APOD) via a scheduled GitHub action into something fit for the various display sizes. An even more extreme approach would be to convert into the packed (4bpp for 7-colour E-ink) framebuffer format server-side. Less network efficient, but more predictable memory usage.
We’ve had JPEG support for a while, but I brought up a PNG decoder (Larry Bank’s PNGdec) recently(ish) and it’s a much better fit than JPEG for palette-based images. It uses a 32K sliding window, however, which can get spicy if you’re not careful.
Our crude (actually Pillow’s IIRC) dither has a certain nostalgic appeal to it, but can definitely be bested by other algorithms. I’m still not totally convinced we have a great perceptual match for the colours either. The approach to get them - take a photo of the screen, use a colour dropper and a bit of eye balling - was crude.
(Hi, I wrote most of the Inky driver and your project is the kind of awesome I wish the Pico/RP2040-based Inky Frame devices could pull off.)
I always say "if it's stupid and it works, it's not stupid". Your approach to get the dithering right sounds brilliant to me :D.
The current inky driver works great, and that fact that it's in Python is what made me develop the original FrameOS software in Python. However now that I rewrote it in Nim, the Python driver is a bit of a crutch. While I could use the C drivers for the Waveshare displays, I'm forced to install a python wrapper on the Pi as a workaround to get the Inky drivers working.
Do you have any idea if there are any C, or even Nim drivers available for the Inky Impression boards? The Python workaround works, but isn't really elegant. If not, I'm considering porting them myself at some point...
I'm also lurking on the Pimoroni discord, and was meaning to ask there about it as well.
I have written drivers for Pimoroni's Inky Frames (based on Raspberry Pi Pico W) in Nim, but I don't own an Inky Impression. The code should be pretty similar once it hits the SPI bus.
I have planned to write GPIO/SPI/I2C "drivers" in Nim that interfaces with the Linux drivers. So far I have made a wrapper for libgpiod. https://github.com/daniel-j/nim-gpiod
I started putting together a Lua-based toy microcomputer [1] using PicoVision and a USB mini B to A adapter to connect a mouse/keyboard. It’s a hacky mess, but it serves as a proof of concept.
There’s also a herculean work in progress to bring PicoVision support to the 32blit embedded game SDK [2]
Really interested in putting together some kind of USB host to HID over GATT profile or Bluetooth HID to i2c/UART bridge.
We’re (Pimoroni) closing on shipping a dual RP2040 HDMI board (PicoVision) that’s great for bedroom coder style games, but lack of full fat Bluetooth support or USB HID host in MicroPython - and the relative pain of making and supporting a build that includes these features - make adding controllers… tricky.
Now I wish I’d kept the Dreamcast controller I modded with a custom cable to poke Maple bus. Hindsight!
Obligatory shameless plug of https://pinout.xyz where I’ve been maintaining an interactive Raspberry Pi SBC pinout for some years, and the newer https://pico.pinout.xyz where I’ve tried to do the same for the Raspberry Pi Pico board. The latter also became a command-line pinout via the Python package “picopins”
I feel- and of course I’m biased- that if anything is worth bringing to the table for device pinouts it’s interactivity and accessibility. The latter, in particular, is lost in static images. I really leaned into this with the Pico Pinout, including everything from visual accessibility accommodations (avoiding low contrast text background colours), to markup for screen readers to the ability to turn off labels and reduce noise. I’m still unsure if I actually achieved my goal, but it’s been fun.
I’d be remiss not to mention that we (Pimoroni) sit right at the hacker end of the E-ink scale with stuff like Badger2040W [1] and Inky Frame [2], both of which pair (small and less small) E-Ink panels with the RP2040 microcontroller so you can BYO software.
The biggest roadblock to these being super compelling is update rate. The black/white screen on Badger can be driven pretty hard, but overdriving it (a friend built a continuous E-ink zoetrope [3]) has consequences.
Inky Frame’s 7 colour display is awesome for dithered artwork (missing cyan and magenta notwithstanding) but very, very slow to refresh- ~30s after the panels were updated to incorporate an unskippable “clean” phase.
Faster, cheaper and bigger all seem mutually exclusive right now, but I share the authors passion for the format.
