willing to give a lift

[zladay]

I am into Sitronix ST7735 style (e.g. ili9341, ili9488 and the like) TFT controllers. I am also working with different TCs (STMPE811, XPT2046 etc.)
I am interested in a more ESP-IDF-ish driver infrastructure with a streamlined lvgl interface.
Willing to share ideas, designs and code examples.
Looking for some guidance since this is an empty space now.

[kisvegabor]

Hi @zladay

Glad to see that you are interested in contributing to the project. Every help is welcome! 🙂

@C47D, the maintainer of lv_port_esp32, is also into this topic.

We are still in the planning phase, finding the right API, layers, etc. Do you already have any ideas?

[C47D]

Hi @zladay,

The initial work is already done on the lv_port_esp32 repo, we will copy the lvgl_esp32_drivers directory into here, so users can use the drivers without needing to use the whole lv_port_esp32 project (we are also working on the lvgl and lv_examples repo to make them easier to use with ESP-IDF framework and other frameworks that use Kconfig).
We already have support for ILI9341, ILI9488, ILI9486, HX8357B/HX8357D, ST7789, ST7735S, SH1107, SSD1306 and IL3820 display controllers, and XPT2046, FT3236 and STMPE610 touch controllers.

Support for those drivers will be gradually added into the lvgl_drivers repo, this repo requires work.

Hopefully I can start working in this repo this weekend, I'm currently trying to fix a bug in the IL3820 display controller.

Any ideas let us know.

Regards

[zladay]

I am aware of the drivers you mention. I started working with an original version of @kisvegabor's ESP32 demo. (There was only ili9341 and xpt2046 support at that time).
I put together a completely new driver architecture initially targeting ili9341 and STPME811 only (this was the only hardware I had back then).
Design objectives included

• support for multiple device (disp, indev) instances (same or different type) for concurrent handling of multiple screens
• proper sync and thread safe operation
• layered approach (drivers do not require lvgl)
• streamlined SPI bus handling to get the most out of what ESP-IDF offers for increased efficiency
• support for multiple hardware types (tft, tc)
• device independent interface toward lvgl (lvgl does not have to 'know' the hardware type)
• flexible initialisation and configuration (nothing is decided in compilation time - no conditional compiling)
• efficient operation, low CPU and memory footprint
• generalized conversion between TFT and TC coordinate spaces
• etc.
  Most of the above goals are already met. Code is ready and tested.
  Current HW support include:
• TFT: all Sitronix style TFTs including ili9341, ili9488, st7735s (st7789 probably works, too, but not tested)
• TC: STMPE811, STMPE611, XPT2046
  I have not yet focused on adding support for the monochrome devices (e.g. SSD1306 style), however.

[kisvegabor]

@zladay
That's great!
Could you upload your code somewhere to see how it looks like?

[zladay]

Sure.
I need some time to clean it up, though.
I will link it if it is done.

[C47D]

I can upload the existing code here and you take over with your improvements, I'm sure there's a lot to be done with the existing code on the lv_port_esp32 display and touch (indev) code.

[zladay]

I have already set up a repository with my drivers. In order to demonstrate the new approach, I need to come up with a new demo program, too. I have also set up a repository for this. I have been using a pretty old version of lvgl and an lvgl example. The "Write List Chart" one. I decided to include lvgl and lv_examples as submodules in this repo. It is now done. In this process, I switched to the master branch of both of these lvgl parts. At this moment, my ancient main.c does not compile with this. I have just recently realised that my favourite "Write Chart List" is gone. I need to find another demo program. (Any suggestions?) I had to fight the build system a bit, but it works now. Nothing serious, I am on track. It has, however, delayed my attempt to clean up and reorganise the driver code. I am asking for a little patience still.
I am planning to link my repos when it is worth to show them.
Given the above circumstances, however, I am not sure if it is worth to populate this repo with the old drivers now.
At least it does not help me at this moment.

[zladay]

I have just changed the demo to lv_widgets_demo. Demo compiles and works on first try with the latest lvgl, wow. ili9341 (320x240) and xpt2046. Touch works, too. Demo and drivers are committed to the Github repos.
I can start the cleanup and reorganisation now.
I will keep you updated.

[C47D]

Hi,

For start you can only show a label in the display, once it's working we can work on showing any of the lv_example demos.

