Same TouchGFX project for multiple CubeMX files in the same CubeIDE project

[PontusL]

Hello,

To elaborate on what I mean and wondering about with the subject using an example:

I am using one CubeIDE project to develop an application for two different hardware boards using the same MCU. Each of these boards have a CubeMX file associated with it since the pinout of the boards differ somewhat. But most of the functionality is the same between the boards, and they share the code on an application layer. I use ifdefs and build configurations to build the desired application. 

Right now, I have a double set of all TouchGFX related files, one in the CubeMX folder for HW1 and one for HW2, which are a complete copy of the other. I instead want to move this code to the application layer level since the code is the same, and changes to the GUI would be implemented to both hardware applications with one change. 

How would I go by doing this? Since the code generation is coupled tightly with CubeMX, can it even, somewhat easily, be done in a reliable way? 

I guess this somewhat also extends to how one would maintain and update a GUI which is used in multiple projects in an easy way. In my head, having the GUI as a module that would be loaded into the desired application would be an option, but I have not found any source about this being done. Does anyone have any input or inspiration here?

Regards,
Pontus

[MM..1]

I mean simple way dont exist. I sometimes use method hw1 hw2 manage manualy and have only one project.

[PontusL]

Could you elaborate please? 

[MM..1]

Primary CubeMX is wizard for create projects... As i write create one project and manage more hw variants in it.

Exist many ways try explain hw1 hw2 diff and we can show example.

[Andrew Neil]

I think you will need one project per board.

Put your "shared" files into a common folder, outside both of the projects, and then link that into each Project; eg:

 

---+---project1---+--- .project
 | |
 | +--- .cproject
 | |
 | +--- .mxproject
 | |
 | +--- project1.ioc
 | :
 | etc
 |
 +---project2---+--- .project
 | |
 | +--- .cproject
 | |
 | +--- .mxproject
 | |
 | +--- project2.ioc
 | :
 | etc
 |
 +---common-----<your folder structure>

 

Note: this is the structure in your filesystem - not the CubeIDE's 'Project Explorer'

 

Now, in the CubeIDE's 'Project Explorer', right-click one of your projects, and choose New > Folder

Click on 'Advanced', then check 'Link to alternate location (Linked Folder)':

then you can browse to or type-in the location of your common folder.

Repeat for your other Project(s).

Then the CubeIDE's 'Project Explorer' will show the common folder within both (or all) of your projects:

But note that the common folders don't have the 'C' on them - which would mark them as Source folders.

To fix this, in the CubeIDE's 'Project Explorer', right-click one of your projects, and choose New > Source Folder

The common folder will now be available to choose:

So choose it.

Note that this doesn't duplicate the folder - it just reclassifies it as a Source folder (so adds the 'C' to the folder icon)

Repeat for each Project.

Now you will see that the common folders do have the 'C' added:

 

If you have headers in the common folder, you will need to update each Project's Include Paths.

Simplest way is to right-click on the folder, and choose 'Add/remove include path':

 

Repeat for each Project.

 

"And that's all there is to it!"

#CommonFolder #SharedFolder #SourceFolder

[MM..1]

Subject is about TouchGFX created from ioc. Then update GUI have in generate script update only one .cproject file , too common isnt real terget when ioc generate TouchGFX folder...

[Mohammad MORADI ESFAHANIASL]

Hello @PontusL ,

As you mentioned the generated code from TouchGFX requires the corresponding STM32CubeMX project. You've also highlighted an excellent solution for separating the GUI from the hardware implementation, which can be easily done.

You'll need your specific application that you already have for your boards. Additionally, you require a third project based on the TouchGFX simulator to manage your GUI. You can then import this GUI into your specific board application by navigating to Edit -> Import -> GUI from within your hardware project.

Importing a GUI to your project

I hope this helps you, don't hesitate to ask more questions

[PontusL]

Hello Mohammad,

This would still lead to me having two, or three(?), versions of the same GUI application in my project. Do I understand you correct in that there is no way for my CubeIDE project, which has two nested projects for two hardware configurations, to use the same set of TouchGFX related code? 

Also on another note, is there a good way of doing the "Edit -> Import -> GUI" from the command line? I currently do this from within TouchGFX Designer, but I would likely rather automate the process. 

Regards,
Pontus

[Mohammad MORADI ESFAHANIASL]

Unfortunately, there is no instruction for importing a GUI through command-line. 

And, my suggestion was to have 3 different projects, but you only need to change one of them, the other two is like a copy paste, which is done by importing the GUI.

Also, as @MM..1 mentioned, TouchGFX and STM32CubeMX are tightly connected which means there are some settings of the CubeMX project that are reflected in the TouchGFX project. Therefore, it is not possible to just use the common TouchGFX files between the two projects. 

Best regards,

[Mohammad MORADI ESFAHANIASL]

Hello @PontusL ,

Have you made any progress on this topic? 

[PontusL]

Hello Mohammad,

No, not really any progress. What I do is that I develop my GUI for one hardware and then use the import gui functionality in TGFX designer to import my changes for the other hardware. It works but is a bit tedious. I also dislike having duplicate setups of the touchgfx files, since my project is fairly large, but it works for now. 

 

Solution: You can't have one TouchGFX project for multiple CubeMX projects. 

 

//PontusL

[Mohammad MORADI ESFAHANIASL]

I'm glad that at least you are progressing, but I understand that unfortunately, there are no better solutions.
Could you select an 'Accepted Solution'?