How to use touchgfx with nucleo board that is not in standard list also how to use a display controller like ili9488 or RA8875.

[Kyrpav]

Hi i am very new to all stm32, i have some project that i want to move to stm32 mcus. I would like to know if i have a nucleo board that is not in the list of selections that exist in designer, or i have selected an mcu that a dev board does not exist at all like H755ZI what should i select as board. Also about screens until now i have used 2 controllers ili9488 and RA8875 for larger resolution, how this can be used since the discovery boards have other displays that do not specify what they are, and how all these things can be fixed with touchgfx. Is there any guide that explains these cases that i could read?

[HP]

LTDC is for parallel displays

DSI is for serial displays - they have way higher clockspeeds for the pixelclock and have tighter requirements for design.

also, quite unfortunately, the STm32 only supports 2-lanes of signals, while a lot of displays you can find are 4-lane.

Parallel displays are just way simpler to work with!

you can do 1, 2 or even 3 framebuffers (the 3rd is called animation storage) on tGFX. each framebuffer is sized by the calculation of height*width*depth. if you can fit a framebuffer into the internal RAM you don't need external - but for higher resolution displays you normally would end up needing the external SDRAM, because in order to have nice transitions on your display you need at least double buffering. if you are only using single buffering the transitions will not be displayed.

QSPI (external flash) is used for storing your images (assets). in order for this to work properly you also need an 'external loader' - this is its own can of worms on itself. the loader is pin-specific so watch out!

if you only have a few assets, you can get away with storing them in internal flash - but you will run out of memory fast this way!

if you can make up your GUI from the basic building blocks inside the designer you can save quite a lot of space.

If you have a look at the video I linked, you can see that I modify the linker script to include the SDRAM and QSPI memory space for storing the framebuffers and assets externally.

[Kyrpav]

So i will retry to place things in order.

1. tGFX send/store data to exSDRAM using QSPI for the buffers created by tGFX at the end of your video you are placing the QSPI code (not initialization) that probably loads the data to the SDRAM am i correct?
2. Then LTDC gets the data from SDRAM and sends them to the display. (I did not see this part of code) i suppose that LTDC does it by itselft?
3. From what i see not all board has DSI but all there series and also the F767 mcu have DPI so if i need to use DSI and select a display that has DSI i have to go to F769 or F4x9 and i suppose there the setup in pinout will be available https://www.st.com/resource/en/application_note/an4860-introduction-to-dsi-host-on-stm32-mcus-and-mpus-stmicroelectronics.pdf
4. In all the displays that they say 800(RGB)x480 or something bigger if i do not see the hor/ver porsch or the clock Mhz in datasheet does this mean that they are not RGB or i have to ask?

I tried to overview fast

https://www.st.com/resource/en/application_note/an4861-lcdtft-display-controller-ltdc-on-stm32-mcus-stmicroelectronics.pdf

[HP]

what? no..

at this point i will say something along the lines of 'maybe you should look in the documentation for this' but I will try to summarize - it's basically what I wrote above.

tGFX is a framework. it will generate a framebuffer. the framebuffer is 'just' a pile of pixel data.

Depending on your screen size and the number of required buffers you MIGHT need to store them in external RAM. That means:

1. if you have a small screen with a single framebuffer you can store that internally
2. if you have a large screen with multiple framebuffers you need more space to store them

What I'm saying here is that the SDRAM requirement is solely based on how much memory you need for pixel storage.

the memory needed is: display Height * display Width * pixel color depth * number of buffers

Next, what you want to display on your screen is up to you - you can do squares and circles and basic shapes (and text) - this is built-in into tGFX and the designer.

if you choose to import images and other fancy things - you will run out of memory very quickly.

Images and other fancy things are generally called 'assets'. these are static pieces of information that you need to be able to load from somewhere. that means that:

1. if you have few assets that are small you can have them internally
2. if you have large assets and/or a lot of them, you need external memory

