Basics of driving E-paper displays

A project log for NekoCal - an E-Ink Calendar

A simple calendar made with e-ink display and stm32 microcontroller.

wenting-zhangWenting Zhang 03/30/2021 at 01:592 Comments


Hi, how's going? I haven't written anything about this project for a long while. I was thinking about making a better version of this, that could support more displays, has an open API, support wireless communication like WiFi, LoRaWAN, etc. But I didn't have the time to pull that off. Instead, I made my code open and wrote a log to describe how to get greyscale when driving these screens directly with an MCU such as STM32 or ESP32 (which no one explored before). I am glad to see the communities were able to take what I have done and built the thing that I wanted to build: the EPDiy project. And there are emerging projects like ei2030's E-ink laptop that are aiming to take the E-ink DIY idea further.

However, people who are new to the whole E-ink DIY thing might be confused: there are so many screen choices. Some require quite sophisticated driving boards, others don't. There are boards that could be connected to an Arduino, and there are also boards that would simply accept standard HDMI inputs. Are they compatible? What are the advantages and disadvantages of different driving schemes?

I am writing this log, to describe some of the basics of driving E-ink/E-paper displays. Hopefully, this could be helpful.


For any E-paper display devices, it needs the following components:

Every system needs these components. However, they could be integrated, so one may not be aware of these. One common technology used in screens nowadays is called "Chip On Glass", or COG for short. It allows integration chips on the glass panel. Virtually all E-paper displays use this technology to integrate some parts of the system onto the glass. (If EPDs were commercialized 10 years earlier, you would see other technologies being used in place of COG, such as TAB, or COB, etc.)

Most of the screens available today can be divided into two categories based on what is integrated into the glass panel, as shown in the diagram as Type A and Type B.

Note: The type A/B name is made up by myself, there is no standard way of calling them AFAIK.

The type A screen integrates only the display driver chips, however, the type B screens integrates almost every chip you need to use the screen.

Here is a non-exhaustive list of the type based on their size: (the size or resolution is not related to or limited by the type, it is just for a certain size, the vendors tend to make them the same type.)

Type A (driver-only)

Type B (fully integrated)

One may notice that almost all e-readers/ e-ink cellphones use Type-A screens, while almost all e-ink electronic shelf labels (ESL) uses Type-B screens. This gives some hints about the advantages and disadvantages of two types:

Type A (driver only)
Type B (fully integrated)
System Cost
High. A dedicated controller usually needed. Needs a dedicated power supply.
Low. Virtually any MCUs could drive the screen directly
Greyscale LevelsGenerally 16 (4bpp), up to 32 (5bpp)
Generally 2 (BW only) or 4 (2bpp), with some hack, up to 16 (4bpp)
Refresh Speed
Generally fast (100ms~600ms), depending on the screen used and the system architecture
Generally fast (100ms~300ms) for BW if the partial refresh is enabled. Greyscales much slower, BWR or BWY screens would be even slower.
Total Update Latency
Generally the same as refresh time. Depends on the system architecture
Slow. Ranging from 100ms to 10s based on the resolution.

Note that I mentioned the refresh speed and total update latency. How they are different?

The refresh speed refers to the time it takes to start refreshing the screen: from starting seeing screen changing, to the screen finish showing the new content.

The total update latency refers to the latency when the processor needs to update the screen, to the screen finish showing the new content. As you could see, this is the biggest issue for Type B displays. This is the main reason why they are almost never used on e-readers or cellphones or PC monitors.

Driving type-B / fully integrated screens

This is fairly simple. Type-B screens have almost everything already integrated. Common type-B displays only need few external capacitors, inductors, and MOSFETs to support the integrated bipolar power supply circuit, then it could be hooked up to MCUs or MPUs using common interfaces like SPI or I2C. There are a lot of driving boards and examples of these screens available online. As they are basically the same, I will not go into details about them.

Driving type-A / driver-only screens

This could get complicated. Note I used a lot of "generally" in the comparison chart because there are many things you could do to drive them. Some of them would certainly impact the performance. The main issue here the controller chip. There are two types of commercial solutions to drive these screen:

And then... there is a third way, a low-cost and more accessible way of driving these screens:

Then, again here is a comparison between them:

