Draft support for M5PaperS3

[jslawek]

Hi,
M5Stack has just released M5PaperS3: https://shop.m5stack.com/products/m5papers3-esp32s3-development-kit. Schematics: https://m5stack.oss-cn-shenzhen.aliyuncs.com/resource/docs/products/core/PaperS3/sch_papers3_V1.0.pdf.
It is based on ED047TC2 directly wired to ESP32S3.

I created a new board definition based on their implementation (M5GFX): https://github.com/m5stack/M5GFX/blob/master/src/M5GFX.cpp.

It works for me, but there are "ghost" afterimages - as visible in the "demo" example application below:

Please let me know if I can try anything to fix it.

[martinberlin]

Looks very good for me. There can be always ghost here and there specially if the gray matrix (waveform) is not the one for this display. But even if it's the good one sometimes making multiple partial refreshes leaves some ghosting.
Sadly I do not have the hardware to test this. Thanks a lot for your contribution!

[jslawek]

Thanks. The ghosts disappear after I do epd_fullclear(). But I noticed another issue: when I draw black on white (the whole screen MODE_GC16, not partial refresh), the single black elements have bright white lines background, while the padding in between is kind of grey. I suppose the blank lines are omitted (difference lookup optimizations?). Is it also caused by the imperfect waveform? M5 use ED047TC2 in their implementation. I tried also ED047TC1 but then everything is greyed out. But maybe as a workaround there is a way to force drawing also the lines which normally would be omitted? Or some other trick?

[vroland]

This looks more like a slightly wrong VCOM value rather than waveform. Do they change if you turn them up or down a bit?

[vroland]

I also see that poweron / off only drives display lines, do they just control the power through these control lines or is the display always powered?

[jslawek]

This looks more like a slightly wrong VCOM value rather than waveform. Do they change if you turn them up or down a bit?

Thank you for the response. Not sure what you mean by "turn them up or down". If you meant the position of text on the screen, I wrote a simple code to test it, and I don't see any difference regardless of how I set start_x and start_y:

    const EpdFont* font = &FiraSans_20;
    char text[64];

    epd_init(&epd_board_m5papers3, &ED047TC2, EPD_LUT_64K);
    epd_hl = epd_hl_init(EPD_BUILTIN_WAVEFORM);
    epd_set_rotation(EPD_ROT_LANDSCAPE);
    uint8_t* fb = epd_hl_get_framebuffer(&epd_hl);
    int temperature = 21;

    epd_poweron();
    epd_clear();
    vTaskDelay(500 / portTICK_PERIOD_MS);
    epd_clear();
    epd_poweroff();

    int start_x = 20;
    int start_y = 20;

    // draw a line along the text
    epd_draw_vline(start_x, start_y, 100, 0x00, fb);

    int font_cursor_x = start_x + 50;
    int font_cursor_y = start_y + 50;

    EpdFontProperties font_props = epd_font_properties_default();
    font_props.flags = EPD_DRAW_ALIGN_LEFT;
    sprintf(text, "Testing 1 2 3 ... x: %d, y: %d", start_x, start_y);

    epd_write_string(font, text, &font_cursor_x, &font_cursor_y, fb, &font_props);

    epd_poweron();
    checkError(epd_hl_update_screen(&epd_hl, MODE_GC16, temperature));
    epd_poweroff();

If you meant to change the VCOM up and down - I'm not sure it is possible with this board. It is sealed and I can't get inside. And M5 did not implement setting vcom in their software. But maybe there is something possible based on the schematics ?

I also see that poweron / off only drives display lines, do they just control the power through these control lines or is the display always powered?

I'm not sure if I get the schematics right, but it seems the lines are drawn separately.

The epd_board_poweron enables EPD_EN, BST_EN and EPD_SPV:

    gpio_set_level(EPD_EN, 1);
    vTaskDelay(1 / portTICK_PERIOD_MS);
    gpio_set_level(BST_EN, 1);
    vTaskDelay(1 / portTICK_PERIOD_MS);
    gpio_set_level(EPD_SPV, 1);
    gpio_set_level(EPD_SPV, 1);

