Improving the TouchGFX experience (Fixing broken links in the tool chain)

[Martin KJELDSEN]

Hi everyone!

I'm kicking off a parallel effort to improve the experience using TouchGFX as far as general ST tool chain is concerned. There are links i cannot fix (though i can suggest improvements) and there are some that i can.

So, what are the major pain points in using this rather complicated tool chain (TouchGFX Designer, CubeMX, CubeIDE, CubeProgrammer, etc)?

• Which improvements would you like to see to make using TouchGFX easier when it come to integration and tool chain? (Specific framework/designer inputs are also welcome and i'll forward those, although this survey is mostly concerned with how to improve integration between tools).
• What are you typically struggling with when you struggle?

Thanks!

Best regards,

Martin

[HP_it]

What a great idea!

It's been a while since I started a project from scratch and I think I just work with the 'quirks' since I think I know most of them.

One thing I miss is a few full guides on how to get a system up and running. We have lots of snippets around in the documentation but I always have to take some of the AT's apart to gather more knowledge about the setup.

I'm about to write another question regarding a system with SPI display. I know that there is a board that uses this, but the main question is about the custom tick that should drive the tGFX process. I have read that support page so many times I think I'm missing the point. In that particular case I would love to have a video of someone setting up such a system.

Just as with complete setup guides it could be nice to have shorter videos showcasing special functionality, like callbacks in lists (this is where I'm at right now). Showing the whole process of the setup and having an idea of which part of the code is generated for you, which parts are virtuals that need an override and so on.

Another thing that could be emphasized is that CubeMX is only configuring the hardware connections - not the following setup, for example SDRAM init. Nor does it magically write drivers for you. I think most of the people in here knows that, but maybe it could be written in plain text somewhere by the code generator, just for good measure :D

It's been a while since I've last seen the error but the English language/locale dependency is pretty high-up on a 'please-fix' list.

There's a few people out there that have missed the complexity of this setup. It is by no means something you just throw together overnight or even a few days. it takes time to get into the inner workings of tGFX.

[HP_it]

I can see that a few other people have some of the similar issues that I have so I will add to my previous post.

about a year and a half ago I started with tGFX and at that time a lot of people had issues setting up the LTDC interface. It seems that there have been a shift towards SPI interfaces.

I know that tGFX doesn't care about what display is connected and how it gets the data transferred but telling people that is... hard... Getting started with the buil-in AT's is easy but when one are building custom HW the complexity starts to show.

So the above suggestion with tutorials is still valid, but maybe even more important with a focus on different display interfaces. I know this is not in the core of tGFX since it's about maintaining a framebuffer, but pushing pixeldata is such a big part of the whole solution that it makes good sense to have complete coverage of the process.

ideally a complete setup guide for different display interfaces, including (but not limited to: 8-bit SPI, 16-bit SPI, LTDC and DSI)

[Michael K]

You didn't mention Version Control in the OP but in the past I've had to do some serious untangling after merging branches where TGFX changes are involved, texts especially. SingleUseIdXXX gets used multiple times etc. I've tried using text resources more frequently but it's impractical for many texts were the intention is indeed single use. Note that I do gitignore the generated folders.

A possible remedy that I know is used in KiCAD for example is instead of a sequential identifier, a timestamp-based hash could be used for each new added object. That way if someone creates a new text object on one branch and someone else creates a new text on another they are almost guaranteed to be unique instead of colliding with the sequential numbering.

Also, the text.xlsx really could be a .csv, no?

[Martin KJELDSEN]

Thanks, Michael. The difficulties of maintaining an excel sheet in a version controlled project is still something that we want to address. It affects a variety of tools, so it's not a small thing to change, but it's perfectly logical to do away with this format. And it'll be something different than csv, for sure.

I've resorted to .gitattributes in the past to use tools that can actually suggest merges for xlsx.

Thanks for the input.

[John Devereux]

Hi Martin,

If you change the spreadsheet please make it something a non-technical user can edit if possible. Translations are usually not done by programmers!

Thanks, John

[Michael K]

This might fall under "links you can't fix" but I find the launch cycle is so slow. I discovered that you can create a new debug configuration that doesn't redownload the whole QSPI every time, which is quite nice (actually I think this info should be more widely shared because it's a serious timesaver as the project gets bigger). However even still there are still long delays between clicking build and the process starting, the build finishing and the debugger connecting, the debugger connecting and cubeprogrammer launching, cubeprogrammer launching and the download actually starting...

[HP_it]

That's actually really good advice!

When not changing anything in the GUI assets I have removed the 'verify' step and sometimes also removed the breakpoint on main (if the issue I'm debugging is elsewhere it most likely have a few breakpoints of its own)

So basically you're working with multiple debug configurations, right? one that is 'fast' and one that is 'full'?

[Michael K]

Yup! I basically disable the external loader on the "fast" configuration.

Good point about disabling verify and the main breakpoint as well. I keep verify enabled because (believe it or not) sometimes if I stand up from my chair while debugging the verification will fail. I should probably find an ESD safe chair... Anyway, the verification of the main program is pretty fast.

[PKara.1]

I spent entire weekend trying to make STM32CubeIDE work with TouchGFX but none of the "solutions" available online worked me. Can we please get this fixed first? Some further suggestions for improvements :

1. Being able to duplicate a screen. Once I've setup a theme with one screen, it will be convenient to replicate that screen .
2. I use Figma to generate assets that i then import into TouchGFX. Having access to those design tools withing TOuchGFX will make this software more design oriented.
3. More advance widgets. Something similar to QT Designer

[Martin KJELDSEN]

Thanks for the input!

What do you mean by "none of the solutions online". I've just tested 3 different application templates from the designer with CubeIDE and those worked fine.

Duplication of screens would be a nice feature i think, AND easy to do.

Better interoperability with outside design tools is a nice idea.

Any specific widgets you had in mind?

/Martin

[PKara.1]

Thanks for your reply Martin. This is probably not the right place to discuss this issue so I will start a new thread to share some screenshots of the errors I am getting. Hope you can help us resolve them.

[MGatt.2]

Hi.

I have implemented a demo for a client using STM32H735-DK. For me, this is the first experience with graphic. I created the project starting from the touchgfx templates. All worked correctly!

But now I have to design the custom board with some differences from the demo-board (for example I will use the LQFP version instead of the TFBGA).

How to create the new project? I can't start from Touchgfx because it only includes pre-built templates. If I start from STM32CubeMX I have a hard time including touchgfx. In my opinion, there is no clear guide on the steps to take. Thank you.

[Romain DIELEMAN]

Hi,

The online documentation will help you understand and guide you through the steps to follow to develop a TouchGFX project on a custom hardware. The process may be long but you can use the application templates as source of inspiration or help during this. Badreddine from ST made videos explaining how to customize application templates to add a different display for example which may help you. Another user made a nice video a while back as well which could be of interest to you.

Concerning the development you can also divide the tasks in two if you are not alone: one team working on the board bring up (so the MCU configuration through STM32CubeMX, setting all the drivers, enabling and setting TouchGFX generator...) and one team developing the UI (through TouchGFX Designer and user code). As long as you know the resolution of the display, which bpp you will have, the second team can develop the UI using the simulator instead of an application template in TouchGFX Designer. You will then use the import Gui option when the other team is finished and they have a working project running on the hardware.