-
-
Notifications
You must be signed in to change notification settings - Fork 24
Parallel epapers driven by Epdiy
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.
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.
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.
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
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();
}
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.
Flashing and rendering a Bitmap downloaded using ESP32 WiFi
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"
)
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€
Revision v.1.3 | Firmware for ESP-IDF >= v. 4.3
Documentation written by Fasani Corp.
If you need test images or want to download with ESP32 a WiFi image to your Epaper I recommend testing our project CALE Screen manager to deliver fresh BMP/JPG to your WiFi displays