Touch-GFX-Sample with ILI9341-SPI wanted (dead or alive ;-)

[Sven1]

Hello,

I'm now spent about three weeks with trying to set up a custom board with the M7-Core of a STM32H745BIT6 to work with an ILI9341-controlled display via SPI.

Interfacing the ILI and writing a bitmap to the display even with 50Mhz SPI Clock (with and without DMA) works perfectly. (=> handling the ILI itself is not the problem)

The online documentation for Tgfx 4.16 doesn't help me to run the system like it should. The Sniplets from the ST7789-Example in there for the L496-Disco-Boads seems to cover an older version of Tgfx cause there are used other (older?) C++methods)

Cause in CubeMX there is a very small hint, that for some reasons H745 is not supported (yet?), I also tried it with a H743-Nucleo Board but also without any success.

The Tgfx included example for the ILI9341-Shield (X-NUCLEO-GFX01M1) for the Nucleo-G071-Add-On Board is not really usable, cause the SPI-Communication is made on MCU-Register-Level (seems very different to H7) and it uses a partial framebuffer and external SPI-Flash but doesn't use FreeRTOS.

I checked a lot of things in my CubeIDE1.6.1 generated project including watching the semaphores „frame_buffer_sem“ and „vsync_sem“ => they never seems to change there status / never been taken? The methods in teh os-wrapper seems to never called....

Due to this, my additional code-lines to transmit data to the ILI in the files where I have to place it (follwing the documentation) never seems to run.

So my first 3 Questions:

1. Does anybody has a hint for me where I can go on?
2. Does anybody could share an example based on or closely to my configuration?

• STM32H745BITG (using M7 Core)
• No external Flash
• ILI93241 4-lines SPI RGB 565
• One complete Framebuffer in internal RAMFreeRTOS

3. Can I anywhere find better examples/explanations to do it by myself?

If it would be helpful I could share a similar project based on a H745- or H743-Nucleo so that it would be easier to „try at home“….

In my live I read a lot of explanations, some good and a much more bad, but that what Tgfx offers here is one of the worst I ever got. It doesn’t help me anything to get to the goal. I cannot believe, that it is so difficult to describe the few steps to set up a custom driver. Surely I understand, that ST/Tgfx cannot write exacly how to connect all display-controllers on the market, but hey…

 ….this is only „SPI“ – it only uses few functions to set a window and transfer a certain ammount of bytes. Thats all !! ?? Why you don't explain where to place the necessary commands.

This leads me to my fourth question:

4.    What is the the intention of ST/TouchGFX to supply such kind of documentation?

(Is this cause Tgfx want to sell additional individually made ready-to-use display-drivers or does ST wants that users only use exact the same MCU-&-Display-Types that are sold as Disco-/Eval-Baords?)

P.S.: I know, that 745 also offers LTDC or 747 even DSI, but the hardware is like it is, so I have to work with 745 and SPI

I also know, that external RAM/Flash would be better, but for my application it will do.

Thanks for your answers…

Best regards

[Sven1]

Hello again,

thanks to the link shared by MM..1 - i tried it but could not get it running.

Meanwhile I also tried the new Tgfx 4.17.0.

In the CubeIDE integrated CubeMX it is declared that 4.17 should work with H7. (...4.16 and 4.16.1 were not)

But with 4.17 it isn't even possible to generate a project which the will result in a succesfull compiled build without errors !?

What's going on here? (..was this all tested by ST/TgfX before release? - I can't imagine.. :( )

Meanwhile I also tried the LVGL - and got it running on my hardware (...so: I principle I am able to get things running ;)

...and also STemWIN works on it with a self-modified Flex-Color-Driver.

But the driver is very slow, cause STemWIN sends the data to the ILI9341 via thousands of single SPI-Transmits with one byte each - this causes enormous delays between the single bytes.

The also implemented function to send several bytes in one step seems not beeing used by STemWIN (65.536 Bytes or even words should work with SPI-DMA-Transfer)

