I am pretty new to LVGL but it came as the standard supported GUI toolkit for the NXP device I am working on. However, in the NXP example code, they have some custom drivers for the IL9341 display controller and the FT6x06 touch controller. This is fine for example code but I would like to build up my project using the actual lvgl and lv_drivers code line (MCUExpresso just lumps them in as part of their SDK). Looks like they are already supported in the lv_port_esp32 repository but not in the main lv_drivers one. Are there any plans to merge those components into lv_drivers? If not I would be happy to do it myself, just donāt want to duplicate work in case its already in progress.
Iām one of the lv_port_esp32 maintainers, there are plans to do it, but we havenāt come up with a roadmap or any todo list.
Any thoughts @kisvegabor.
@Carlos_Diaz would you be open to working on the roadmap and todo list together? I can start taking a look at the existing driver in the lv_port_esp32 and compare it to what Freescale has done so I can get an idea of the differences and any gotchas we might run into.
We can, hereās a repo (lvgl_esp32_drivers) where we were trying to decouple the drivers from the ESP32 Demo project. The drivers architecture is being rewritten but focused on the ESP32 microcontroller, I think we can get some ideas from there to make the drivers MCU agnostic and land the new architecture on the lv_drivers repository instead (that was the end goal of that repo).
But Iām only a maintainer, I would like to include @kisvegabor or @embeddedt (and everybody who wants to help) in the roadmap.
We can start some brainstorming in here if you agree.
As @Carlos_Diaz mentioned we started to work on rewriting the drivers and make the platform reusable in a platform agnostic way.
Thank you for offering your contribution. Regarding the roadmap we are still sitting on the first stage: find a suitable architecture to manage platform independence. Once itās ready Iām sure we can reuse a lot from the current drivers.
I am the one who came up with a new set of lvgl display and input device (TC) drivers together with a completely new driver architecture.
If you are interested in the details, you can find it here.
I am, however, not sure if I understand your problem.
If you have working drivers for both the display and TC, why do you need new drivers?
I was trying to check the drivers you are referring to, but the information you gave is not enough to identify yours.
Without looking at the code of your drivers, I am not in a position to make a comparison between mine and yours. Without it, I am not able to tell you if you benefited from my drivers at all.
Could you give me a link to your code or at least a demo application that uses the drivers you mention?
The drivers I have are provided by NXP. They are not part of the lv_drivers repo and are in fact lv_drivers is not even used by their tools. For me having the drivers supported in the lv_drivers seemed like the ābetterā way to both support maintainability for my client and also to support the lvgl community.
Drivers for the same 2 devices also exist in the ESP32 repo of LVGL. So since those are likely better supported than the ones from NXP, I figured it would be easiest if we made those work compatible with the lv_drivers framework.
At the end of the day all I am really looking for is to support for the IL9341 and FT6x06 as part of lv_drivers. How we accomplish that is up to you. Iām just open to help.
A significant portion of display and TC drivers are platform specific. This mainly applies to the transport (e.g. SPI) part.
ESP-IDF has a very sophisticated API for SPI handling. Its related capabilities are heavily utilized in my drivers in order to make it very efficient.
Because of this, taking it over to LPCXpresso might not be very straightforward.
As I said before, ādrivers I have are provided by NXPā is just not enough information for me to identify what you are specifically referring to.
In order for me to assess the possibility and the efforts needed to make āthose work compatible with the lv_drivers frameworkā, I would need to have a look at the specific driver code.
Can you give a link to a project where the code of those NXP provided drivers can be examined?
Iām porting the ILI9341 driver to use a PSoC microcontroller, I had to identify the MCU-specific code, like:
Code to control the DC, RESET, BACKLIGHT pins.
Transfer data via SPI (aka transport interface) with blocking (for display controller register configuration) and with an āasyncā approach (aka DMA).
and change it from ESP32 to PSoC specific code, so I think we maybe can change the MCU-specific code with user provided callbacks.
The issue is: How can we access to those callbacks (in the flush function in example)?
Iām now thinking on using the lv_disp_drv_user_data_t user_data field of the lv_disp_drv_t, but that would end up forcing the users to use that field for display control and not their purposes only.
I really liked how @zladay built the new architecture for the ESP32 microcontroller, we should take their work into consideration.