Board v7 testing

In this page will try to document my tests with EPDiy V7 16 bit data bus capable board (s3_lcd branch)

I currently have only a 10.1 inch e-paper display DES full color large 2232x1680, GDEW101C01

This are my settings for: src/epd_driver/board/epd_board_s3_prototype.c

    /* 16 bus_width settings */
     LcdEpdConfig_t config = {
        .pixel_clock = 6 * 1000 * 1000,
        .ckv_high_time = 30,
        .line_front_porch = 4,
        .le_high_time = 4,
        .bus_width = 16,
        .bus = lcd_config,
    };
// up to 8 MHz pixel_clock seems to work but sometimes it hangs. But please not that it is with this particular EPD GDEW101C01

Sending this buffer statistics. Note that I'm just drawing the dragon so it's not using the whole display:

epdiy: calculating diff..
epdiy: highlevel diff area: x: 0, y: 0, w: 1200, h: 825
epdiy: starting update, phases: 30
Actual draw took 2232ms.

Also this is a color epaper so it has a Color filter on top that is not being used at all. Hence we will just see a normal grayscale image, till we figure out how to add Color, as a setting in EPDiy component.

New test with full color JPG image

// NOTE: pixel_clock set to 8 Mhz
decode: 4487 ms . image decompression
www-dw: 8423 ms - download
calculating diff..
highlevel diff area: x: 0, y: 0, w: 2232, h: 1680
starting update, phases: 38 actual draw took 2801ms.
12910 ms - total time spent

About color research

In order to do add color support I will take as a master reference, the work of Wenting Zhang who worked with DES color displays, and I consider as a master professor both in Hardware and Software understanding how things work. Big hats off and respect to him and EPDiy for opening the doors to test 16-bit displays. This will open so many possibilities!

Testing displays with a color filter pattern

This is my very basic test just to see how colors are made:

/* Simple firmware for a ESP32 displaying a Color square in a DES epaper screen with CFA on top */
#include "esp_heap_caps.h"
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "epd_driver.h"
#include "epd_highlevel.h"

EpdiyHighlevelState hl;
int temperature = 25;

uint32_t get_panel_color(int x, int y) {
    uint8_t c = (x + (EPD_HEIGHT - y)) % 3;
    switch (c)
    {
    case 0:
      return 0; // R
      break;
    case 1:
      return 2; // B
      break;    
    default:
      return 1; // G
      break;
    }
}

int color_test() {
  EpdRect epd_area = {
      .x = 0,
      .y = 0,
      .width = 1000-1,
      .height = EPD_HEIGHT
  };

  uint8_t color = 0;
  /**
   * @brief PATTERN
   * pix1     2    3  X
   *    B     G    R  row:1
   *    G     R    B  row:2
   *    R     B    G  row:3
   */
  for (uint16_t y=1; y<epd_area.height; y++) {
    for (uint16_t x=1; x<epd_area.width; x++) {
      color = 0;
      // 0:R 1:G 2:B
      uint8_t getc = get_panel_color(x, y);
      if (getc == 0) {
        color = 255;
      }
      epd_draw_pixel(x, y, color, hl.front_fb);
    }
    vTaskDelay(1);
  }

  epd_poweron();
  // Color test
  
  enum EpdDrawError _err = epd_hl_update_screen(&hl, MODE_GC16, temperature);
  epd_poweroff();
  return _err;
}

Results of trying Blue and G colors on in this tweet

Additional notes on Color handling

It's really hard to drive Epapers with a color filter on top (Called CFA I think) The challenge is not only because it has a huge buffer, considering the WIDTH*HEIGHT /2 (4 bit-per-pixel) on one of this big 10.1" from Good-Display: W:2232 * H:1680/2 = 1.874.880 bytes. Almost 2 Megabytes in external PSRAM that are "diffed" from the front buffer (New image) with the back buffer (Old) and then processed to be sent via parallel. What is sent is the raw data that the panel needs and not this 4-bit pixel information.

But the additional challenge is to know on what color it lands. Send it as we do with a normal grayscale image and the Colors on top won't be really seen, you will just get a normal Grayscale image. The pattern in the color DES from Good-Display is the following:

 pix1     2    3  X
    B     G    R  row:1
    G     R    B  row:2
    R     B    G  row:3 

This is the same underlying technology as the 16 grayscale epapers already supported by this library below the color filter. Send 1,1 a value of 255 (Full WHITE background) leaving the others 0 (BLACK, won't reflect colors) then you will see a blue pixel. Send the G & R to WHITE, and B to darken, then you will get YELLOW. That's the principle.

But is not magical. Having an additional filter on top means you will never see the really white background of a classic 16 grays display. It will be always a bit grayish. It's nice but has it's drawbacks as you can see.

Now looking again at the table below, how we render an image?

As a practical example the trick to render an image is then to extract only the Blue part of pixel 1,1. The Green part of pixel 2,1 and the Red part of 3,1. This will render somehow the image you send in the right colors but you are really making a "COLOR STRIPE" from the real image, hence reducing the resolution details 3 times. In my mind this is something like: It will work, but it really needs some thinking and maybe some per-processing before sending it. This is something you can do quite easily having a Linux PowerMCU like NekoInk but it might take a precious time on a ESP32-S3. Although fast enough is not a super-computer. I guess this is one of the reasons why the projects you will see using this displays as the Reinkstone DES Color tablet have all Linux powerful multi-core CPUs.

Additional reads

C ideas to add color support

// For a certain pixel, get its color component on the EPD screen,
// return in the RSH amount to get the component
static uint32_t get_panel_color_shift(int x, int y) // Check it below:

https://github.com/zephray/NekoInk/blob/master/utils/imgview/disp.c#L333

This notes are written by EPDiy collaborator Martin Fasani.

Thanks a lot Valentin for designing and giving me the opportunity to test this awesome Hardware