Add a code snippet which can run in the simulator. It should contain only the relevant code that compiles without errors when separated from your main code base.
The code block(s) should be formatted like:
/*You code here*/
Screenshot and/or video
If possible, add screenshots and/or videos about the current state.
Hi, Right now I am testing the ft813 800x480 with an Aurix TC375 mcu and simple Spi @30mhz . It works fine, but it’s very slow, write it line by line and it generates a rolling effect from top to bottom. When running the testbench example only can get 2 fps.
I still can’t find a way to make it work properly, I don’t testing on stm32 but it’s the same way to use.
I will be reporting any news.
And it was quite simple to integrate (in my case was a STM32G4). Just had to change some definition in “Riverdi_EVE\host_layer\platform.c” regarding the pins used for “CS”, “RES”, and SPI Module in use. They use the Riverdi GitHub library to control the display, it is a bit confusing for my taste but since we don’t need to use a lot of commands except for the display initialization it is “fine”.
Careful with the display initialization, it needs to match with your display characteristics, specially the commands sent in “App_Common_Init” some of them are LCD Panel dependent and other ones may be “Display Board design” dependent, in case of Riverdi displays typically in the datasheet for the display there is a table with the values to configure in chip. Handling screen rotation and touch screen is quite easy.
For a STM32H7, it a bit more tricky because of the issues with data cache maintenance, you can check this port stm32h7b3 port for some references about that. And eventually use the HAL instead of LL for SPI Access, although the use of DMA becomes a bit more difficult in my opinion.
Regarding performance (in my case with a 3.5" 320x240), using SPI (and DMA, very important the use of DMA or at least leverage the internal SPI FIFO of the processor) the performance is not bad, actually is quite good for a SPI display, in my design i am using QSPI ( @ 21.42MHz, can´t go higher start to have errors) and the performance is very good, a full screen refresh takes around 29ms (Without DMA is around 91ms).
During the benchmark test most of the times it maintains the 33FPS having significant drops (to 5~7FPS) in some more demanding tests. Probably performance can be improved by using double buffer and not blocking in the function ex_disp_flush until DMA transfer is completed.