I am using lv_port_stm32f746_disco, but with a 1024x600 display instead of a 480x272.
Now I need to adjust the buffer from 480 x 48 to 1024 x 100 (1024 / 10).
Unfortunately this does not fit into the (internal?) RAM (maximum 1024*61).
Is there a tutorial what all I have to change on this lv_port_stm32f746 to go to the external SDRAM ?
I think this question not for this forum but…
You situation depends on compiler that you use for stm32.
For gcc based code you need define buffers in sdram section.
According this I added following code before SDRAM init (in tft.c) and now it works. BUT: Since my buffer was not 1/10 of the horizontal resolution, I hoped that the lv_task_handler would do the job much faster now with full buffer and external SDRAM… but unfortunately it seems not the case …
Putting the draw buffer in SDRAM is too slow because of the big latencies. I had the same experience on the stm32_F469i. I would suggest to reduce your buffers so they fit in internal ram (which has almost no latency). Making it smaller will not effect performance that much.
Though with the F7 you might be able to use some caching functionality on the external RAM.
ok interesting, thanks for the tip.
I have the feeling that the used lv_port writes directly to the SDRAM even without adjustment, because the SDRAM initialization is enabled…
Ok, so now I rather have to see what I have to change to write to internal RAM…
I think you need to read the display configuration documentation of lvgl to get a better understanding.
LVGL has 2 kinds of buffers in use.
The actual framebuffer that contains the whole screen and is transferred 30-60 times per second to the display. static __IO uintpixel_t * my_fb = (__IO uintpixel_t*) (0x60000000);
The LTDC hardware copies that memory buffer to the display. This is put in ext. RAM because the whole frame does not fit in the internal ram. Here the latencies are not an issue because it is copied in large blocks directly without CPU intervention.
Next to the framebuffer you also have one or two lvgl draw buffers. These are used by lvgl to do the actual graphic drawing calculations. These calculations are done on blocks the size of your draw buffers.
On this part a lot of write/read operations take place by the CPU to do the drawings. This is the reason why the RAM latency has a huge effect on the performance. So these you place in internal RAM.
When the calculations are done for the buffer it gets transfered to the framebuffer. This is done in the the flush callback function. You can use DMA2D to offload the CPU and do the actual copying for you. This allows you to continue calculations on the next drawing block.
So just change the draw buffer sizes so they fit your memory and check if the implementation uses DMA2D for transfering the buffers.
PS. DMA2D can use rectangular buffer sizes. Regular DMA needs a consecutive memory block. This allows you to use draw buffers smaller then a full line width.
Looking at the lv_port code it uses the regular DMA. Not DMA2D (DMA2 is not the same).
So in this case you need to keep full line widths. Otherwise you will need to change the code to use the DMA2D block.
Which would be a good learning exersice
Nope that is internal lvgl that uses the engine for accelerating the drawing. In my experience it did not have any influence on speed. But might depend on your use case.
Correct that is what I stated in my message. That is using it for drawing internally in lvgl.
But for copying in rectangular blocks to SDRAM it really helps if you don’t draw full lines.