So beside the Tgfx-tragedy: If anybody knows how to tell STemWin to send a number of bytes/words in one rush => please let me know.

... still struggling on ...

[Sven1]

Update...

...I tried it again with the new CubeIDE 1.7 and Tgfx 4.17...

I generated a new project (see attachment), but it is still not possible to work with it...

...even worse - I could not get any error-free compiler-run.

The first issue:

Opening the ApplicationTemplate.touchgfx.part with Tgfx works...

...but when trying to generate code the first issue appears – an error generating the code.

As I figured out: The reason is that CubeIDE generates the ".cproject"-file in the CM7 subfolder. But Tgxf expects this file in the folder one layer above.

The quick-n-drity-solution: copying the file to the upper folder ….and then Tgfx generates the code without error.

(funny: with older versions I had to copy the ".ioc"-file to the place where the ".part"-file was located to get it run....!?)

The second issue:

From the last experiments I know, that I have to add all the Tgfx-generated folders to the include-path...

...but even if doing this, CubeIDE does generate errors when compiling the project cause some files are not found...

After now spending dozens of frustrating hours with all these problems I have one question to the people from ST and Tgfx: What are you doing? … and … WHY???

OK - I know, the software is "free" for use - but on the other hand we all know, that you offer it for free cause you want to sell MCUs (...if they would be available...)

So why do you release software like this, which does not work and frustrates customers and make them angry?

Personally I think that's ok that some combinations (MCU and SW-features) does not (yet) work together, if you exactly communicate this.

But I really does not enjoy to spend a lot of my time every time when a new release occures - only to figure out that it still does not work.

So please: If not possible to directly include it in CubeIDE please write it clearly and in big letters where users can find and read it, that (e.g. in my case) it is not possible in CubeIDE 1.7 to use TouchGFX with a STM32H745BIT6 for driving a LCD via SPI.

If some of you from ST are interested in the problem I added my project just freshly generated with CubeIDE1.7.

It would be nice, if:

...you can tell me how to do it right..

...or...

...you tell me, what I did wrong?

But in this case I diretly ask you, why I was able to do it wrong with your software? (...which in my oppinion should prevent me from doing it wrong..!?)

So: I hope you understand my povocative question in the right way to generate motivation to do it better the next time...

...and If not => I will have my special awareness of the softies at ST and the honor they feel about their daily work...

So long - still hoping for better times

Have fun with my attachment

(I took out the check whether the M4-Core is running, cause I deactivated it with CubeProgrammer)

Btw: When activating FreeRTOS together with Tgfx there occure similar errors, that some FreeRTOS files are not found. This can be solved by copying the whole FreeRTOS sub-directory from the "common"-folder to the "cm7"-folder and adding all sub-dirs to the include-path...   (…can‘t think, that this was the inventor’s origin intent…!??)

[Sven1]

...just tested again with the brand new Tgfx 4.18... (and CubeIDE 1.7)

...and still...

**** on the whole line !!! (...translated frustation outgoing from a well-known German expression... ;)

...not even a first generation of the newly created CubeMx-Project leads to a working code generation in the new Tgfx-Designer... (...the well-known Message "Generate Code ! Failed" ***** me in my brain again :-(( )

...very sorry, but...

"You are Idiots !!" (ST and Tgfx)

(...in principle, I dont want to use those strong words, but I can't express it in any other way...)

If I would do my job in a way as the responsible programmers at Tgfx & ST are doing - I would have been fired years ago!

Shame on you !

P.S.: with my strong words I hope to trigger an algorithem which pops up my post to some ST-Guys who possibly forward my technical frustration to persons who could improve something in "the system" ("the hope dies last" - not personally knowing wether this expression exists in other languages ;)

[Sven1]

nice...

my "strong" words are directly blanked out by software ;)

..still hoping that someone now (Human - not Bot) looking at it..

...

funny