[RFC] ESP32 port repo, improvement suggestions

General discussion
1

Hi,

The lv_port_esp32 repository has been growing the last months with several contributions from the community in general, while being an example project and not a fit for all use cases we are always trying to:

  • Improve the code base, documenting and cleaning up the code, so it’s easier for new users to contribute support for their particular display and touch drivers if they want to.
  • Ease the configuration of LVGL and LVGL examples using the menuconfig from the ESP-IDF framework.
  • Trying to fix bugs/issues as soon as possible, sometimes this is not possible because we don’t have the displays available, so we rely on user feedback.

With the release of LVGL v7 the repository had several changes, and we would like to get user feedback on a particular change that we are considering and wasn’t included in the last update.

The current lv_port_esp32 project include a “component” (in the ESP32-IDF lingo), this component includes LVGL, lv_examples and lv_esp32_drivers. The particular change we are trying to implement is to separate this into three different components. To avoid duplication of work this change would require us to add the CMakeLists.txt and Kconfig (and a proposed lv_conf_kconfig_template.h) files into the main LVGL and lv_examples repositories, this files will be only used by the ESP-IDF framework and don’t interfere in other uses.
The Kconfig files in particular will be helpful for other frameworks that work with this file for project configuration. The lv_conf_kconfig_template.h is a custom lv_conf_template.h file with the symbols/options available on the Kconfig file.

With this change the users would be able to include just the component they want to their project without needing to include the whole lv_esp32_port project, while keeping the options of update, open issues and PR to the “components”.

So this Request For Comments (RFC) is to ask for your thoughts about this change, this will begin as a proof of concept and if it is successful will be merged into the main LVGL and lv_example repos.

Regards.

2

I’d like to support this idea. In my (RepPanel) project I could use the drivers component only. That way a new version of the ESP32 port will no longer (possibly) break my build and I can update the submodule for the drivers only fix bugs etc…
Drivers are generally also not dependant on any LVGL implementation. This means maintaining a legacy LVGL v6 project gets easier since I can always get the newest driver updates without having to update the entire component that might be including a possible V7 implementation/port (thus breaking my build).

3

I like the idea.

Besides the advantages you listed it’d join the developers of lvgl and esp repos.

It seems the lvgl and lv_examples could easily work this way, but lv_drivers would require a significant rework. We need to find a suitable architecture to support various platforms (not only esp) and hardwares. The current drivers in lv_drivers (expect the PC related ones) are not really maintained so some of them can be dropped if they cause trouble.

We can create a branch in lv_examples for the changes and replace master with it when it’s ready.

4

Hi,

Last week I took a look into the lv_drivers repo and tried to add support for the displays available on the ESP32 repo but was facing some issues, the hardware dependent functions are added to a header file, my opinion is that it would be useful to use function callbacks and group them on a struct, something like this (just thinking out loud):

typedef struct {
     uint32_t (*send_buffer)(void *buffer, size_t buffer_len);
     bool (*spi_cs_write)(uint8_t value);
     /* etc */
} lv_display_driver_spi_vt_t;

And then the display driver can be initialized with:

 lv_display_driver_spi_vt_t ili9341_driver = {
.send_buffer = ili9341_send_buffer,
.spi_cs_write = ili9341_cs,
};

We could even define some macros so the end users doesn’t need to do this.

 lv_display_driver_spi_vt_t ili9341_driver = DISPLAY_DRIVER_ILI9341_INIT_DEFAULT();

The problem I haven’t think about is when using multiple displays on the application, the current implementation supports only one display, isn’t?

@kisvegabor On the mean time could we create a temporary lv_esp32_drivers repo?

5

Hi,

I agree to pack the descriptors in a struct. What does _vt_ mean?

Can we create a branch instead?

6

vt means virtual table, see: https://lwn.net/Articles/444910/

I don’t think a branch will work, there’s a lot of esp32 specific code on the lvgl_esp32_drivers directory and getting lv_drivers ready would be a big task.

7

So the initial goal is to separate the esp drivers from lv_port_esp32 to get a standalone component and integrate it into lv_drivers later?

8

Hi,

Yes, separating lvgl_esp32_drivers from the main esp32 is like an intermediate step towards having all in lv_drivers.

On the other hand, I have started working on adding a Kconfig to LVGL, I’m about 50% done with it. Some options will not be possible to add to Kconfig. I will let yall know when it’s done, I hope to finish it this weekend.

9

It also would be great to have some sort of CI on the repo, I’m doing some research about it, I’ve used Gitlab CI before but never Github actions.

My work station takes about 15 mins to compile a project from scratch, that’s why it would be great to have some CI, at least to discover commits that break the project.

10

I’ve created the repo and sent an invitation to you.

The lvgl repo uses GitHub CI and I thought it’s a kind of “Actions”. See here.

I don’t see any problem with setting up CI for the drivers repo too.

11

Hey guys, just throwing my two cents out there that I’ve set up jenkins servers for CI on several different projects with different languages. Fast, free. If you guys would wanna head that way let me know and I’ll help. But I’ve never really heard anything bad about GH’s CI, although that could be lack of research.

1 Like
12

Hi @kisvegabor and @jhubbardsf,

I have worked with Travis a bit on the Circuitpython project, but that is about it, so it’s also an opportunity to lean :slight_smile:.

Here’s a list of what I think the CI should do on the lv_port_esp32, suggestions are always welcomed:

  1. Setup the OS.
  2. Download and install ESP-IDF, I’m testing with v4.1, but it would be nice to test with the latest v3 aswell, so we can test building the projects with make and idf.py.
  3. Clone the lv_port_esp32 repo.
  4. Have some preconfigured sdkconfig files, I was thinking on having one for each preconfigured kit, I’ve seen people naming the sdkconfig files as follow: sdkconfig.m5stack, sdkconfig.wrover-kit, etc.
  5. Cleanup the repo (idf.py fullclean).
  6. Rename one of the preconfigured files sdkconfig.m5stack to sdkconfig.
  7. Build the project.
  8. Go to 4 and repeat for each preconfigured file.

I think we should be able to do this in a local script, once it’s working we should be able to make it work on any CI. My opinion is to give GitHub actions a try because they are already available for us, but we can also test Jenkings.

What do you think?

Great, thanks, I will work on it tonight.

13

I agree with the list.

So in the end lvgl and lv_examples will be directly available as ESP components. I don’t know if it’s possible to trigger ESP tests if lvgl or lv_examples is updated. (Just to be sure we don’t break anything)

BTW, what should we do with lv_port_esp32 repo finally?

14

I would keep the lv_port_esp32 repo as a project example, I didn’t meant to remove it.

Edit
I’m trying to fix a bug on the IL3820 driver, once solved I will start working on the lvgl_esp32_drivers repo.

1 Like