TouchGFX works with disco/eval board, then what?

[JLema]

Hi,

let's say I created an interface with TouchGFX and it's working with a disco/eval display board.

Do you have any advice if I want to use the same code with a custom PCB?

I take the same uC, interface it electronically with any display of the same resolution and I'm ready to go?

If I want the screen to display to interact with an other system, I add a communication protocol and it's done?

Best regards.

[Tesla DeLorean]

I think that rather trivializes the complexity you'll encounter when your display and controller chip choices cause you to have to write some low level drivers yourself.

The screen buffer and rendering will be fairly consistent.

The life cycle for your display/controller is likely to be a fraction of that of your product and development cycle.

[JLema]

Thank you for your time Clive.

I know I oversimplified. I'm well aware that you hit way more wall then expected when you develop something, hehe, I laugh but it's not always funny...

The main point I want to make sure is the portability of TouchGFX to other display then the one used on the eval/disco boards if I base my design on these boards.

Thank you for your answer.

Regards

[Martin KJELDSEN]

Hi,

Generally speaking, yes, a TouchGFX application can be run (in terms of resolution only) on any other hardware platform. There may be restrictions in terms of memory used for buffers and the likes, but if you're basing your own design on a disco/eval design it should be highly portable and then you'll add in whatever protocol/communication afterwards to enhance the application.

We've seen customers do what you're describing in the past, with success.

[JLema]

Hi Martin,

Thank you for your time and your help, this is the answer I was looking for.

Best regards.

[Mon2]

@Martin KJELDSEN​ and @JLema​ - was going to say no. There is a strong bond between the code generators and the target graphics controller. However, Martin knows best - he is the guru from the company that developed TouchGFX.

On adding other features like communication, etc. - all should be good to go if you use the STCubeMX tool. Best to prove out your concept on the working ST kit -> review the CPU onboard -> then gel out your custom design using the same target CPU and you should be fine.

It is a strange costing model for the ST processors as we have seen again that the products are a lower cost in Asia than for us here in Canada. That is sad and not fair. Ok to prototype using mainstream distributors but most definitely shop the world when ready for your BOM.

On this topic of different target displays - would like to get back to you Martin to discuss in depth on how to change the target controller code as Asia is drying up on the older controllers used by the ST kits. For example, we have been shot down for the OTM8009A display which is scarce in Asia and impossible to source for new product design. After we wrap up the current design using the ILI9341v controller display, we wish to move to a 800x480 display with DSI interface and a more current controller. This topic appears to be a daunting task so will have some questions at a later time.

For now, loving the quick simulator runs we are doing with TouchGFX.

As a suggestion - consider if possible to allow the CubeMX to alter the graphics controller that may be present on the Brand x display. I think one of your competing GUI tools allows for that but openly we found yours to be the easiest to just power and run. Took us minutes to generate our first screen.

[JLema]

Thank you for you help.

I have the same steps in mind that you describe.

Best regards.

[Martin KJELDSEN]

@Mon2​, you're right when you say that there's a strong bond between what's generated and what that code is generated for, but screen definitions can be ported almost directly into another project.

Let's say we created a project with CubeMX and developed a TouchGFX application for an STM32F4 driving a 800x480 DSI display. We then wanted to upgrade to an STM32F7 driving the same display and the size of the memories is the same or larger. This is just a sunshine scenario. Any hardware configuration of the new setup is then handled in the new CubeMX project. Once the TouchGFX application is bootstrapped we could then in theory copy the project file and screen definitions and TouchGFX, blind to any hardware configuration, would then simply ask HAL to give it a pointer to the current framebuffer (Configured in CubeMX) or ask Chrom-ART to copy something from QSPI flash. Since the CubeMX configuration of the applications dimensions is the same, TouchGFX will render the same amount of pixels per screen as in the previous project to whereever it is told to by the HAL.

That's the quick and dirty version. I hope to be making some of this a lot more clear in an upcoming article "Understanding TouchGFX".

Regarding the change of displays, feel free to contact me. Yes, changing DSI displays can be quite a task. Glad you're enjoying the simulator and the designer - As we're expanding it with new Widgets (Bringing some to life that are already present in code) it's becoming easier to do more and more from the Designer, saving a lot of time.

I'll try to forward your suggestion about display controllers in CubeMX. Thanks!