Roadmap

[C47D]

The main reason for creating this repository with the driver controllers (display and indev) from lv_port_esp32 was eventually contribute the drivers to the lv_drivers repo (then we could use that repo as submodule here, and other LVGL users could use their microcontroller of choice and have many drivers already available).

In order to achieve this, we would need to abstract the microcontroller independent code, this being: the bus the microcontroller uses to send the data to the display (SPI, I2C, parallel, etc) and any other GPIO (reset and backlight control).

I personally think of the following list as the steps we need to take, not all at once nor in priority order:

• [ ] Fix the code style on the drivers, use the LVGL code style.
• [ ] Update any outdated code.
• [ ] On the meantime it might be useful to move the ESP32 specific code into a set of functions, think of static functions on the driver files, then maybe have a couple of files with all the ESP32 specific code?
• [ ] Issue #1 had a lot of great ideas on how to get the display and touch controllers into one 'box' and update them if necessary, when rotating the screen, etc.
• [ ] I think using callbacks is a way to abstract the microcontroller specific code from the drivers. Do you happen to know any other?

Other things we would like to do:

• [ ] Clean up the Kconfig files.
• [ ] Maybe structure the directories a bit better, I was thinking of rename the lvgl_tft directory to displays and have a directory per driver maybe?

@kisvegabor @embeddedt and others, any suggestions?

[kisvegabor]

The main reason for creating this repository with the driver controllers (display and indev) from lv_port_esp32 was eventually contribute the drivers to the lv_drivers repo (then we could use that repo as submodule here, and other LVGL users could use their microcontroller of choice and have many drivers already available).

I thought it's only a temporary repo, and lv_drivers could be used directly in lv_port_esp32 in the end as well. Have I missed something?

Fix the code style on the drivers, use the LVGL code style.

It seems "working" well. lv_templ.c and lv_templ.h also could be used.

On the meantime it might be useful to move the ESP32 specific code into a set of functions, think of static functions on the driver files, then maybe have a couple of files with all the ESP32 specific code?

Do you mean e.g. ESP's error handling and logging?

I think using callbacks is a way to abstract the microcontroller specific code from the drivers. Do you happen to know any other?

Another option would be #ifdef-ing platforms and use the same function names across platforms. E.g. GPIO set is called lv_gpio_set(port, id) on every ESP32, NXP, STM32 etc, but as only one platform can be "active" at a time, only one gpio_set will be active.

This "technique" can't be used with display and indev drivers though because more displays and/or input devices can be active at a time.

Maybe structure the directories a bit better, I was thinking of rename the lvgl_tft directory to displays and have a directory per driver maybe?

I agree. Added directivities for each driver makes the number of elements to the half immediately (1 directory instead of a c + h file). Besides, it makes more natural to split the drivers into multiple files as all files exist in the same older.

[C47D]

Hi,

I thought it's only a temporary repo, and lv_drivers could be used directly in lv_port_esp32 in the end as well. Have I missed something? Another option would be #ifdef-ing platforms and use the same function names across platforms. E.g. GPIO set is called lv_gpio_set(port, id) on every ESP32, NXP, STM32 etc, but as only one platform can be "active" at a time, only one gpio_set will be active.

This "technique" can't be used with display and indev drivers though because more displays and/or input devices can be active at a time.

I asked because of this, what I was thinking on is this repo provide the callbacks for ESP32 microcontrollers, and lv_drivers having no mcu-specific code. If a user wants to use another set of callbacks they can register their callbacks and not modify lv_drivers.

Do you mean e.g. ESP's error handling and logging?

Yes, and SPI, I2C, etc related code.

I agree. Added directivities for each driver makes the number of elements to the half immediately (1 directory instead of a c + h file). Besides, it makes more natural to split the drivers into multiple files as all files exist in the same older.

I think this is the "easier" thing to work on, but it will require modify the component.mk and CMakeLists.txt files.

[kisvegabor]

I asked because of this, what I was thinking on is this repo provide the callbacks for ESP32 microcontrollers, and lv_drivers having no mcu-specific code. If a user wants to use another set of callbacks they can register their callbacks and not modify lv_drivers.

IMO a larger monolithic repo would work better here even for platform-specific parts. Some reasons I see:

• It's easier for users to find everything in one place
• It's easier to maintain and keep the parts in sync
• No versioning issues between the platform package and the driver package
• Contributors are concentrated into one place

[C47D]

I will try to work on the directory restructure first, I got almost no free time because work

[kisvegabor]

Just take your time :slightly_smiling_face:

[tore-espressif]

Hello @C47D @kisvegabor

Recently a new ESP-LCD component was introduced, see here, there is a basic LVGL example in test folder.

The main idea is to provide driver for LCD SystemOnChip level and to provide modular architecture: a universal panel handle that every specific LCD driver will have to return; example for ST7789: https://github.com/espressif/esp-idf/blob/master/components/esp_lcd/include/esp_lcd_panel_vendor.h#L40

Implementing this into lvgl_esp32_drivers could bring few benefits:

1. More runtime configuration and less Kconfig -> flexible configuration
2. Multiple display support -> users are asking a lot about this
3. This repo won't have to be updated for every new ESP chip, as the chip support is taken over by esp-idf

Before I get any further, could you please have a brief look and let me know what you think?

Thanks!

[C47D]

Hi @tore-espressif , thanks for the heads up, I guess this feature is available on the latest ESP-IDF only, or it can be backported to previous versions?

This repo was meant to somewhat upstream the esp drivers into lv_drivers repo, but life happened and my free time is spare. If we can still have MCU independent drivers and use them with the new ESP-LCD component it would be great.