cancel
Showing results for 
Search instead for 
Did you mean: 

TouchGFX Code Builder - Driver Initialisation File Structure

Garnett.Robert
Senior III

Hi ST Employees,

When I build apps using cube I have the option of generating pairs of peripheral files '.c/.h"

I do this because if I want to create a custom startup I can simply delete the CubeMX generated versions and add my own without having to edit the generated file. I do this a lot as I create a folder with all of the necessary stuff in it; peripheral intialisation, interrupt routines DMA initialisation, wrappers, FreeRTOS functions which I can then import and use in any other project. In other words all of the code the peripheral requires to do the job all in one place, not spread out over many common files. i.e. modularise the system.

The .f/.c file pairs are a lot easier to manage.

When you don't check this box your main.c ends up being as long as your arm and the msp file is as long. A nightmare to maintain as well as being extremely cumbersome to edit.

The TouchGFX code generator doesn't give you the option of splitting out the initialisation files which means you end up with a horrible main.c and horrible msp. For example the current TouchGFX project I am working on has a main.c of over 2100 lines and that is with all of the cube user blocks removed: i.e.

/* USER CODE BEGIN Includes */
 
 
/* USER CODE END Includes */

The stm32h7xx_hal_msp.c is likewise long at about 1000 lines.

TouchGFX projects are generally quite complex using many peripherals thus making main and msp very long. TouchGFX also generate MPU functions which are quite long.

It would be a lot better if these along with the processor clock intialisation could be put in their own files. "The aim of the game is a small main"

Could you give this idea your consideration; it would help me a great deal.

What do others think?

Best regards

Rob

0 REPLIES 0