first thing is you are not using double buffering or DMA memory. Those will give you a decent bump up in performance. The other thing is your code doesn’t show the connection specific bits for the display. Is the display connected using SPI, RGB, I8080, etc…?
I also thought that the STM SDK has libraries to handle connecting to the display and if it does it would handle writing the data you just have to pass it the buffer.
which tells me that you are only using a single buffer and you will not get any benefit of using DMA memory if only a single buffer is used.
When using DMA memory there is a special function thaat has to get called in the MCU’s SDK. You pointed out the use of HAL_SPI_Transmit_DMA which is a good thing you know about that function. You are not using it correctly. you are passing a pointer to lcdSpi to that function. I don’t know what that pointer is but I would make the assumption it is specific information about the SPI connection. in that structure you should find a field that you set a callback function to. That callback function would get called when a DMA transfer has completed. Inside of that callback function is where you would call lv_disp_flush_ready(disp_drv); That is what lets LVGL know the data from the buffer has been flushed.
If you don’t know exactly what DMA is I can explain it to you. If you don’t know what it is you will once I explain it and it will make complete sense on how the code needs to be in order for it to work. Let me know if you want to explain how DMA works with LVGL.
I am also seeing that display as having a color depth of 24 bits and not 8 bits. I will have to do more reading to know if that can be changed to 16 bit as LVGL doesn’t have direct support for 24bit color which means LVGL would need to be set to 32 bit color and the alpha bits would need to be removed form the buffer in the flush function. Having to do that will add quite a bit of overhead.
lets say the color depth is 16 bit
30,976 * 2 = 61,952 bytes
61,952 * 8 = 495,616 bits
so lets say there is a max transfer speed of 2MHz like you said. that’s 2,000,000bps.
2,000,000 / 495,616 = 4.04. that is the number of times the entire display would be able to be redrawn per second. Theoretical of course. it is more likely to be closer to 3 FPS.
as I had said, I did not know what the display is able to do and I have not had the chance to look into it yet. I have to read over the data sheet for the display to see if any changes can be made to the code to give better performance and stay within the boundaries of what the display IC is able to do.
I believe the display is 24 bit which is 3 bytes but I did my calculation for the display being 16 bit(2 bytes) if the display is in fact 24 bit then the frame rate would be closer to 2 frames per second and not 3.