Introduction

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.

Components

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)

• 4.3" panels (both 800x480 and 800x600)
• 6.0" panels (both monochrome and ACeP)
• 7.8" panels (both monochrome and ACeP)
• 9.7" panels
• 10.3" panels
• 13.3" panels

Type B (fully integrated)

• 1.02" panels
• 1.54" panels
• 2.13" panel
• 2.6" panels
• 2.9" panels
• 3.71" panels
• 4.2" panels
• 5.83" panels
• 7.5" panels
• 12.48" panels

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 Levels	Generally 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:

• Using a dedicated controller chip to drive the screen
• Using an SoC that has an integrated controller

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

• Using a fast MCU/SoC to emulate the controller with GPIO (software timing controller)

Then, again here is a comparison between them:

	Specialized controller chip	SoC with integrated controller	MCU + Software TCON
Resolution	UXGA+	UXGA+	Limited by MCU RAM. Up to XGA with SRAM, UXGA with PSRAM, UXGA+ with DDR
Greyscale	16	16	Up 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 Latency	Depends. 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:

• Specialized controller chip
  • Closed-source / Commercial
    • EPSON S1D13xxx: Widely used EPD controller in early E-readers. Proprietary, no documents available. Probably EOL.
    • IT8951: Used on waveshare EPD Hat. Documents available, work with large EPDs. The drawback is the speed. Using IT8951 with a large Type-A EPD effectively turns it in to a Type-B like screen, with high update latency (interface between processor and IT8951 could be slow)
    • Waveshare HDMI driver board: FPGA-based controller. Closed source but easily purchasable, could be integrated into larger projects as a module.
    • Dasung E-ink monitors: Not sure. FPGA + some proprietary controller.
  • Open-source
    • https://hackaday.io/project/21607-paperback-a-desktop-epaper-monitor: FPGA-based controller. However, doesn't support partial update mode.
    • https://hackaday.io/project/21168-fpga-eink-controller: Seems to be working. Not sure about the state.
• SoC with integrated controller
  • RK29xx: Fairly old, Cortex-A8 based (RPi 1 level performance), 55nm, EOL
  • RK3026/RK3028: Fairly old, Cortex-A9 based (RPi 2 level performance), 40nm, EOL
  • i.MX 50: Fairly old, Cortex-A8 based (RPi 1 level performance), 65nm, in production
  • i.MX 6S/D: Fairly old, Cortex-A9 based (RPi 2-3 level performance), 40nm, in production
  • i.MX 7S/D: Cortex-A7 based (RPi 2 level performance), 28nm, in production
  • i.MX 8ULP: Cortex-A35 based (RPi 2 level performance), 28nm FD-SOI, sampling
  • RK3566/RK3568: Cortex-A55 based (RPi 3 level performance), 22nm, in production
  Note none of them are confirmed to work with open-source waveform. I am not aware of any open-source hardware (as defined by OSHWA) projects built with these processors utilizing an e-ink screen.
  
• MCU/SoC + Software TCON
  • http://essentialscrap.com/eink/waveforms.html: One of the earliest e-ink hack. Limited in performance but still could be used as a reference
  • This project (NekoCal): One of the earliest e-ink software TCON with greyscale support. Used to be available as a DIY kit. No longer updated, still could be used as a reference
  • InkPlate 6/10: Commercially available. Based on ESP32.
  • EPDiy: Based on ESP32, supports a lot of different screens, recommended if want to build some device with ESP32+Eink or embedding it into a larger project.
  • Many new BOOX ereaders, using software driver + parallel LCDIF to drive the screen

Conclusion

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.