How to call the RGB interface driver for STM32 to drive RGB screens?

[Vincent1-python]

How to call the RGB interface driver for STM32 to drive RGB screens?The code seems to be unable to use the RGB interface.

[kdschlosser]

STM32 is not supported yet by this project. I do not have the knowledge on the hardware and the STM SDK in order to write the drivers. I have been hoping that someone with the knowledge would turn up and that person would be willing to put some time in to help write the drivers. I am more than happy to handle writing the binding code if someone would write a low level C driver that is a runtime driver and not a compile time driver. The problem with all of the drivers I have found for the STM32 is they are all compile time drivers so things like the number of lanes has to be determined when the firmware is compiled and not while it is running.

[Vincent1-python]

Maybe you can refer to openmv, which has RGB interface and DSI interface. Message ID: ***@***.***>

[kdschlosser]

I just checked it out. Once again it is not written as a runtime setup. It is written as a compile time. can't get much from it. it also doesn't look like it supports DMA transfers either.

[Vincent1-python]

I don't understand why DMA is necessary. Perhaps DMA2D would be more in line with your idea, and I believe there may be corresponding information online 在 2025-02-21 01:00:11，"Kevin Schlosser" ***@***.***> 写道： I just checked it out. Once again it is not written as a runtime setup. It is written as a compile time. can't get much from it. it also doesn't look like it supports DMA transfers either. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> kdschlosser left a comment (lvgl-micropython/lvgl_micropython#299) I just checked it out. Once again it is not written as a runtime setup. It is written as a compile time. can't get much from it. it also doesn't look like it supports DMA transfers either. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[kdschlosser]

The reason why you need to use DMA memory for the RGB display is because the data that gets sent to the display needs to be continually sent in a loop. It cannot be a blocking call that is made to handle the transfer. If it was a blocking call then it would sit there and continually transfer the data. DMA memory use allows the data to be sent while the CPU is free to go and do other things. One of those other things would be updating the UI. You cannot update a buffer that is being transferred, you will end up with visual artifacts called tearing. 2 frame buffers need to be used to keep this from happening. One that is being transferred and the other is being rendered to.

If you were using an SPI display or an I8080 display you don't have this issue because the display has GRAM built into it. The Display IC is what handles continually sending the frame buffer data to the display. You only have to send the data to the display IC where it gets stored in it's internal GRAM.

[Vincent1-python]

Perhaps DMA2D can solve it, and the next step is to learn DMA2D 在 2025-02-25 14:28:20，"Kevin Schlosser" ***@***.***> 写道： The reason why you need to use DMA memory for the RGB display is because the data that gets sent to the display needs to be continually sent in a loop. It cannot be a blocking call that is made to handle the transfer. If it was a blocking call then it would sit there and continually transfer the data. DMA memory use allows the data to be sent while the CPU is free to go and do other things. One of those other things would be updating the UI. You cannot update a buffer that is being transferred, you will end up with visual artifacts called tearing. 2 frame buffers need to be used to keep this from happening. One that is being transferred and the other is being rendered to. If you were using an SPI display or an I8080 display you don't have this issue because the display has GRAM built into it. The Display IC is what handles continually sending the frame buffer data to the display. You only have to send the data to the display IC where it gets stored in it's internal GRAM. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> kdschlosser left a comment (lvgl-micropython/lvgl_micropython#299) The reason why you need to use DMA memory for the RGB display is because the data that gets sent to the display needs to be continually sent in a loop. It cannot be a blocking call that is made to handle the transfer. If it was a blocking call then it would sit there and continually transfer the data. DMA memory use allows the data to be sent while the CPU is free to go and do other things. One of those other things would be updating the UI. You cannot update a buffer that is being transferred, you will end up with visual artifacts called tearing. 2 frame buffers need to be used to keep this from happening. One that is being transferred and the other is being rendered to. If you were using an SPI display or an I8080 display you don't have this issue because the display has GRAM built into it. The Display IC is what handles continually sending the frame buffer data to the display. You only have to send the data to the display IC where it gets stored in it's internal GRAM. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Vincent1-python]

https://blog.csdn.net/a2267542848/article/details/111163633 This may help you 在 2025-02-25 14:28:20，"Kevin Schlosser" ***@***.***> 写道： The reason why you need to use DMA memory for the RGB display is because the data that gets sent to the display needs to be continually sent in a loop. It cannot be a blocking call that is made to handle the transfer. If it was a blocking call then it would sit there and continually transfer the data. DMA memory use allows the data to be sent while the CPU is free to go and do other things. One of those other things would be updating the UI. You cannot update a buffer that is being transferred, you will end up with visual artifacts called tearing. 2 frame buffers need to be used to keep this from happening. One that is being transferred and the other is being rendered to. If you were using an SPI display or an I8080 display you don't have this issue because the display has GRAM built into it. The Display IC is what handles continually sending the frame buffer data to the display. You only have to send the data to the display IC where it gets stored in it's internal GRAM. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> kdschlosser left a comment (lvgl-micropython/lvgl_micropython#299) The reason why you need to use DMA memory for the RGB display is because the data that gets sent to the display needs to be continually sent in a loop. It cannot be a blocking call that is made to handle the transfer. If it was a blocking call then it would sit there and continually transfer the data. DMA memory use allows the data to be sent while the CPU is free to go and do other things. One of those other things would be updating the UI. You cannot update a buffer that is being transferred, you will end up with visual artifacts called tearing. 2 frame buffers need to be used to keep this from happening. One that is being transferred and the other is being rendered to. If you were using an SPI display or an I8080 display you don't have this issue because the display has GRAM built into it. The Display IC is what handles continually sending the frame buffer data to the display. You only have to send the data to the display IC where it gets stored in it's internal GRAM. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Vincent1-python]

How's it going? Message ID: ***@***.***>

[kdschlosser]

??

[Vincent1-python]

Is that all right? Message ID: ***@***.***>

[kdschlosser]

I don't know the hardware to be able to make it work... I am looking for someone that does know the hardware to add the needed drivers for it.

[Vincent1-python]

Then it may be helpful for you to go to STM32 official technical support. Message ID: ***@***.***>