RGBDisplay constructor no longer works

[MitchBradley]

I have some display init code that was working last month, but I tried updating to the latest commit of lvgl_micropython (4c62391) and now the RGBDisplay constructor fails. The first problem I had was the disp parameter to RBGBus, but I noticed its removal, deleted that line, and got the bus to construct.

Now I get this when constructing RGBDisplay (code attached as file)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "crowpanel7_init.py", line 67, in <module>
  File "rgb_display.py", line 38, in __init__
  File "rgb_display_framework.py", line 42, in __init__
  File "display_driver_framework.py", line 215, in __init__
  File "display_driver_framework.py", line 280, in _init_bus
SyntaxError: Cannot convert 'bound_method' to pointer!

I tried commenting out various lines in the RBGDisplay parameter list to see which is causing the problem. It seems to be related to the framebuffer1 and framebuffer2 lines. If framebuffer1 is omitted, it fails with a "can't allocate memory" error, presumably because it tries to allocate from scarce regular RAM instead of PSRAM. If framebuffer1=buf1 is present but framebuffer2 is absent, it hangs and execution does not proceed to the following code. Could changes to the bus code be causing problems?

crowpanel7_init.py.txt

[kdschlosser]

I know what is going on here. I messed up and I pushed an update to the submodules that I didn't intend to. You are going to have to give me a bit to figure out how to undo it. It's not a simple thing to undo. What I am probably going to have to do is remove the submodule and then add it again and set it to the correct commit..

[kdschlosser]

this problem should now be fixed

[MitchBradley]

It is still failing. I tried various ways of updating the submodules (after git pull), then took out the big gun and just got a fresh clone of lvgl_micropython and started from scratch. The failure syndrome is the same as above.

Here is the output of git submodule summary:

wmb@DESKTOP-6I1SH7T:/GitHub/lvgl_micropython$ git submodule status
-6ad390fc5093bcbf785b7ad103484501d11d8c2a lib/SDL
 11eaf41b37267ad7709c0899c284e3683d2f0b5e lib/esp-idf (11eaf41b)
 92d424ec7442aa7cf2ba237929c1e8ecb5d0abc3 lib/lvgl (92d424e)
 d7d77d91becd0716ac1672c92652d9dd72ec613f lib/micropython (d7d77d9)
 3cf6bf5eb16f5eadd4a058e41596145c407a79ad lib/pycparser (3cf6bf5)

Which versions should I have?

[MitchBradley]

This is probably related but I am not sure what to make of it - the file api_drivers/lvgl_api_drivers/frozen/display/display_driver_framework.py is somewhat different than the display_driver_framework.py inside the .zip archive in that same directory. The differences appear to be related to subtle differences in lvgl.

[wxzed]

@MitchBradley I encountered the same issue. Did you manage to solve it? On my side, it appears that the issue arises when invoking the callback here:

/py_api_drivers/frozen/display/display_driver_framework.py

self._disp_drv.add_event_cb(
self._on_size_change,
lv.EVENT.RESOLUTION_CHANGED, # NOQA
None
)

[kdschlosser]

I know what the issue is and I am trying to solve it. There was a change made upstream in LVGL that is causing the problem with the binding code and I had set the LVGL submodule to before that change was made and I screwed up the submodule somehow and had to redo it and for the life of me I don't remember the commit in LVGL that caused the issue.

In order to fix the problem it is going to require a lot of time because of figuring out where in the code generator script changes need to be made and the extent of the changes that are going to need to be made.

What is causing the problem is this... The code generator literally reads the header files like you or I would read them. it follows includes located in the header file it is handed so recursively it end up reading whatever header files are included in LVGL. In LVGL starting with 9.0 there has been a big push to make portions of LVGL private. This push is being made because the API is getting extremely large and when dealing with a binding where the binding code gets generated there is a very large chunk of the code that gets generated that will go unused because those portions of LVGL are only used internally. In order to correct this problem what is being done is there are forward declarations being made and the definitions mare occurring in private header files. Those private header files are not included in any public ones they are only included in the C course files. The compiler doesn't care because the header files are not what gets compiled it's the source files that are and so long as the definition occurs in a file that is being compiled it's not going to bean issue. But for the code generator it is. C code sees callback functions as pointers to a memory location. Python functions are not pointers so they need to be handled in a very specific way to make it work. In order to make it work a c function is what gets stored and that function is what handles making the call to the python function. Part of the mechanics that triggers that C function to get created is the code generator being able to look at a structure and know what the fields are. But if the definition of a structure doesn't happen inside of any public header file the code generator is not going to be able to see it. The only thing it sees is a structure but it doesn't know anything about it. So what happens is when setting a callback instead of a c function being passed to the actual LVGL function the python function gets passed and that function is not a pointer. Hence the error you are seeing.

