A new solution for controlling parallel eink displays

Intro

We're all familiar with Kindle-type e-book readers. They've been around for enough years and have been copied by enough competitors that we've seen or used one over the last 10 years or so. What these devices have in common is that they make use of a high speed eink display which is controlled over a parallel data bus. These displays can handle 8 or 16-bits of data sent at up to (and beyond) 20MHz. This allows them to have very high resolution and support fast updates. What has typically been controlling these displays is a powerful 32 or 64-bit Arm processor running Android or Linux. People have made an effort to hack these devices to run their own code, but that path is not always practical or cost effective.

How does parallel eink work?

For people familiar with SPI epaper displays like the small ones found in supermarket shelf labels, the larger parallel ones work on the same principal. Charged pigment particles are suspended in a clear oil between two conductors and pushed back and forth with an electric field. The smaller displays normally have a dedicated controller built onto the display glass (e.g. SSD16xx or UC81xx) which is optimized for low power. You send it commands and data over a 1-bit serial bus (SPI) and it manages the framebuffer and updating of the pixels. Parallel eink displays are very similar except that there is no low power controller on the glass and instead, a simple state machine is exposed. This state machine allows you to write data a row at a time and step to the next row. The row data consists of 2-bits per pixel which control the two transistors of each pixel. The 2 bits normally mean the following: 00 = floating/no-change, 01=make darker, 10=make lighter, 11=skip. The display only has memory for a single row, so you need to manage the framebuffer on the MCU side. Since the pixel control bits are sent 8 or 16 at a time (parallel data bus) and at high speed (~20MHz), you can push a whole frame's worth of data quite quickly. One catch - it takes more than one "push" to get the pixels to be fully positioned into a black or white state. For the average panel, it may need 5 to 10 pushes to get the pixel to fully go from one state to another. This may seem impractical - why not just do the full push in one shot. There are two reasons - one is that the temperature affects the viscosity of the oil. The colder the ambient temperature, the slower the granules move. This means that it will take more 'pushes' to get the color you want. The other reason is that by allowing an incremental push, the display can support shades of gray between black and white. Now we've hit the really complex subject of getting 16 good looking gray levels from black and white eink! Besides the temperature, the mobility of the granules increases if they're thrust back and forth between their black and white states. This is why a 'full' update will set all pixels to black and then white and then the final color - to ensure that they're maximally mobile and will be fully set into their extreme positions. To get more than a few unique gray levels, it requires a long set of moves (->B->W->B->B->W) to tease them into middle positions. The manufacturer (EInk) publishes a matrix of values for each temperature and for transitioning from one gray level to another. Sometimes these tables stretch for more than 40 steps per color change! There are more simplistic efforts to get gray levels that take fewer steps, but result in poorly distributed grays. This set of steps has mistakenly been called a "waveform". There's no waveform involved in eink displays - it's a purely digital device with several fixed states.

A Hacker's Option

A few years ago some adventurous people reverse engineered the signals which control the displays and decided to create their own hardware to drive them. The displays are readily available for purchase direct from China, so there was nothing stopping someone from making their own e-reader or other application. The first of these efforts to formalize the hardware and software side was called the EPDiy project from Valentin Roland in 2019. He created a PCB based around the ESP32 along with a code library to drive it. A couple of years later, Soldered.com created some crowdfunding projects based on 'recycled' eink displays and that started their line of products they call 'Inkplate' devices. These too are mostly based on the (older) ESP32 except for their newest (Inkplate6 MOTION) which uses an STM32. The EPDiy project is more geared for 'diy' people because it offers open source hardware and software plans, but is not involved in selling actual hardware. The Inkplate series allowed people to buy ready-to-use hardware and start experimenting with fast eink displays.

Smaller Displays

The two sources above weren't the only ones working on parallel eink products. Both M5Stack and LilyGo released several versions of their 4.7" 960x540 eink products over the last few years. M5Stack's original M5Paper used the IT8951 controller to drive the display, but their newer device (PaperS3) uses the ESP32-S3 to directly control it.

Unnecessary Slowness

I have been mostly on the sidelines of this field of parallel eink displays until recently. I saw info about a new project called ZeroWriter that was using the Inkplate5V2 PCB as the basis of an eink typewriter. I contacted the project lead (Adam) and asked if he was happy with the performance of the Inkplate library. He wasn't and risked some of his own money to send me the Inkplate5V2 board to see if I could help. After receiving the board, it took less than a day to dramatically improve the performance of display updates by cleaning up the code.

A New Solution

I was quite displeased with all of the software provided by these different projects and instead of hacking at each of them, I decided to do something more definitive about it - create my own library. Over the holiday (Dec/Jan 24/25), I created code which can drive the following boards:

• M5Stack PaperS3
• EPDiy V7 (all panel types)
• Inkplate5 Gen 2
• Inkplate6PLUS

In time, I'll support more devices, but this is a good start. So what makes this code special? Besides speed, I replicated my API and features from my bb_epaper library. This means it includes support for highly compressed fonts and graphics and all of the normal graphics primitives. How does this translate to fast eink panels? Well, here's a simple example - using my AnimatedGIF library to display an animation on the Inkplate5 Gen 2:

I'm now working with Martin Fasani to create complete hardware and software solutions for parallel eink which are easier to use and more affordable than what's currently in the market. More info soon...