TFT LCD drivers for TouchGFX?

[NNar]

I am looking into using an STM32 with TouchGFX to drive a 2.4" TFT LCD. The LCD will have some type of internal driver (ILI9340/ILI9341/ST7789, etc). Are there drivers for these already? Or is this relatively standard (I doubt)? Or do I have to write my own?

Any good app notes/docs/tutorials that explain this properly?

Thanks.

[sasha]

Hi, thanks for your quick reply. Did you manage to get it to work at all, e.g. with STemWIN?

[ASili]

Hi,

Yes, I could make it work well with HAL library. I am using nhd 2.4" tft display. I can try to help if there is something that I can do. Please let me know.

Best regards

[Martin KJELDSEN]

Hi,

Can you tell me what kind of things you've tried and where you are right now? In theory, making a new screen work with TouchGFX should be simple because TouchGFX specific drivers for individual displays do not exist. The steps are:

1. LCD and LTDC (if applicable) configuration and initialization (Format, clock, porches, etc) - For Parallel RGB displays the standard HAL will operate on VSYNC interrupts.
2. If Serial interface: Transferring framebuffer data to the display in a special hook (Serial configurations are not supported with CubeMX when choosing TouchGFX).
3. Defining screen dimensions for the TouchGFX designer / application so that dimensions of canvas match that of the display.

That's just the overall guidelines. Let me know.

/Martin

[Martin KJELDSEN]

Any updates on this issue?

/Martin

[PDeck.2281]

Hi @Martin KJELDSEN​  Martin,

I'm about to go down this rabbit hole.

I am using an STM32L4R9AI with the 240x240 round LCD using the st7789v display driver. It has a 2x SPI interface with a FMARK signal that generates the signal for safe display update. I also have an I2C capacitive touch controller on the display glass that will need to be integrated. It seems a good starting point will be the stm32l4r9i-disco board. I would appreciate any pointers or help in making this a smooth experience.

Regarding steps 1 - 3 and looking at the stm32L4R9i-disco, is the Chrom-GRC™ (GFXMMU) used for this type of configuration?

Paul

[PDeck.2281]

Hi @Martin KJELDSEN​ ,

Further reading on this and also AN4860 it appears that maybe the DSIHOST can be operated in SPI mode and that the TE (tearing) signal from the display controller can also be used. Has anyone connected a display in traditional SPI mode using the DISHOST? Is this possible?

https://www.st.com/content/ccc/resource/technical/document/application_note/group0/1d/b8/33/4f/dc/0a/45/52/DM00287601/files/DM00287601.pdf/jcr:content/translations/en.DM00287601.pdf

[Martin KJELDSEN]

Hi @PDeck.2281​,

By "rabbit hole", do you mean "TouchGFX" ? :squinting_face_with_tongue: .. or display interfaces.

In our configurations we use the TE signal - You can check out some of the DSI based Application templates from the designer to see how it's implemented - They're basically drivers for mipi dsi displays in adapted command mode (We don't have configurations for video mode).

SPI mode is not something we've tried either.

For STM32L4 the Chrom-GRC (GFXMMU/Graphics MMU) can help optimize memory usage for round displays since you don't really need a "square" framebuffer, if you get my meaning. The GFXMMU helps with that.

Bonus info: Since TouchGFX does not support 180 degree software rotation (This kind of rotation is usually handled in hardware config) we've used the ChromGRC configuration to "flip" how an application is presented on screen. You can do this for each line.

/Martin

[PDeck.2281]

Both really :)

I've been digging through the stm32l4r9i-disco board (round display) touchgfx code. Can you give some insight into why there is an LCD_Init() function in gui_main.cpp and also a BSP_LCD_Init() function in stm32l4r9i_discovery_lcd.c they look very similar. It seems it would be better to have a "driver" level initialization?

[PDeck.2281]

@Martin KJELDSEN​ Hi Martin,

I spent a good time digging through the code of the 32L4R9IDISCOVERY (round display). I now have an operational SPI based driver that can send a "frame buffer" to the display or it can address any pixel in the display memory over SPI.

It seems also that the varialbe _frameBuf0[] is updated with the display contents, so it should be a matter of just sending that buffer over SPI to my display. I have been able to change/create a template for a 240 x 240 display with RGB565 encoding.

It appears that the vsync in the disco example triggers a display update. I could simply replace this with a timer to trigger the display update. It appears many functions are called from an internal library through touchgfx::HAL::getInstance()->taskEntry(); What functions must I support for this?

I am working with my local FAE team here in Boston, but there is limited information on how to port a new display driver to TouchGFX. It would help us greatly to have a very simple skeleton to know how to implement this.

Thanks,

Paul