STM32CubeIDE projects: how to use objects generated in main.c file in other C files?

[HTD]

The goal is to not write my entire hardware handling program in main.c file, as tutorials often show.

I use TouchGFX, the project for Visual Studio doesn't even see main.c file or has any access to the hardware part of the code. It's OK, I use VS only for the UI part. I code the hardware handling part in STM32CubeIDE.

Let's say I enable I2C bus in .ioc file. That automatically generates code in main.c, the problem is, I want to make a driver (in another file) that uses that object (initialized I2C object) in my own piece of code, let it be even C++ class.

I already figured out how to bridge 2 projects (hardware part and UI part) with conditional include of a bridge file, that includes main.h and use externs. The condition is of course "#ifndef SIMULATOR". For the simulator I make dummy objects that just simulate the actual hardware. It all works.

The problem is - my bridge file includes main.h and has access to most HAL, but it doesn't see anything defined in main.c. The CubeMX code generator writes everything in main.c. How can I make my custom code contained in other file (my bridge file) see the objects defined in main.c? Is there a standard way of doing this, or maybe a clever trick?

[wired]

I was able to make everything still work with the Set Unused Pins to Analog checkbox after reserving the debug pins. I then made a copy of the project and tried checking the box to create separate .c and .h files for each peripheral. This resulted in my main.c file losing all of its FreeRTOS-related information. My tasks were no longer declared, and my task handling functions disappeared as well. There is definitely something wrong with STM32CubeMX and its handling of the project settings. Maybe the checkbox is only meant to be set at the beginning of a project, before anything is modified.

[wired]

Apparently, as an undocumented 'feature', the RTOS-related information gets automatically created in FreeRTOS.c instead of main.c when you check that box. And the body of my tasks got lost, because it created default bodies.

Sometimes these 'helpful features' aren't so helpful.

[wired]

Back to the hard fault in touchgfx_init() when the Texts::setLanguage(0); initialization occurs. I give up. You win, ST, I'll just keep all my hardware initializations in main.c.

That was a waste of an entire day...

[HTD]

For what I tested, TouchGFX needs all automatically generated initialization in main.c. At least, I haven't figured out how to change it and make it still work. However - I moved my custom code entirely to different files to make the code clean. It was super tedious and a little tricky to introduce new files and includes to all IDE-s involved (TouchGFX, Visual Studio and STM32CubeIDE), but I made an automated tool for that: https://github.com/HTD/TouchGFX-HAL-Bridge - I tested it only with my STM32H747I-DISCO board, I'm curious how it would play with other setups. The tool just adds a 4 new files, 2 code files and 2 header files. One part is a "core", for the hardware part (built for the device), one is for UI C++ code. BTW, the files are empty, it's just the template to connect the code that would otherwise go to main.c, now it goes to HALBridge.c and the methods are exposed as HALBridge class static methods to be called by the Model class. Under the hood - it just changes the project files to link the new files and include an additional include path.