Garbage appears in the horizontal direction of the widgets

General discussion
11

Hi @embeddedt,
Thank you for your suggestion. The bandwidth problem is indeed a very important clue. The current situation is not caused by bandwidth. The real reason will be discussed below.

Hi @pete-pjb,
Thank you for your attention and reply.
I have already figured out the difference between the two writing methods. For lvgl double buffer, when lvgl_flush_cb is executed, the color_p buffer should have been displayed on the LCD. But for the driver, ELCDIF_SetNextBufferAddr just notifies the LCD controller of the framebuffer, and the LCD still displays the previous one, and will not switch to the next buffer until the current render is completed . If lvgl_flush_cb returns at this time, lvgl will think that the previous framebuffer is free and draw the next picture, which will cause garbage when drawing the framebuffer being displayed.
An example may be clearer
In case 1, lvgl call RGBLCDUpdate:

  1. A buffer is rendering
  2. wait sem done, the A buffer is rendered, the LCD continues to render the next time, but the A buffer is still rendered.
  3. call ELCDIF_SetNextBufferAddr(B)
  4. At this time, the rendering is still A buffer, return to lvgl

After returning to lvgl, lvgl thinks that the B buffer should be rendered at this time, so it starts to prepare the next picture and write it to A buffer.
Therefore, the correct approach should be case 2, wait for rendering B before exiting.

Here is another set of double buffer buffer data in RGBLCDUpdate, so that LCD render and LVGL can establish the next frame synchronously, as follows:

int swiftHal_RGBLCDUpdate(void *buf, u32_t size)
{
        char *pbuf = buf[widx];
        widx = !widx;
        memcpy(pbuf, buf, size);

		DCACHE_CleanByRange((uint32_t) pbuf, size);
		k_sem_take(&rgblcd_data.sem, K_FOREVER);	
		ELCDIF_SetNextBufferAddr(rgblcd_data.elcdinfo.base, pbuf);
		s_framePending = 1；
		return 0;

}

But this will waste more memory, and memcpy will also take some time. According to the current measurement situation, lvgl is also very smooth in case 2, so I plan to keep the modification method of case 2. Thank you again for your help!

1 Like