Oh, wait, my typo, there shouldn't be twice EPD_SPV but rather gpio_set_level(STH,1); in the last line (but it does not seem to change anything for the display anyway).

For some reason though, in epd_board_poweroff they commented out the first two and turned off only EPD_SPV and I simply followed their implementation.
I also tried to uncomment these lines in my epd_board_poweroff, but it did not make any difference:

  gpio_set_level(BST_EN,0);
  vTaskDelay(1 / portTICK_PERIOD_MS);
  gpio_set_level(EPD_EN,0);
  vTaskDelay(1 / portTICK_PERIOD_MS);
  gpio_set_level(EPD_SPV,0);

Please let me know if I can try anything else.

[martinberlin]

Hello @jslawek
please check also the C-lang format check below, just check ESP-IDF / format-check (pull_request) :

./src/board/epd_board_m5papers3.c:133:26: error: code should be clang-formatted [-Wclang-format-violations]
gpio_set_level(EPD_SPV,0);

I really don't have a clue why is like this but sadly don't want also to collect more Eink devices. Soon if my new board "v7 raw" works I will finally have a PCB to test this same display.

[jslawek]

OK @martinberlin, done, by the way fixed a typo and uncommented poweroff to the BST_EN and EPD_EN

[felmue]

Hi guys

I measure about -2.2 V on VCOM on my M5Paper. VCOM is generated from EPD_VNEG through a fixed voltage divider R37/R38.

Thanks
Felix

[jslawek]

I measure about -2.2 V on VCOM on my M5Paper. VCOM is generated from EPD_VNEG through a fixed voltage divider R37/R38.

Thanks for the report @felmue.
Would you be able to try my test code from above (just paste it in examples/demo or whatever) and check if you have the same effect of lighter and dimmer stripes on the screen? Just wanted to rule out the possibility that my device is faulty - I have only a single one so cannot confirm this.

[felmue]

Hello @jslawek

sorry, I need some additional info to build successfully. Using the latest ESP-IDF (e.g. v5.4) I get an error building examples/demo for target esp32s3.

/home/fm/esp/epdiy/src/output_lcd/lcd_driver.c:181:53: error: 'const struct <anonymous>' has no member named 'module'
  181 |     periph_module_reset(rmt_periph_signals.groups[0].module);

Below are my steps:

mkdir esp
cd esp
git clone -b v5.4 --recursive https://github.com/espressif/esp-idf.git
cd esp-idf
./install.sh
. ./export.sh
cd ..
git clone --recursive https://github.com/jslawek/epdiy.git
cd epdiy/examples/demo/
idf.py set-target esp32s3
idf.py build

Thanks
Felix

[jslawek]

Hi @felmue,

sorry, I need some additional info to build successfully. Using the latest ESP-IDF (e.g. v5.4) I get an error building examples/demo for target esp32s3.

thanks for trying.
It seems you have just found an issue with EPDIY: for some reason the lcd driver does not compile with the latest esp-idf. I just confirmed your observation with esp-idf version 5.4 as well as 5.3.2: I get the same compilation error as you. It works for me correctly in version 5.3.1. They must have changed something in the internal APIs in the meantime, in the v5.3.2 release information they do mention some changes in LCD and RMT. I think this deserves submitting a separate issue as it is beyond the scope of this pull request.

[felmue]

Hello @jslawek

I managed to build and run your code with an earlier esp-idf version (release/v4.4) and I can confirm that I get the same result on my M5PaperS3 as you posted. So I guess there is nothing wrong with your device.

Thanks
Felix

[vroland]

Good to know about the IDF issue. I hope I can look into it on the weekend!

[martinberlin]

Is really annoying that the Espressif team has to change on every little upgrade from version 5 the LCD and RMT functions. At the end the code will need to have a lof of if def preprocessor conditionals on those peripherals

[vroland]

I started working on a fix #401 , but for some reason I still get compile failures in CI that I don't get locally... it's strange. I'll need to continue another time :)