Code
The code block(s) should be between ```c and ``` tags:
/*You code here*/
lv_obj_t * btn1 = lv_btn_create(lv_scr_act());
lv_obj_set_size(btn1,150,80);
lv_obj_align(btn1, LV_ALIGN_CENTER, 0, 0);
static struct display_timing st7102_timing = {
.pixelclock = 24000000,
.hactive = 480,
.hfront_porch = 40,
.hback_porch = 40,
.hsync_len = 2,
.vactive = 854,
.vfront_porch = 193,
.vback_porch = 9,
.vsync_len = 2,
};
static struct panel_rgb rgb = {
.mode = AIC_RGB_MODE,
.format = PRGB_24BIT,
.clock_phase = AIC_RGB_CLK_CTL,
.data_order = GRB,
.data_mirror = AIC_RGB_DATA_MIRROR,
};
Screenshot and/or video
If possible, add screenshots and/or videos about the current state.
May I ask what possible reasons may have caused this phenomenon? My configuration is RGB888 with a screen size of 480x854, which can display a solid color background normally
you are using an RGB panel which means there is no internal GRAM for the display so you MCU is going to have to update the display as fast as it can over and over again so if you only use a single frame buffer to render to then you will end up with tearing. in order to use 2 frame buffers you either have to allocate the buffers in DMA memory or you have to use an MCU that has 2 processor cores, one for transmitting one buffer while LVGL is able to render to the other.
Plus testing with one solid color is absurd, you see nothing…
Try give nfo abut MCU…
I’m still a newbie and don’t quite understand, thank you for your answer. I have a general understanding now! Another question I would like to ask you is, even if I enable DMA for double buffering, would it still cause this situation if there is not enough memory?
If there is no enough memory for the 2 frame buffers you will know it because the second buffer you try and allocate will end up being NULL. do a simple equality test to NULL to see if the buffer is actually getting allocated…
It would help if I know what the brand and model is of the MCU you are using. If you are using a premade display board that has the MCU attached then providing the manufacturer and model of the board is what I would need.
My MCU is DX21, and the specific information is as follows: 产品简介 — 智显文档中心 v1.0 文档
My configuration is 4MB PSRAM, 16MB NOR Flash
what is the resolution and color depth of the display you are using?
It would be 24 bit color because that is what the display is able to display. Most displays don’t work with alpha channels unless the display has some kind of a built in IC that handles writing the data to the display. RGB displays don’t have that kind of thing typically built into them…
Typically if you have 25 data wires connected fomr the MCU to the display then it would be RGB888 or 24 bit color. If you have 16 data lines connected to the display you would typically use RGB565 or 16 bit color. You can use 24 bit color with 16 data lines but it is not done all that often because of the loss of the data lines causing a reduction in how fast the data is going to be able to be transferred to the display.
so lets do some math…
450 * 854 * 3 = 1,152,900
That is how many bytes of RAM would be needed to support a single frame buffer. You would need twice that number to support 2 frame buffers. If using 2 frame buffers you are going to want twice that number in DMA memory. You need to check and see how much DMA memory is available on your MCU. Some MCU’s support doing DMA from PSRAM and some only support it from SRAM. Depending on how the PSRAM is connected to the MCU it could end up being a bottleneck if the display is able to receive the data faster than the MCU is able to send it due to a limitation that is caused by reading and writing to the PSRAM at the same time which would occur when transmitting one frame buffer and rending to the other. If that occurs you would need to reduce the clock speed of the transmit to a level where everything works properly.
You are going to need to look over the SDK for your MCU and also look through the documentation to see if DMA memory is available on PSRAM and if so how much is available and you will also want to know what the connection type, number of lanes and the speed of the connection to that PSRAM. I did not see that information when I gave some areas of the documentation a quick look. It should be in there somewhere I am sure.
I did see that there are drivers written for RGB display hardware. That is a nice thing to have. You will need to look at that driver to see if it supports sending the data from DMA memory. If it doesn’t then you would need to write a driver that is capable of doing that. I know the MCU does supports DMA transfers but from one area that I skimmed over it seemed like it might only be available for SPI, I2C, I2S, CAN, UART but not for a display. It doesn’t specifically state that it does or that it doesn’t which is why you would need to look at the driver.
Thank you very much for your answer! I have contacted the chip manufacturer, and their conclusion is that "currently, the LVGL application layer display only supports displays up to 32-bit depth and 16 bit depth, and the corresponding calculation is resolution * 4 * (16 bit * 2 32-bit * 4). If the rotation function is turned on, it will consume more memory
You are using an old version of LVGL. I am not familiar with how that version works concerning the frame buffers. I do know that with version 9.x if you were writing to the display using 25 lanes you would want to use a 3 byte per pixel buffer and if you were using a 16 lane connection to the display you would want to use a 2 byte per pixel buffer.
Sorry , but DX21 is nothing on provided link. When you use M3C/M3A = MCU is RISC-V, seems without SRAM. Not very optimal for GUI app, but doable.
As @kdschlosser write , here func is basic match = refresh you display smooth require optiml 60 frames per secod = 60x480x854x3 (or 2 for 16 bit)
bytes from memory speed minimum. For SPIRAM this result to 590MBitPS.
Then four bit spiram require clocking on over 100MHz …
My chip uses a 4M PSRAM chip, and my channel is RGB888. To display normal colors, I need to select 32-bit color depth in lvgl