Maybe we can use your architecture as a base and add the old drivers on top of that, updating any necessary code, we have to remember this repo will be used as submodule on the lv_port_esp32 repo, what do you think? I have some drivers so we can test with them.

The lv_port_esp32 repo has three components, lvgl, lv_examples and lvgl_esp32_drivers. I'm working on separate those, currently writing the Kconfig file for LVGL.

Do you have your repos available somewhere?

OFFTPIC:
It would be nice to have a discord server about LVGL.

[C47D]

Also, are we going to compare both approaches? I haven't measured how busy the SPI master is in the current approach.

[zladay]

As I wrote earlier, the lv_example problem is solved. This widget demo is scrolling through the TFT right now. (I am missing the "Write List Chart" BTW, that looked much nicer :)
Oh yes, the repo question! I did not think it is going to be this complex when I showed up here.
@kisvegabor asked me to upload the code somewhere. This is why I had to set up a repo for the drivers. Later, I realised that the driver code can not be used in itself. It has a completely new initialisation and lvgl interfacing. I could come up with some sort of documentation to describe how it is intended to be used, but I thought it is better to show it in a working demo application. This is why I started to build it and created a separate repo for this. The demo repo is constructed in a way that it uses lvgl, lv_examples and my drivers as submodules. My drivers are organised in a separate demo as multiple ESP-IDF components (yes, not one component, but more components). You can exclude certain components from the build. If, e.g. you do not have STMPE811 in your hardware setup, you can leave the corresponding component out. The driver repo is designed in a way that it is not strongly connected to the demo app. It can be used for any application preferably as a git submodule. This is meant to contain all the code. If you want to exclude something from the build, you need to make the necessary changes in CMakeLists.txt under main. (All components are included by default).
The components in the driver repo are organised in a hierarchical manner. There are common components (e.g. SPI handling for TC aka tc_spi). These are required for all the TCs. If you want to use STMPE811 e.g., it is enough to specify that component, it will pull in dependencies automagically (e.g. tc_spi).
This driver repo can, of course, also be a part of lv_port_esp32. lv_port_esp32 (its main.c) needs to be heavily reworked in order to use this drivers, though. Until that happens, we can use the repo I put together. It is not meant to be final. I have not yet implemented all my ideas in the drivers & the demo. I have yet not touched lvgl itself yet, but I have ideas how we could make interfacing much better with that. My code is meant to be a work in progress. I do not want to break the applications of many people using the publicly available code.

[zladay]

You have a lot of questions :) I am trying to answer all, however.
Discord server (or any other real-time comms application)? I am definitely in. I have suggested this to @kisvegabor earlier.

[zladay]

"Maybe we can use your architecture as a base and add the old drivers on top of that"
This is my intention, too. Later. This time, I think, it is a bit early. As I said, I need to reorganise the code first. It does not yet fully reflect my ideas and objectives yet, not to talk about other people. Your suggestions are also welcome.
My initial plan is to support the following hardware:

• TFT: ST7735S, ILI9341, ILI9488
• TC: STMPE811, STMPE610, XPT2046
  This is what I have and, therefore, this is what I can test. I also have a couple of monochrome OLED displays, but I do not want to go into that now (sub-byte addressing of the screen buffer, no touch, meek graphical experience).
  I know that your list is longer than this. If you want to add other drivers, you are welcome. I would put the emphasis on the architecture design first, however.

[embeddedt]

Discord server (or any other real-time comms application)? I am definitely in. I have suggested this to @kisvegabor earlier.

We typically prefer to use communication mediums that can be searched more easily (i.e. GitHub issues and the forum). It helps reduce the number of duplicate questions.

EDIT: I forgot to mention that the forum actually behaves very similarly to a real-time chat system; I'm pretty sure you get notified almost instantly if browser notifications are enabled.

[zladay]

What do I mean by reorganisation?
Maybe it is news for you, but the above TFTs do not need separate drivers. Only the initialisation is different, and that difference is only one bit in the MADCTL register (RGB order).
I want to write a generic driver (not writing it actually, since any will do, of course) as a common component and a very thin specific driver for each of those.
Similarly, there is no visible difference between the STMPE811 and STMPE610. One generic driver is enough. But, just not to confuse people, there is going to be two different initialisations for it for each device.