LVGL using standard HAL TFT IO (SPI and FSMC)

[rhapsodyv]

Description

We have a lot of TFT/XPT IO repeated code in STM32F1. This PR begins to change that.

Now LVGL uses the standard HAL TFT IO - FSMC and SPI, and XPT2046.

Standard HAL TFT and TOUCH IO are in:

#include HAL_PATH(../../HAL, tft/xpt2046.h) 
#include HAL_PATH(../../HAL, tft/tft_spi.h)
#include HAL_PATH(../../HAL, tft/tft_fsmc.h)

Next PR I will see to migrate emulated DOGM.

Benefits

• less repeated code
• more performance (HAL TFT SPI uses 16 bit DMA, the old LVGL SPI DMA were 8 bit, so it became very fast now)
• less errors
• more easily to port LVGL to others HAL

Related Issues

#18958
#18952

[looxonline]

Yes. Waiting for this to be used in a LP1678 SPI port.

[rhapsodyv]

Yes. Waiting for this to be used in a LP1678 SPI port.

Which board?

[looxonline]

Yes. Waiting for this to be used in a LP1678 SPI port.

Which board?

Have not checked DMA access on the SPI port exposed on the EXP header of the SKR1.4 but if there is access then it would be great to use it with that board.

[rhapsodyv]

Yes. Waiting for this to be used in a LP1678 SPI port.

Which board?

Have not checked DMA access on the SPI port exposed on the EXP header of the SKR1.4 but if there is access then it would be great to use it with that board.

I wil test it. But to run LVGL UI, you need access to spi flash too. The SKR 1.4 board only have spi flash in the TFT, not in the board. I dont know if it expose too.

[looxonline]

Yes. Waiting for this to be used in a LP1678 SPI port.

Which board?

Have not checked DMA access on the SPI port exposed on the EXP header of the SKR1.4 but if there is access then it would be great to use it with that board.

I wil test it. But to run LVGL UI, you need access to spi flash too. The SKR 1.4 board only have spi flash in the TFT, not in the board. I dont know if it expose too.

Yes, there is an exposed SPI header which is shared with the SD card. P0.26, P0.7, P0.8, and P0.9. I believe that these could easily be interfaced with a cheap, external W25Q32.

[rhapsodyv]

@thinkyhead I have finished the emulated DOGM to use the same HAL TFT IO classes.

Now, we have only one FSMC and SPI TFT in STM32F1, that follow this interface:

#include HAL_PATH(../../HAL, tft/tft_spi.h)
#include HAL_PATH(../../HAL, tft/tft_fsmc.h)

And it is already available in STM32.

Any other HAL that wants TFT, just need implement this two classes, and LVGL + emulated dogm will work!

Do I commit it here? Or wait the merge and do another PR, specific for dogm?

[rhapsodyv]

LVGL, Emulated DOGM and the new Color UI, now all are using the same low level IO abstraction. To use any of those UI, the HAL just need the low level TFT IO classes. STM32 and STM32F1 already have it, so all 3 UI are available for them.

[rhapsodyv]

@thinkyhead
This port emulated DOGM to use the same tft io: rhapsodyv@6bd3d04

Do I push it here? Or do you prefere separated PR to better organize merges?

After that commit, we have only two things to finish that refactoring:

1. I will join all xpt code
2. we can make a cleanup of the defines LCD_ and TFT_ defines

Lots of repeated code removed!!

[rhapsodyv]

It's containable. I see from this that the FSMC_UPSCALE pertains to how the screen will be drawn and how touches will be interpreted, but also that FSMC_UPSCALE is not tied specifically to the pixel-size. One should be able to decide to do 2x or even 1x scaling on a 480x320 screen and make it work, after all….

Sure, after this refactoring, we can handle upscale at a low level, making it available for all UI.