search

lvgl / lvgl_esp32_drivers

Drivers for ESP32 to be used with LVGL
MIT License
330 stars 281 forks source link

Initial changes to support ESP-IDF v5.0.0 #184

Closed rashedtalukder closed 2 years ago

rashedtalukder commented 2 years ago

ESP-IDF v5.0.0 incorporates a major update to the real-time kernel and number of other changes. This is my quick stab at adding support for the new toolchain version before the official release. Tested on the M5Stack Core2 for AWS IoT EduKit and works great.

There are memory and performance advantages to using pdMS_TO_TICKS instead of portTICK_PERIOD_MS or the deprecated portTICK_RATE_MS macros. That's why you'll see mostly universal changes that switches to that.

C47D commented 2 years ago

Hi, changes look OK, the only 'issue' I see are the rom gpio includes, they were removed in the develop branch. I will try to patch develop with the other ones.

rashedtalukder commented 2 years ago

Looks like you have to include the target specific ROM libraries as per: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides/system.html

It threw an undefined error without it.

Rashed Talukder

On Feb 21, 2022, at 5:45 PM, Carlos Diaz @.***> wrote:

 Hi, changes look OK, the only 'issue' I see are the rom gpio includes, they were removed in the develop branch. I will try to patch develop with the other ones.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.

ropg commented 2 years ago

I haven't had time to look at ESP-IDF 5. Wouldn't these changes break under IDF 4? Maybe it would be best to create our own macro and use #IFDEF to interpret differently based on ESP-IDP version?

rashedtalukder commented 2 years ago

I haven't had time to look at ESP-IDF 5. Wouldn't these changes break under IDF 4? Maybe it would be best to create our own macro and use #IFDEF to interpret differently based on ESP-IDP version?

These are backwards compatible changes. I tested down to IDF 4.2.1 and had no issue. The one header include that is only available in v5+ has a #IFDEF to prevent breakage: https://github.com/lvgl/lvgl_esp32_drivers/blob/a75abc016e99bf757212cf31de4ecc9645ad9abe/lvgl_tft/esp_lcd_backlight.c#L17

tsctrl commented 2 years ago

These are backwards compatible changes. I tested down to IDF 4.2.1 and had no issue. The one header include that is only available in v5+ has a #IFDEF to prevent breakage:

it is not compatible, i use release v4.4.0, build failed and lots of files and declaration are missing which only available in v5.

rashedtalukder commented 2 years ago

These are backwards compatible changes. I tested down to IDF 4.2.1 and had no issue. The one header include that is only available in v5+ has a #IFDEF to prevent breakage:

it is not compatible, i use release v4.4.0, build failed and lots of files and declaration are missing which only available in v5.

What were your errors?

tsctrl commented 2 years ago

mostly on spi access function. probably c linkage or compiler causing the issue. it is working after switching branch. i am not able to reproduce the issue now. will try again later.

edit: probably user have to add v5 support to their local idf installation to make it work with v4. that what i did that solve the build issue.

thanks!

rashedtalukder commented 2 years ago

You might be seeing the effects of there being different branches that have different commits. I couldn't get the Master branch to work without other changes that were done in the develop branch.

Glad this PR does not have changes that result in errors for you though.

rashedtalukder commented 2 years ago

@tsctrl, I also pushed the changes to my fork's develop branch https://github.com/rashedtalukder/lvgl_esp32_drivers/commit/44342b653f4111cb5340a93338b553f120898809 which should be better for a future merge since it seems that the develop branch is most up to date.

@tore-espressif @C47D if you'd like me to submit a new PR for the develop branch and close this one, let me know.

C47D commented 2 years ago

Hi @rashedtalukder, I think that a PR against develop is preferred. Sorry for not following along the discussion, I've been somewhat busy with other stuff.

rashedtalukder commented 2 years ago

Closing to open a new PR on the develop branch instead.