Parallel epapers driven by Epdiy - martinberlin/cale-idf GitHub Wiki

In the first weeks of 2021 Lilygo send me one of this parallel epapers. The difference between the other SPI models is that this ones do not speak SPI. They are driven by 8 data bus Gpios plus an additional Latch PIN (also called start pulse, enabling data input on the slave device when LOW) and a Clock pin. This Lilygo Model comes with all the wiring done in a nice PCB that we can see here below.

Epdiy E-Paper Driver component

Valentin Roland, a programmer from Germany, made an awesome component to drive this epapers called Epdiy.

A part of the Firmware that works in C he also made the BOM design/PCB to drive this Kindle replacement screens, which are available for 20$ (small) / 30$ (large) on ebay! The interesting thing, is that this epaper data protocol, is at least 8 times faster than SPI. Over SPI protocol bits travel by only one cable (3 Pins SPI) but here we have a whole byte, 8 bits, send on each clock tick. The EPDiy driver board targets multiple E-Paper displays. As the driving method for all matrix-based E-ink displays seems to be more or less the same, only the right connector and timings are needed. The EPDiy PCB v4 features a 33pin and a 39pin connector, which allow to drive the following display types: ED097OC4, ED060SC4, ED097TC2. With the upcoming revision v5, even more display types will be supported! For more details please check the supported epapers on @vroland repository.

Board requirements

ESP32 WROVER or similar with PSRAM (Not ESP32-S2 or C3 models) This is the reason the dependancy to this library is commented out in refactor/oop development Branch. There is a condition in components/epd_driver/CMakeLists.txt that prevents this.

Integrating this on Cale-idf

My first impulse on integrating this went bad. I tried to encapsulate all in C++ object oriented classes. It turns out that after reviewing the architecture it's not an easy task. Epdiy is exceptionally nicely built, using 2 "data sinks" that are looping in the background, and are triggered by DMA semaphores from the draw functions. This was not going to be easy to encapsulate. As a second reason to look in another direction is that Valentin is adding more models every month, since it turns out that the controllers driving this, are relatively similar compared to their SPI counterparts (That need specific wakeUp commands). So after loosing two days and giving it a second though decided to go another way.

With the experience learnt I took a different direction. I would leave Epdiy "as is" and just make C++ wrappers around it, same as my existing models, but using Epdiy functions directly for IO communication.

That way we could have the best of both worlds, a linked and working Epdiy, but with out C++ object oriented approach so we keep the same way and similar implementation examples as for the SPI existing models. It turns out this was the right approach and so far is working great. The first implemented model is already merged in master and the first epaper supported is LILYGO ED047TC1.

First proof of concept Firmware

A working example

In the File: main/demos/demo-epaper-parallel.cpp we left a working example. It's still on development, it will take a while to have all the methods wrapped, but so far the results are good and it's easy to implement. Here a small example:

// Run idf.py menuconfig-> Component Config -> E-Paper driver and select:
// Display type: LILIGO 4.7 ED047TC1
// Board: LILIGO T5-4.7 Epaper
// In the same section Component Config -> ESP32 Specifics -> Enable PSRAM
#include "parallel/ED047TC1.h"
Ed047TC1 display;

// Include a font header
#include <Fonts/ubuntu/Ubuntu_M24pt8b.h>

extern "C" { void app_main(); }

void delay(uint32_t millis) { vTaskDelay(millis / portTICK_PERIOD_MS); }

void app_main(void)
{
   display.init(true);
   //display.setRotation(1); // Working, 1 rotates 90° the display
   // Clear all screen to white
   display.clearScreen();
   delay(1000);

   // Draw some rectangles
   for (int x = 0; x < 200; x++) {

      for (int y = 0; y < 400; y++) {
         display.drawPixel(x, y, 0);
         display.drawPixel(x+200, y, 80);
         display.drawPixel(x+400, y, 160);
         display.drawPixel(x+600, y, 200);
         display.drawPixel(x+760, y, 230);
      }
   }

   // Draw some text using Ubuntu Font
   display.setCursor(30,200);
   display.setFont(&Ubuntu_M24pt8b);
   display.println("Hello world");
   display.update();
}

Existing conflicts with Adafruit GFX

The only small conflict at doing this is that in Epdiy the font structs are named like this: GFXglyph GFXfont

This collades with Adafruit own names. So for development purpouses I renamed them appending Diy at the end: GFXglyphDiy GFXfontDiy

It's not the most charming idea since that forces me to have a copy of the library that is exactly what I want to avoid doing. When it's fully implemented maybe the best road to take will be just to rename Adafruit GFX, or better, to let it live "as is" and make an install_epdiy.sh shell script that will rename this automatically after adding the repository with git submodule. The ideal way to link this is just to add it as a submodule in the components directory.

17.03.2021 UPDATE: https://github.com/vroland/epdiy/search?q=GFXglyph Valentin has informed me that this is already addressed. Now this structs have been renamed to EpdGlyph so it will be possible to use this component as a git submodule instead of copying it in the Repository.

Proof of concept

Flashing and rendering a Bitmap downloaded using ESP32 WiFi

Build

EPDiy that is the component to control this epaper may be not enabled by default. Check the components/CalEPD/CMakeLists file and uncomment it so it's included on the build

idf_component_register(SRCS ${srcs}      
                    REQUIRES "Adafruit-GFX"
                    REQUIRES "FT6X36-IDF"
                    # Only for parallel epapers:
                    #REQUIRES "epd_driver"

                    INCLUDE_DIRS "include"
)

Where to buy the hardware

LILYGO Aliexpress store: epapers section

T5-4.7 inch E-paper ESP32 V3 version 16MB FLASH 8MB PSRAM | 22€ (Price lookup at the time of writing this) Related product: T5-4.7 inch E-paper ESP32 V3 version Capacitive Touch Cover | 9€