Tracking PR: epdiy v7 and dynamic display configuration

[vroland]

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

• V7 hardware prototype
• V7 final hardware designed
• V7 final hardware tested
• Deepsleep current verified (~30uA for now, may be enhanced by isolating LCD pins)
• Software support for V7 and previous versions (Currently, only V7 works with this version)
• 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 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]

Awesome job!

[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.