Specialized controller chip
SoC with integrated controllerMCU + Software TCON
Limited by MCU RAM. Up to XGA with SRAM, UXGA with PSRAM, UXGA+ with DDR
Greyscale1616Up to 32
Partial Update
Yes (monochrome and greyscale)
Yes (monochrome and greyscale)
Yes with vendor waveform (monochrome and greyscale) and open-source waveform (currently monochrome only)
Waveform support
Vendor waveform or open-source waveform if open-source controller chip is used
Vendor waveform only. Might could work with open source waveform as well with some hack
Vendor waveform and open-source waveform
Total Update LatencyDepends. Could be very close as refresh speed, could be slow like Type-B screens
Same as refresh speed.
Same as refresh speed if data is internally generated. (not streaming from an external device such as a PC)
Suitable Applications
IoT devices,
E-readers, cellphones,
E-ink monitors.
possibly E-ink laptops
Advanced IoT devices, E-readers, cellphones,
E-ink typewriters,
possibly low-performance E-ink laptops
When using MCU: IoT devices, large ESLs, simple DIY E-readers
When using MPU: Same as SoC with integrated controller

Some additional notes about some of the items in the table:

About waveform...

The waveform is a look-up table that the controller uses to determine how to drive the screen. Features like greyscale display and partial updates are enabled by sophisticated waveforms. This is an essential part of any e-ink controller. There are two different types of waveforms: vendor waveform and open-source waveform.

Vendor waveforms are copyrighted material. Think them of like the BIOS or ROM of the game consoles. Issues with console emulators apply here: one cannot distribute them legally. Currently, they are protected by NDAs, so not easily obtainable from the vendor. Dumping the waveform would require buying a commercial device and extract by the end-user.

Open-source waveforms are created by the community as a replacement to be used in open-source projects. They are created with cleanroom technology (at least the ones used in my project are entirely crafted by hand by myself. I have never reverse engineered any vendor waveforms.) so they are not copyrighted by vendors. However, they are limited in performance, missing critical features, and might not compatible with vendor waveforms (thus not compatible with controllers designed to work with vendor waveforms).

Waveforms are interchangeable between different screens to some extent. The screen would work with a non-optimal waveform, but the image may not show the correct color (gamma, brightness, etc), the ghosting could be more noticeable.

About update latency again...

The latency, is composed of 2 parts: the time it takes for the processor to transfer the image to the controller, and the time it takes for the controller to drive the driver to display the content on to the screen.

The reason Type B screens are slow is that, they tend to use slow protocols to talk to the processor. For example, the most common one is the SPI, could only transmit up to ~20Mbps. For a 1024x758 panel at 4bpp, it takes 1024 * 758 * 4 / 20000000 = 150ms to transmit the image, would be worse if SPI is running at slower speed or . This adds 150ms to any frame to be displayed.

For Type A screens, it really depends on the controller used.

If using SoC with integrated controller, or MCU direct drive scheme, the image is always already in the RAM local to the controller. The latency is just the latency to access the RAM, which is usually less than 200ns and can be ignored.

If using a dedicated controller, it depends on how the controller is connected to the processor just like Type B screens, but you have more choices.

For example, controllers like IT8951 or S1D13xxx supports i80/68K parallel interface, which brings down the latency to like 20ms. Controller that supports DPI/ DSI/ HDMI interface, depends on the implementation, the latency could be 1 frame (16.7ms) or just 1 line (~20us).

About the suitable application...

When using a dedicated controller, it could accept data from external devices. This allows it to be used in various different types of applications. Ranging from IoT devices, ESLs just like when using Type B displays, to PC monitors with relatively fast refresh rate and low latency.

When using SoC or MCU, the display content is generated by the SoC or MCU itself, which ultimately is limited by the capability of the SoC or MCU. Given the current SoCs with E-ink display controllers are quite limited in performance, the application is limited. The same goes for MCU, it does what an MCU could do. You could find ways to stream video data into SoC or MCUs by using USB, camera interface, WiFi, etc., but this might not be optimal.

List of the available solutions by driving scheme:


Hopefully this log clarifies some of the confusions or answers some of the questions. There are different types of displays and different ways to drive the screen. They come with their advantages and disadvantages. There is no single best way of doing things, it all depends on the requirement of the target application.


David Anderle wrote 11/05/2021 at 15:10 point

I've been researching ePaper displays for a couple of days now and this blog was a good confirmation to my findings. It seems to me that if I want to achieve "high" frame rates my best option is still the i.MX family. You also mention a "Waveshare HDMI driver board" under your commercial devices, however I could not find any reference to that chip/SoC/gadget. Have you maybe got a link/part number? An FPGA solution would be quite intriguing.

Just out of curiosity, how do you know that the reMarkable 2 uses software TCON? Their tablet uses NXP's MCIMX7D2DVK12SD which version has no integrated EPDC (nor CAN). Also, by software TCON do you mean that they bit-bang the EPD bus from software-driven GPIOs? I wonder how difficult that is as their screen seems quite sharp and responsive. 

  Are you sure? yes | no

Giovanni wrote 03/30/2021 at 09:28 point

Awesome! This helps me understand so much more- I kept forgetting display controller & driver were two different things.

  Are you sure? yes | no