Touch GFX working within a CubeMX framework

[Harvey White]

The last time, admittedly a while ago, I tried creating a touchGFX project.

It didn't work.  Nothing would link or compile properly.  Most of the included files/referenced files could not be found.

I used CubeMXIDE, while including the TouchGFX files and trying to make it an ordinary project.

That didn't work.  One problem I remember is that one thing (TouchGFX?) needed to be compiled under root and Cube MX did not.  Or vice versa.

The only way I found to get anything working was to use the TouchGFX tools to combine an existing program.  Using CubeMX did not work at all.

Before I try to make TouchGFX working, has this been solved?

Is there a way to simply encorporate the TouchGFX files in a standard CubeMXIDE project?

 

[Mohammad MORADI ESFAHANIASL]

Hello @Harvey White ,

TouchGFX and CubeMX work in conjunction. You can easily choose the board that you would like to develop your application for, and TouchGFX creates relevant STM32CubeMX, STM32CubeIDE, EWRAM, and MDK-ARM projects to work with. Therefore, you just need to open the project based on the compiler or IDE you want to use, and all the required files will be in the project.

Hopefully, this would encourage you to give TouchGFX another try. :grinning_face: 

[Harvey White]

Oddly enough, I decided to try a TouchGFX project.  Since it is on a custom board (Nucleo F767 for now, SPI interface, 320 x 240 display with touchscreen.  CubeMXIDE latest.

The first problem is that this board configuration is not supported in TouchGFX (no board says "custom board").  Ignoring that, so far I have a program structure with gaping holes where software ought to be, and isn't.  It's looking for a touchgfx directory, then the HAL drivers, and so on.  Likely this is because no board has been selected. 

I do not use BSP drivers except on one of your DISCO boards, which is currently not the product.  I have not found any documentation that shows how to bring up a TouchGFX project on custom hardware, especially using what's built into CubeMXIDE.

Any suggestions?

 

[Mohammad MORADI ESFAHANIASL]

Have you checked out these tutorials? 

https://support.touchgfx.com/docs/development/development-introduction

We have plenty of explanation for how to run a project from ground up.

[Harvey White]

I have checked out the tutorials. 

In your touchGFX generator, you are given the options of generating code for many different ST micro boards.  There is no option for a custom board. 

If you do not select a board, the entire low level framework is missing and the program cannot compile.  I would like to see a framework that allows you to put in your own drivers.

Please note that unless I am supporting specific hardware on a specific ST designed board, I DO NOT want to use BSP drivers, since they are (IMHO) poorly documented and have no particular connection to code written in the IDE.  The people who write the demos apparently don't talk to many of the people who work with and in the IDE. 

So my problem is, can I use the touchGFX generator on a custom board, NOT picking a "it's similar" board from the ST board list?

Where are the instructions to do this?

How does touchGFX generate code for a custom board?  Where are the configuration files or the configuration dialog in the TouchGFX generator?.

It's not a hardware problem.  The entire TouchGFX file structure is not generated.

 

[Mohammad MORADI ESFAHANIASL]

Hey @Harvey White ,

I feel like you are starting from the wrong point. If you want to work on a custom board, then you should start your project from STM32CubeMX, not TouchGFX. After you have created your project in CubeMX, then you can enable TouchGFX under 'Middleware and Software Packs'. Then, when you set the required settings and generate, there will be a 'ApplicationTemplate.touchgfx.part' under TouchGFX folder in your project, which is tied to the framework you have set. 
As I mentioned previously, all these steps are explained in these documents:
https://support.touchgfx.com/docs/development/touchgfx-hal-development/generator-how-to/enabling-touchgfx-generator

I hope this one gets you going.

[Piranha]

Consider stopping the self torture...

https://www.reddit.com/r/embedded/comments/wfw4if/how_does_lvgl_compare_to_touchgfx_in_terms_of/

[Harvey White]

My, life can get complicated.

I have a graphics solution.  Panels, geometric shapes, monochrome and color text, buttons, oscilloscope grids, progress bars, animated icons, flood/fill, object alignment within a panel (where it makes sense), clipped drawing in panels, 32 bit color virtual images converted to the display of your choice.  Panels own graphics objects.  Redraw the panel, and the children are redrawn, all of them, turtles all the way down........

I wrote it. It's in C++ (so is everything if I can help it, C++ does very well for graphics classes).  Adding features and modifying things is easy.

What I wanted was to avoid having to write the graphics designer.

I tried emWin:  Low level drivers are missing unless you pay lots of money (emDOS is free for ST).  STemWin used to work, and is no longer supported.  The documentation for a custom board is quite poor.  It does have a decent GUI designer.

I tried LVGL:  never got past the "designer is limited, so there" part of it.  As in many products, I found the documentation for custom boards poor.

I tried uGFX:  There is a product that, IMHO, follows the old adage "He who cooks for everyone cooks for no-one".  The drivers are very poorly documented, the customization lacks documentation, it's an "install the library" product, and while I did get it to boot up partially, their solution fell apart after that. 

I tried TouchGFX:  The documentation for custom boards is miserable, and (seeing this thread), completely lacking.  It has the typical STMicro "just adapt an example" approach.  If I do it that way, I put a lot of effort into understanding someone else's badly (or at least absent the philosophy) design.

Every program, every last one, has a "you're going to do this with it" and a "you're going to use it this way" and then the derivative of that is "see how easy it is?". 

IF I'm going to use someone else's code, I want it well documented enough that I can deduce the philosophy, figure out what the designer thinks I OUGHT to be doing, and then modify the code if I need to.  This is missing within TouchGFX (and thanks for that link to the commentary, TouchGFX would not work well for me anyway).

Whatever graphics solution (other than mine, which of course does this) is going to have to work in a FreeRTOS (or maybe emDOS) framework, using low level drivers generated by CubeMX (Had enough writing bare metal drivers with AVRs), be able to handle remote displays, RF mesh networking, I2C peripherals, SPI peripherals, and multiple networked processors (working on that one).  Displays need touchscreens, too.

It seems as if I need to write that screen designer, though.

So I'm not seeing a good graphics solution out there other than my own.  I was hoping.....

Apparently the people who design the software never really used it.  (seen that before).

Thanks