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]

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]

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)

[Martin KJELDSEN]

Thanks, HP.

It's great to hear (kind of?) that you're also struggling with some of the same issues, being a competent user of TouchGFX already. That's great input.

I agree, we cannot simply brush off display interfaces and claim we only care about writing pixels to a framebuffer. Taking notes.

So your input related to interoperability is:

• Difficult to know where CubeMX stops and when user/touchgfx takes over ?

/Martin

[HP]

That's a great way to describe it!

A lot of users start of with the Disco-kits where SDRAM config and QSPI timings are done in the AT. all those settings are easy to miss and not completely straight forward to find when designing a custom board.

There are many designers that have been baffled by the complexity that is inferred by choosing a different RAM chip and haven't considered that they need to do some setup themselves. 'It just worked' with the AT. Luckily most of the setup IS the same but one could not (and should not) assume that it is identical.

Personally I prefer video guides because they tend to show more than just 'the perfect scenario'. there might come something up during the recording that other viewers might stumble upon as well. (that's why I did the no-edit videos a while back).

It's a bit funny to read the threads and notice how a lot of users seem to have similar issues at the same time :)

again, it's a complex system that spans all types of development, software, firmware, hardware, low-level drivers/high-level drivers. My experience is that the documentation have been greatly improved along with the examples provided and the boards/chips supported. You're definitely on the right track - it's just a very long road.

[Martin KJELDSEN]

I'm actually also a fan of no-edit videos. They're more real. I used to spent a ton of time editing and planning videos, but as soon as a video gets out dated then you're in trouble again.

I agree it's peculiar that you're having the same issues at the same time.

You're right that it's very complex, and there are a lot of components to cover - While they may be covered in parts in the documentation it's difficult to get a good overview. What's your general experience with going through all of the toolchain? Maybe in a different order

Cubemx -> CubeIDE -> Touchgfx designer -> cube programmer -> ??

What are the pain points here? I'd like to see if there are some concrete changes i can make, tool-wise, while also improving the video/doc approach.

/Martin

[HP]

I haven't tried starting with CubeMX. I like the CubeIDE approach better, because there's fewer settings to get started.

One thing that could be done is that when one select a Disco-kit as the target chip you get this 'initialize hardware with default values' box. this is counter-intuitive because right there you go 'oh, nice, everything is set up for me! cool!' - when in fact what happens is that all HW connections are setup but the FW init is still missing. Also, QSPI timinigs are not set (at least they didn't get set on the 746 kit)

I remember quite the debate about one of these scenarios. I have tried to make it a mantra 'CubeMX is ONLY setting up hardware configurations' - I should make that a T-shirt :D

with the latest releases of tGFX designer, the .part file works great and I haven't had any issues with that process.

It's interesting to see that the designer keeps a watch over files and I frequently get a notification that 'some other process have modified my files' and I get to reload the project. Maybe it could be done in reverse over at the cubeIDE to make sure that one doesn't forget to compile the tGFX project?

I'm out on a tangent here, I know.

I'm circling back to the topics I think is needed most - examples and examples of different types of display connections. it's not a part of the core work of tGFX but I think that a lot of people would expect it to be.

I find the 'display agnostic' approach very fitting but a lot of people don't get it before they actually try and read what was meant. and THEN they need examples of custom implementations.

Actually, that would make for a great (and fairly easy?) case, which, conincidently is exactly what I need right now: make a tGFX project without a display, but with a 'dump framebuffer' function so you can see that tGFX maintains the framebuffer but decouples all the pixel-pushing. That would actually be a really great example to have! (forgive me if you have already made this :)

[Martin KJELDSEN]

Yes, that's been one of the confusing things from the get-go. CubeMX refuses to configure the SDRAM timings even though it knows what they are - to keep the seperation clean. I've asked for a re-work of this feature before. Basically the MX means MicroeXplorer. Only look as far as the micro.

Thanks for all your suggestions :) Keep 'em coming if you think of anything!

/Martin

[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?

[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...