for this external memory you have the QSPI.

now, in order to communicate with the QSPI you need this external loader thing. again, this is it's own topic but you will need this file (it's a small program compiled into an .stldr file that you include into the debug configuration in CubeIDE)

this effectively means that SDRAM and QSPI memory is not always both needed - that will depend on your project. usually though it's easier to include both so you can have one standard HW configuration.

be VERY aware of the pinout on the MCU you select for this - the interfaces are overlapping and are placed all over the pins. be aware of configurations that effectively lock out certain parts - for example the STM32F746 in the 144 pin LQFP will not be able to handle 24-bit LTDC AND SDRAM- there's not enough pins available for this. (i might be wrong - it's been q few years since I looked at this)

okay, now you got yourself a framebuffer (or multiple) - tGFX is 'display agnostic' this just means that what you want to do with the framebuffer data is entirely up to you. you don't need to use it for anything (but that would be weird).

Different displays need different methods of pixel-pushing.

you are right that the LTDC dont' realy need anything else than the setup and porch configuration.

there are MANY different displays with different controllers out there - choose carefully which beast you want to battle (there be dragons)

1. Parallel 24-bit RGB is in my oppinion the easiest. STM32F746 as an example
2. SPI + 18-bit RGB comes in close second - you 'just' need an INIT-script to configure the controller
3. MIPI-DSI.. uuuurgh... where to begin - as I said, the MCU only support 2-lane interface, so be aware what you need. also, tight layout constraints because of higher pixelclock. STM32F769i is a good example here
4. SPI controllers - they do have a 16-bit data interface but now this will need to use the FMC interface (which is the same interface you use for SDRAM) - they should be able to co-exist. the STM32F429 is a good example of this

No matter what you choose, expect to spend a fair amount of time in the CubeIDE and MX configuration where you set up pins. compare these to your layout - and double and triple check this.

as for porch settings and init-data: yes, these should be supplied from the manufacturer! I think I just got lucky when I developed my own board the first time - the porch from the 746 board was the same as my display.

It is complicated stuff to begin with - but it does make sense in the end.

[MM..1]

You little lost and mix.

Your 1. tGFX is gui render into framebuffer is ok. Framebuffer can place internal or in external SDRAM. Dont mix QSPI here.

2.LTDC is hw based, init code isnt part of tGFX (for RGB displays mode)

3.DSI is next internal hw bridge from LTDC to high speed serial sync interface using diferential low voltage ... (for MIPI DSI displays)

other displays with 8080 or SPI can be controlled with FMC and SPI hw in STM.

QSPI is extending flash storage for your GUI. For example simple GUI images + fonts = 1,5MB you can dont use QSPI external. But if you plan big amount graphics internal 2MB is full and you need add external QSPI for example+16MB

[Kyrpav]

1.So tGFX sets the framebuffer. The location is up to me based on size.

2.For the QSPI i though that it is just an interface that you can use it wherever a chip supports it but from what i see it is specifically designed for memory so i assume that when someone talk for QSPI he/she talks about a memory itself that uses QSPI. I assume the size of QSPI is whatever even 256mb is they say in the docs (i think is not really needed except if you place also video?).

3.LTDC handles the data transfer from whatever memory location to the display.

4.For the display interface with parallel is the easiest probably nothing else is needed except what you set also in video for the portch.

5.For the DSI i assume i assume proper pin connection for the layers and to check the layers of the display + clk + something else that i do not remember now. But i do not need to created function to push the pixels.

6.rest of serial interface or intel 8080 since i have to use FMC which if i understand it is just normal set of pins and SPi protocol i will have to create also the push of data to the display

I hope that i am in proper place now . Crossing fingers.

What do you propose to by 769-disco or a screen to use it with the 144 nucleo-F767. Also you just unlock in my mind the concept of what dispay ic to pick.Any proposal?or something you used and it is smooth and good?