Integration with TouchGFX and STM32

[Yc1897]

Hello,

I am trying to integrate my SPI Riverdi display (RVT70HSBNWCA0) which supposedly has been tested with STM32 with this library. I haven't tested it on my Nucleo board yet but I am trying to figure out how could I integrate the TouchGFX Gui editor with the display. TouchGFX does not support SPI displays and we have to make changes on how TouchGFX sends data to the display, referenced in this article https://support.touchgfx.com/docs/development/touchgfx-hal-development/scenarios/scenarios-fmc.

The article states that we need three steps to make it happen:

1. Setting the display frame or the area we want to send the data
2. Prepare to send the data
3. Write the data to the memory buffer.

I tried to understand how this would work with the EVE and with my display, but it seems like a very complicated process. I found out that the technique used by the EVE controller to carry out the process is very different than the simpler ST7789H2 display controller used in the article. Could anyone help me with this? Is there a simpler process to do this? I'm not sure if I should try to make it work on TouchGFX somehow or a different GUI editor. Any help would be massively appreciated!

Thanks!

[RudolphRiedel]

Hello,

while I believe that this could be done in general, this is not a good idea.
The EVE chips work fundamentally different in comparision with a plain framebuffer display controller.
The image displayed is generated line by line from a display-list that for the most part contains commands to dermine which objects to display where.
Sure, that list could be reduced to show a single image from memory but this would mean to throw out 95% of what the chip actually can do like for example displaying text from the built-in fonts with only a fraction of the SPI traffic that would be necessary to transfer even only the necessary pixels.
At the resolution of this display in particular, which is 1024x600, it is not possible though to put one full size uncompressed image with 16 bit colors in memory as there is "only" 1MiB of SRAM and required would be 1200kiB.
So abusing a BT817 as a framebuffer at 1024x600 would require to use one of the 8 bit modes like RGB332 or the monochrom L8.
There is the option to display ASTC compressed images but any controller that could compress images in this format
in realtime very likely has a gfx unit implemented and is not really a MCU but rather a MPU or SOC.

And even at 8 bit it is not a good idea to use one single image, this should be a set of much smaller tiles as there is no way of synchronizing the upload of the data with the display.
With tiles the upload could be done to a tile that is not not displayed to modify the display-list after the upload is done.
No idea of TouchGFX could even do that but only updating the portions of the screen that actually change is a rather obvious thing to do to increase performance.

One more, the EVE chips do handle the touch, you set a tag-id, display an object somewhere. If the object is touched you receive the tag-id, it is not necessary to calculate from coordinates what might have been touched.

I can do full color UIs with 60 fps that react with no detectable delay using an Arduino Uno and yes, on the RVT70HSBNWCA0.

So in short you either have the wrong display or can not actually use TouchGFX for your UI.

[Yc1897]

Hi Rudolph,

Thank you so much for taking your time and responding to me. Your insight has helped me massively and I have decided to use a different display which has TouchGFX support and is much easier to interface.
Thanks again for all the help and I appreciate it a lot!

Best,
Yash

[RudolphRiedel]

Ok, one last point though as my answer concentrated on using EVE chips with TouchGFX.
Of course this library works with STM32 chips, only not with TouchGFX.

And the niche for that would be mostly when there are limited resources, like when you have a coffee maker and want to replace the 2x16 text display and keypad with a nice touch display while not changing everything else by switching to a more powerfull controller which might include switching to a different manufacturer and the need to rewrite a good portion of the codebase from scratch.
Well, the first EVE chips were introduced in 2013 and I am afraid that the niche for them is getting smaller and smaller, back then controllers with integrated GFX engines practically did not exist.

[Yc1897]

Hi Rudolph,

I do appreciate your work building this library. Its fantastic and fairly straightforward to use which is how it always should be. I will use this library in the future where more "ready to go" option like you mentioned is needed. Once again, thank you for taking your time and helping me out!