I’ve managed to get LVGL v 7.8.1 working but the frame rate is really slow at about 15 FPS.
In ex_disp_flush() it is drawing one pixel at a time in a loop.
I’ve tried to use the DMA function from the F746 example but it is not working on the H743 as it give a hard fault. I think the settings are quite different but I can not work out what.
Are there any example driver with DMA for use with the STM32H743 ?
I own a OpenH7XX board, and running lvgl on it is no problem.
I think there is no real difference between the different STM32F families in relation of using lvgl.
Maybe more a misinterpretation of FPS which is shown within the display when you set LV_USE_PERF_MONITOR to 1 witin lv_conf.h?
Setting the framerate is done with the setting of LV_DISP_DEF_REFR_PERIOD within lv_conf.h
So if you set 20 (ms) you get 50 FPS, with 30 (ms) you get 33 FPS.
The % CPU is calculated as the number of ticks (1 ms) which the function (‘task’) _lv_disp_refr_task needs for doing the drawing.
FPS is of course going down if _lv_disp_refr_task take more than 100% of CPU time. This indeed can be caused by a slow flush_cb function.
My flush_cb is also a simple (two, to be honest) loop. I do not use DMA2D because I need a rotation of the display for which I can’t use the DMA2D.
So the question is, when do you see the FPS of 15? Always? Means there is not really something to redraw (means also CPU is 0%)? Or under heavy redraw action (when CPU is getting high)?
Are you using a single buffer?
Maybe you can show your initialization? The part where you call lv_disp_buf_init.
Of course the ex_disp_flush can be written to use the DMA2D.
You also could try to write your own DrawPixel function. One which uses fixed framebuffer addess and fixed display sizes to avoid calling subfunctions.
But I don’t think, that’s the problem here.
I tried the lv_demo_music with my board.
Framerate is 33 FPS as expected. Of course can go down on start of animation.
I just see some strange artifacts on the screen. Seems to be that something isn’t really properly scaled up
to my 800 x 480 resolution.
/* LittlevGL requires a buffer where it draws the objects. The buffer's has to be greater than 1 display row*/
static lv_disp_buf_t disp_buf_2;
static lv_color_t buf2_1[LV_HOR_RES_MAX * 40]; /*A buffer for 10 rows*/
static lv_color_t buf2_2[LV_HOR_RES_MAX * 40]; /*An other buffer for 10 rows*/
lv_disp_buf_init(&disp_buf_2, buf2_1, buf2_2, LV_HOR_RES_MAX * 40); /*Initialize the display buffer*/
/*-----------------------------------
* Register the display in LittlevGL
*----------------------------------*/
/*Set the resolution of the display*/
display_drv.hor_res = 800;
display_drv.ver_res = 480;
/*Used to copy the buffer's content to the display*/
display_drv.flush_cb = ex_disp_flush;
/*Set a display buffer*/
display_drv.buffer = &disp_buf_2;
/*Finally register the driver*/
lv_disp_drv_register(&display_drv);
How are you initialising LVGL ?
I am also using a 800 x 480 4.5" LCD. I don’t see any artefacts.
Using two buffers is meant for double buffering, and in this case you need two buffers which can hold the full frame.
I’m not sure, but I think double buffering is not really working good. Sometimes lvgl makes full copy of one frame buffer to the second, and then the real drawing takes place. The full buffer copying will take ‘a lot’ of time. Which is in addition to the normal drawing. Maybe this is the reason for lower FPS.