Maintainer wanted

[kdschlosser]

@bdbarnett

Another issue moving forward with lv_bindings_micropython is the way display and touch drivers are handled. For instance, for the ESP32 port, Micropython moved to using ESP-IDF v5.x, while the drivers in lv_binding_micropython are written for v4.x. Due to that mismatch, the only way I can get lv_micropython (the fork, not the binding) to compile for an esp32-s3 is by removing any lines in the build files that require esp-idf. Rather than porting the old drivers to the new framework, I recommend moving away from including drivers in the binding, and instead use drivers that are are also themselves Micropython modules.

This is possible to do using the viper code emitter. The drivers were originally made before that was available so any reordering of the frame buffer that needed to be done was done in C code because of the speed it gave. Most of the drivers should be able to be easily made to run using only python code.

I have used the code generator script to add the LCD components that is built into ESPIDF. It does require some tweaks to be made to the generation script but nothing too crazy to get it running.

I recommend using the LCD component in the ESPIDF instead of writing to pin registers using viper code. I do not however recommend using the 3rd party components for the display drivers due to them needing to be added at compile time instead of runtime.

The current state of the display drivers in MicroPython could use an overhaul so the code for irrelevant drivers doesn’t get loaded and also to come up with a common API for all of the drivers. This should not be too difficult to do. I did at one point in time locate a driver set for the STM boards and I have seen a few drivers for RPI. These can be used as a guide.

I know that there was talk of writing display drivers in C and while they could technically be used the idea behind MicroPython is runtime support for devices, not compile time. So IDK if that would work if specific displays have to be picked at compile time. Where as with MicroPython the display driver that gets used is chosen at runtime. It is not that hard to write drivers for MicroPython for the ESP32. IDK how hard it would be to expose the needed C functions for RPI and for STM or any of the other boards that MicroPython supports.

It would be a nice thing to be able to select the display and also the MCU and be able to have the proper code added when using SquareLine Studio or when using the online javascript port that is used for the examples.