Tracking PR: epdiy v7 and dynamic display configuration

[vroland]

This PR tracks V7 hardware development and software updates. List of tasks:

• [x] V7 hardware prototype
• [x] V7 final hardware designed
• [x] V7 final hardware tested
• [x] Deepsleep current verified (~30uA for now, may be enhanced by isolating LCD pins)
• [x] Software support for V7 and previous versions (Currently, only V7 works with this version)
• [x] dynamic display selection

[martinberlin]

Just tested this with a V7 board and this configuration and the examples/demo program.

The beginning with the "Loading demo" scroll-bar runs fine (A bit slow but OK)

// Using EPD_LUT_1K it hangs directly at the beginning
  epd_init(&epd_board_v7, &ED097TC2, EPD_LUT_64K);
  // Set VCOM for boards that allow to set this in software (in mV).
  epd_set_vcom(1560);

Then when it's trying to load the picture it hangs with this error:

I (21791) epdiy: calculating diff..
I (22041) epdiy: highlevel diff area: x: 354, y: 25, w: 492, h: 768
I (22051) epdiy: starting update, phases: 30
W (22061) epd_lcd: draw frame draw initiated, but an error flag is set: 400

Valentin maybe there is a way to make that error numbers more verbose? Video https://github.com/vroland/epdiy/assets/2692928/494b842a-b795-45ea-a8dc-08d916502f61 -> Sorry! This video is useless in the browser. Only downloading it and playing it with VLC or similar works.

Most of the errors I'm getting are of the last type described. Like it would be some kind of memory corruption when the bus_speed is too high. Tried also to decrease bus_speed to the range 12 Mhz to 18 Mhz and now the dragon is working fine.

After playing a bit more with this I could also get the demo to work. I think this should be somehow be pre-configured for most examples to avoid the users getting frustrated with the first tries. Left my settings that are based on the ones you gave me documented in the WiKi. https://github.com/vroland/epdiy/wiki#epdiy-v7-settings

Further notes

I'm planning to do an additional pull-request once this is merge is done and fix the JPG decoding examples. They still use EPD_WIDTH / HEIGHT constants that should now be replaced by epd_width() and epd_height(). Also noticed that when including epdiy.h this way from a CPP program:

extern "C" {
  #include "epdiy.h"
}

So I fixed it declaring EpdDrawError before the highlevel API include. The s3_color_research branch is just a that, an experimental test, that I will pass to a clean PR once all examples are fixed.

[martinberlin]

@vroland with this last 2 commits we can already test this examples in IDF 4.4 / Arduino ? Will make some tests over the weekend with my 9.7" and V7 board.

[vroland]

It does compile in arduino, but for some reason I have to use much slower bus speeds for it to work consistently, probably caused by some stuff arduino is running in the background. I wasted an evening on this already, maybe I can reproduce it by compiling arduino as a component but that will take even more time... :/

[martinberlin]

@vroland it looks awesome. Tomorrow will check some of the examples with IDF 5.1 see if I can help fixing them so they pass the tests. What is the MPD status one? That I never tried. Maybe it will be nice to add a short 4 lines Readme to explain what it does.

[vroland]

It's a client for the music player daemon, to show album cover and current playlist. I added a readme :)

[martinberlin]

I've been testing the examples specially to give you a hand to fix mine, this is just that IDF v5 is picky about the integer type in any kind of logging:

/app/vroland/epdiy/examples/www-image/main/jpg-render.c:517:12: error: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'size_t' {aka 'unsigned int'} [-Werror=format=]
  517 |     printf("Free heap after buffers allocation: %" PRIu32 "\n", xPortGetFreeHeapSize());

Lange Rede kurzer Sinn :) You can just copy the fixed examples from my branch s3_color_research where they are fixed. Then I will go throw them and try them in my 9.7" epaper.

Maybe it's a good idea to add a WiKi page mentioning in a short and straight-forward way that all examples except Lilygo EPD47 are meant for a 9.7" parallel epaper and if using a different model, they have to be edited, since most people is at this point accustomed to the menuconfig option and after this is merged, that will be not any more the way to set this up. Is a breaking change, but is nicer to do it this way, and it will be also nicer to the Platformio users since they do not have to use constants anymore in their platformio.ini configuration file.

After this is fixed, only the MPD status and terminal examples should be fixed, for both IDF 4.4 and 5.

[vroland]

@martinberlin Thanks, I used the fixes and did some more (allocating a smaller buffer for the downloaded image, updating the cert).

[martinberlin]

@martinberlin Thanks, I used the fixes and did some more (allocating a smaller buffer for the downloaded image, updating the cert).

Awesome great idea to allocate the buffer using content length header! Now the www-image examples pass the tests.

[martinberlin]

@vroland just check this error for the weather example

esp32-arduino requires CONFIG_FREERTOS_HZ=1000 (currently 100)

and found this mention in the Platformio ESP32 repository Is there a specific config that should be added when using the Arduino repository?

I know that this example is quite specific and has some author references but maybe one day we should do our own weather example that is easier to setup (Out topic for the PR of course!)

Additional hint: When using idf component manager I get this warning (Testing USB D+ D- connection with tinyusb)

$ idf.py add-dependency esp_tinyusb Executing action: add-dependency Selected profile "default" from the idf_component_manager.yml config file WARNING: Unknown string field "license" in the manifest file

[martinberlin]

@vroland one additional request before merging this in master: https://github.com/vroland/epdiy/releases Maybe is wise to make another minor release? Like 1.0.2 Then if someone wants to still use older version in a firmware can just tag it like that. Otherwise we will force many Firmware developers using the component to update the integration in their code.

@mickeprag can you please also add your thoughts?

[mickeprag]

Yes, I agree to do a release before any breaking changes. Also minor fixes could later also be ported to the 1.0 branch if needed.

[vroland]

Of course, that makes a lot of sense :)

[vroland]

I'm just missing some updates to the docs and readme, then this can be merged.