Just wanted to let ya know.

[kdschlosser]

Once I get the lcd_bus all ironed out in the lvgl_micropython repo I will be separating it from the repo and putting the updates into the mp_lcd_bus repository

[bdbarnett]

Awesome. I'm looking forward to it. I've been testing my code against lvgl_micropython, even when not using LVGL. It works like a champ for SPI and i80. I haven't been successful with RGB yet, but that's probably my fault. I haven't spent much time troubleshooting it.

[bdbarnett]

@kdschlosser Hey, I was thinking about the double-buffering issue with RGB bus that you mentioned. Won't you need a full-size buffer that LVGL knows nothing about to serve the same purpose as the display chip's GRAM or graphics RAM? Then add 2 buffers for LVGL as normal. The highest resolution RGB display I've seen is 1024x600, so with a full size buffer and two 1/10th size buffers at 16-bit depth, that's less that 1.5MB for the buffers. For an RGB display, it's going to need a souped up MCU with lots of external RAM, so 1.5MB doesn't seem too bad to me. The Lilygo T-RGB has 16MB PSRAM and Adafruit Qualia has 8MB PSRAM. I don't think its reasonable for the end-user or developer to expect to get by with the same two 1/10th buffers when using RGB that they would have with i80 or SPI. There is no GRAM, so it's gotta be stored somewhere.

[kdschlosser]

Double buffering allows LVGL to write to one buffer while the other is being written to the display. With the RGB driver for the ESP32 it is able to use the SPIRAM as DMA memory. This is actually a pretty crucial thing if you want a performance bump.

Now there is what is called bounce buffers that the ESP32 RGB supports. It is almost exactly like what you have mentioned where there is one larger frame buffer that the RGB bus driver handles and then there are smaller buffers, typically the side of one horizontal line of pixels that gets used to write the data to the the large frame buffer. The downside with going this route is there is no DMA memory that can be used to move the data form the small buffer to the large one. Only one small buffer is able to be used. The other thing is the buffer needs to get copied and that is a CPU intensive task. The reason why I have not implemented the bounce buffer is because of the extra CPU use and the loss of DMA. Someone that buys a high resolution RGB display and attaches it to an esp32 would be a foolish person. Not because of the memory but because of the speed not being there form the CPU. The highest resolution RGB display I would attach is an 800 x 600 and even that's pushing it. with that size display you are looking at a single buffer size of 1.44 meg, so running double buffering with DMA on an ESP32 that has 8MB of Octal SPI ram that is over clocked to 120mhz (yes you can do this) would be fine and there would be more than enough memory left over. This comes with a hitch tho, in order to keep the speeds where they need to be you don't want to be reading or writing to flash, if that is done the speed gets cut in 1/2..

[kdschlosser]

If a person ois going to use a display that has a higher resolution than 800 x 600 they need to be looking into an MIPI connection instead. It is a better bus than RGB is because an MIPI display has GRAM and it uses a lot less pins. The ESP32 doesn't support MIPI displays, STM32 does but I do not have experience with the STM32 SDK or how to go about writing a bus driver to support it.

[kdschlosser]

HEYYYYYYYYYYYYYYYY

the RGB bus driver is now functional. There is a hitch tho. LVGL with MicroPython is too slow to use only a single buffer. You MUST use 2, otherwise you get tearing. Nice thing is DMA gets used even from the SPIRAM. It looks like the I80 driver copies the buffer contents to PSRAM and then uses DMA from that. Rather odd to do. Once there is a fix in place for displaying the frame per second e can do some testing to see if there is a speed difference between double buffering and single buffering for all of the bus drivers.

But the RGB drivers are now functional... YAY!!!!

I did want to mention that every other driver I have seen that uses the RGB driver from the SDK in MicroPython uses a bytearray or something similar and passes that to the driver when flushing. There is a second buffer that is made internally in the RGB driver that you don't see. What happens is that byte array that gets passed in ends up getting copied to the buffer inside of the RGB driver. What I did actually lets the RGB driver allocate the buffers and then I go in and collect the pointers to the actual buffers stored inside the driver. I do not use their function to collect the buffer. It's a little bit more overhead to collect those pointers but it is only done when the driver first starts up and the memory allocation that occurs happens on the stack.

It's pretty nifty how I handled the buffers. See the user can optionally create the buffers and pass them to the python display driver. To keep the API consistent I have to hand back something when that is done. The actual driver doesn't start up until the init function gets called on the bus inside of the python display driver. This is how crafty I am... For the RGB bus when the user allocated the buffer I return a memory view object that only has 1 byte allocated. I also store the pointer to the memory view object in the bus. when the init method gets called for the bus driver I start the display and then I go and collect the real buffers and place them into the memory view object. so now the frame buffers that have been passed into the python display driver get updated with the real buffers before they get set to the display driver in LVGL... It's pretty sneaky how I did it because any references to the memory view object that is returned from allocating the frame buffer gets updated without the user ever knowing it has changed. If you check the length of the buffer before running the python display driver you will see it has a length of 1 and then after it will have the correct length,