There’s a lot to like about E-Ink displays, and you might be about to like them even more with [antirez]’s MicroPython driver for the Badger 2040 (or any display based on the UC8151 / IL0373) because it brings all kinds of useful features to your next project.
E-Ink displays are great. They are high contrast, daylight-readable, and require zero power to maintain a displayed image. But a few things come with the territory: displays have slow refresh rates compared to other display types, expect flickering during screen changes, and the displays are monochrome. [Antirez]’s new driver not only provides a MicroPython interface but goes in some fantastic directions that challenge those usual drawbacks.
Probably the most striking is the ability to display greyscale images without relying on dithering, which means the results avoid the charmingly gritty look of old-school dithering. Dithering has its place, but it’s not always the best choice, so options are great.
Similarly, display flicker may be a small price to pay for some, but if the obvious flicker is too boorish and crude-looking one can use an anti-flicker refresh mode that greatly limits flickering at the cost of update speed. Over time some image ghosting will accumulate which necessitates an occasional whole-screen refresh, but the effect is overall much nicer when updating something like a clock face.
How is this all done? It turns out that the controller chips for these displays are highly configurable, and it’s possible to do much more than simply drive the display in known-good and completely approved modes. It’s also entirely possible to permanently damage one’s display by doing so. Part of what makes [antirez]’s work so appealing is that he has already done the work finding workable configurations.
His driver is designed using computed LUTs (look-up tables) that make using and exploring alternative refresh modes easy and efficient, invaluable for exploring the capabilities of a patented, poorly documented technology like E-Paper displays.
We’ve seen the Badger 2040 E-Ink display in a teapot timer and a custom macropad, and [antirez]’s uc8151_micropython project is a fantastic step forward. And don’t miss another of [antirez]’s clever microcontroller hacks: playing audio without a DAC.
It’s always great to see that someone comes along with new thoughts to solve old problems.
I wish there would be a less flicker refresh solution for the Inkplate2. It was supposed to be used as a name badge for none hacker conventions. But the refresh is way to distracting.
I wonder if it would be possible to do a per pixel refresh, instead of full screen refresh.
Some higher-end kindles somewhat improved the refresh by “animating” it from left to right, so that it looks like a wave refreshing the screen. It’s pretty cool
Partial updates are possible on some screens. I have always had two types of screen refresh, one where you update the screen to full black/white before the image and one where you update on th mask of the previous one.
E-ink moonshot coming along nicely ;-)
Similar to what I’ve done with the Waveshare 3.7″ display:
https://github.com/jrymk/epepd
with 16 shades of grey and partial updates.
The computed LUT idea is very interesting. Maybe I’ll revisit this topic.
Props to [antirez] for the fantastic documentation, and for including links to reference material!
Why use MicroPython? MicroPython is interpreted, glacially slow compared to compiled C/C++. The MicroPython core is written in C to begin with! Ben Heck did a C/C++ versus MicroPython speed comparison on the RP2040 and found C/C++ to be around 1071 times faster than MicroPython:
“C is compiled, while Python is interpreted. Compiled will always (don’t quote me on that) be faster. I think Ben Heck did a comparison in his Pico video: https://youtu.be/dd2fofTF9CI?t=448.%5B1%5D C code can turn on/off a pin in 60MHz, while the same logic in MicroPython runs at ~56kHz, so over 1000x slower than the C code.”[2]
1. Raspberry Pi Pico Testing – Ben Heck Hacks [YouTube]
https://www.youtube.com/watch?v=dd2fofTF9CI&t=448s
2. How fast and reliable is MicroPython?
https://www.reddit.com/r/MicroPythonDev/comments/mrg5us/comment/gup57db/
If you need to do low level bitbanging stuff you can write the driver in C and link it to MicroPython. (Micro)Python is intended for high level code. It shines when you use optimized libraries.
If it works, it’s good enough – and sometimes throwing something together in python is 10x faster to get working than doing it all from the ground up in C.
What was that famous quote about premature optimisation?
Haven’t used MicroPython? :P
You should read more of Antirez’s posts where he explains how to get similar to C levels of performance in MicroPython…
is there a video showing the fast (partial) updates with thjis driver?