FT81x porting to STM platform

Description

How to port LVGL to FT81x and STM32

What MCU/Processor/Board and compiler are you using?

What LVGL version are you using?

What do you want to achieve?

What have you tried so far?

Does anybody know how to port FT81x to LVGL I am using STM32H7.
I found this…

It is way too difficult for my taste

So I found this…

I just need to change command: fillFB(area->x1, y, area->x2, y, DISP_fb);
with classic FT81x command. (using this official library GitHub - MatrixOrbital/EVE2-Library: C library for a Matrix Orbital EVE2 & EVE3 & EVE4 Displays)
Thank you for help and ideas

Code to reproduce

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.

Would you like to share command you used instead of fillFB?
Every idea and help is appreciated.
Looking forward to your news.

Hi

I have used the same github repo as a base for the development…

github

Another source for reference is ESP32 Drivers

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.

1 Like