The code in the binding generator needs to be changed in a manner so it is able to see what is in those structures but not add any binding code to access anything in the structure. That is where the complications come in because now C objects need to be tied to the header file names that they are defined in so a check can be made to see if the word "private" is in the file name so decisions are able to be made on what to do. Because of the nested mess in the way the code generator was written this is not an easy thing to solve. The code generation script is something I am frankly afraid of, LOL. Making changes to it usually cause cascading problems. It would probably be easier to write a new script then it would be to make this kind of a change to the existing one. Writing a new script is going to take time to do and if I do write a new one I am going to flatten the API so it is identical to the LVGL C API. This will reduce the memory use as well as the compiled size of the binding by a sizeable amount. changing the API is going to be like pissing in a lot of peoples cheerios which is something I don't really want to do either. Stuck between a rock and a hard place with this.

[kdschlosser]

OoOOoO I think I just found the commit it was set to before things broke..

e1c0b21b2723d391b885de4b2ee5cc997eccca91

[kdschlosser]

OK I just updated it, see if it will work now.

[wxzed]

@kdschlosser Thank you, the previous issue has been resolved, but now there's another problem. I'm using the ILI9341 display, and my build command is:
python3 make.py esp32 clean BOARD=ESP32_GENERIC_S3 BOARD_VARIANT=SPIRAM_OCT DISPLAY=ili9341 --usb-jtag --flash-size=16
However, I get the following error:
Traceback (most recent call last): File "<stdin>", line 43, in <module> File "display_driver_framework.py", line 487, in init ImportError: no module named '_ili9341_init'.
My test code is as follows:
`import lvgl as lv
import lcd_bus
import ili9341
from machine import SPI, Pin
import machine

import gc
gc.collect()

spi_bus = SPI.Bus(
host=1,
mosi=21,
miso=-1,
sck=12
)

display_bus = lcd_bus.SPIBus(
spi_bus=spi_bus,
dc=13,
cs=14,
freq=40000000,
)
print(gc.mem_free())
buf1 = display_bus.allocate_framebuffer(int(240 * 320 * 2 ), lcd_bus.MEMORY_SPIRAM)
print(gc.mem_free())
buf2 = display_bus.allocate_framebuffer(int(240 * 320 * 2 ), lcd_bus.MEMORY_SPIRAM)
#print(gc.mem_free())
print(gc.mem_free())
display = ili9341.ILI9341(
data_bus=display_bus,
frame_buffer1=buf1,
frame_buffer2=buf2,
display_width=240,
display_height=320,
reset_state=ili9341.STATE_LOW,
color_space=lv.COLOR_FORMAT.RGB565,
rgb565_byte_swap=True
)
print(gc.mem_free())

display.set_power(True)
display.init()
display.set_rotation(lv.DISPLAY_ROTATION._90)
`

[wxzed]

Got it, I'll use display.init(1).

[kdschlosser]

yeah the API has changed so that it deals with initializing displays in a dynamic manner. this keeps the amount of code that needs to be loaded as small as possible since leading a python source file takes up memory and quite a bit of it. so no use having code loaded into ram that never ends up running. some of the initialization code can be quite large for the displays.

[kdschlosser]

With the display you are using I suggest not creating any framebuffers, let the driver handle it as it will setup the buffers to give the best possible performance.

[MitchBradley]

When I tried that before it failed because you need to allocate the framebuffers in SPIRAM. The on-chip RAM is too small. The automatic allocation did not know to use SPIRAM.

[MitchBradley]

But maybe your suggestion was directed at wxzed instead of the OP

[kdschlosser]

yes it was directed at @wxzed

but it should also work for RGB displays as well. If it's not I will have a look at the code to see why it's not. How the buffer allocation works is it will try to create 2 buffers in DMA SRAM and if that fails then it will try and make 2 buffers in DMA SPIRAM and if that fails then it will try and create a single buffer in SRAM and if that fails then it will create a single buffer in SPIRAM

When using any driver except for the RGB driver it will do the math for the size of the buffer and divide it by 10. The RGB display it will allocate the buffer at the full size.

Maybe what you did was you forgot to remove the lines where you were allocating the buffers? That would cause an issue. You would need to remove those and leave out the frame buffer parameters or set them to None when constructing the driver.