Stm32f469 screen refresh rate

How-to
#1

Hi,
I am working on f469 ported example of @kisvegabor to understand that the library is suitable for our requirements or not. Also, in addition to, I am trying to learn how the objects can be used.

I have realized that the screen refresh rate is diagonal. But there is a little latency on the refresh rate. so, I want to speed up the screen refresh rate or change the partial refresh of the screen to whole refresh. is that possible or what do you suggest to decrease the effect of this problem.

you can find some pictures below that I captured with camera about the problem which I have mentioned above.

Capture Capture_2 Capture3

BR,

#2

Have you enabled the GPU in lv_conf.h? That might speed things up.

#3

Yes, LV_USE_GPU and TFT_USE_GPU are enable.

Already, If these parameters are disable, the speed is too slower.

#4

I guess, the problem may be in double buffer mode or buffer size but i am not sure.

#5

If it’s too slow without GPU that indicates that there is an underlying problem with the driver somewhere. I’m pretty sure an STM32F469 should be able to handle that rendering load without sluggishness.

#6

Actually it is not too slow, there is only diagonal screen refresh. You can find the video below.

#7

make sure to use double buffer, and make sure they are large enough.
And remember to use DMA to transmit data to the screen.

l wonder if you can set the screen size to 240*240？ may be in this way you can find the problem

#8

This shouldn’t be necessary for good speed on an STM32F469 if nothing else is running.

#9

I have reviewed your code.

image
image.png753×233 5.44 KB

You are using only one buffer.
Add buf2 and have a try!
/*Initialize disp_buf with the buffer(s) /
lv_disp_buf_init(&disp_buf, buf_1, buf_2, MY_DISP_HOR_RES10)

#10

@muratze Could you share a video with real speed?

#11

Actually I have tried 2 buffer with like this;

image

But I am not sure the size of the buffer and size_in_px_cnt parameter of the lv_disp_buf_init.

#12

If you use RGB565, the pixel count would be buffer/2. I think manual doc explained the meaning of this API.

#13

Here you can find the video with real speed;

#14

:rofl::rofl:

I am here in China. We can’t use google… yet.
By the way, what is google? :sleeping::sleeping:

#15

For the video it seems FPS is great but diagonal shapes are there sometimes.
Probably it’s a VSYNC issue. You should synchronize the frame buffer writing with the VSYNC signal. IIRC STM has an interrupt for it.

#16

Ok, I have added to onedrive. Here you can find the real speed video. As you can see, upper side of the list, diagonal screen refresh is more noticeable.

https://1drv.ms/v/s!Aj3RP_6tqlVwjXUssdBscSAleGcp

#17

Maybe you are right because your library works fine on F429. But I dont know how can I sync the vsync and buffer writing.

You can find a video again, now with demo app. Attention for the diagonal refresh please.

https://1drv.ms/v/s!Aj3RP_6tqlVwjXdYaW04bMsK112n?e=cgsZtp

#18

We can’t use onedrive either…

As @kisvegabor suggested , you can refresh data when TE triggered.
HAL_DSI_TearingEffectCallback

#19

Here is the video again without onedrive or google drive :slight_smile:

https://transfernow.net/32amd105rvdy

#20

I can see similar artifact when I do a full screen update on my display.

I do not think it is caused by the speed of the communication to the display. It is the tearing cause by the internal display RAM scanning during the refresh. My display doesn’t expose a TE or VSYNC signal to synchronize with. I am using DMA transfers and still see this occasionally.

But not having a TE doesn’t matter as much if you aren’t doing a full screen refresh, as you will be updating different areas at different times anyway. I only see the effect on large rectangles now.