2024-02-28 08:42 AM
In a project there are multiple MCUs of the same type. Each of these must have the same software on it and decide at startup which role they take. Some pin definitions are common for all the MCUs (like clock, identification, communication,...) and others differ completely, hence need to be initialized differently.
It is a requirement that all of these MCUs are having the same software on it for update reasons. And preferrably changes pin definitions could be made in CubeMX.
One option would be to have a CubeMX project for each of the MCU role and copy the generated code by hand to a overall project. This involvels a lot of hands on which is cumbersome and error prone. But since not too many changes are expected certainly doable.
I've looked at nested projects. But since only one .ioc file can be active within one IDE project not really an option.
There is also the option of Project references. But I could not find any documentation on the purpose of these and how it would work.
Is there a good way to handle this situation in CubeIDE?
Solved! Go to Solution.
2024-02-28 02:42 PM - edited 2024-02-28 02:43 PM
> But since only one .ioc file can be active within one IDE project
Just use the standalone CubeMX instead of the CubeIDE "plugin". The former lets you have as many .ioc variants as you want, name them as you want and keep them where ever you want.
2024-02-28 08:59 AM
Sounds like a nightmare if you're auto-generating all these individually. Not really designed for hybrid functionality.
Can't you make one project that combines all functionality and merge in the salient portions from the auto-gen'ed pieces. CubeMX disperses rather than centralizes the code. Pin / Peripheral level differences in initialization likely to be in the MSP files.
You could use a loader that selected the appropriate sub-function application.
Then each would need it's own unique address within the FLASH memory space, you'd want the code setting the SCB->VTOR to perhaps do this automatically based on the symbol for the Vector Table, rather than #define in the stm32_system.c / SystemInit() code.
Decent merge tools could make some of this manageable and scripts.
Better would be to rationalize the multiple functionality and dispense with auto-gen nonsense. Decompose the projects so you have the common pieces for the board, and separate source files/directories for the sub-functions
2024-02-28 09:24 AM
Not really designed for hybrid functionality.
That was my suspicion.
Can't you make one project that combines all functionality and merge in the salient portions from the auto-gen'ed pieces.
Shure, that's what I meant with one CubeMX project per role.
Yes, a loader will need to decide which role to execute.
Alright, thanks for the hints, I'll get to work then!
2024-02-28 09:50 AM
>Is there a good way to handle this situation in CubeIDE?
I just can tell, how we do (at work) :
- if not many variants (maybe 15 ), a dip-switch is there, for info: what to be/do here
- if many , a local mounted eeprom is in every machine, for info...
+
The "basic" program is set in Cube/IDE , make a project with all defined, whats always used.
Then after start cpu reads info (or switches), "who am i " ; now other specific peripherals are set and used then.
This way only one "standard" program to manage, but many even very different use cases possible.
2024-02-28 02:42 PM - edited 2024-02-28 02:43 PM
> But since only one .ioc file can be active within one IDE project
Just use the standalone CubeMX instead of the CubeIDE "plugin". The former lets you have as many .ioc variants as you want, name them as you want and keep them where ever you want.
2024-02-29 12:27 AM
Thanks for all the inputs.
There will be one pin which has an array of resistors connected to it. At startup, the analog voltage is read and this defines the role the specific MCU has to take.
I think I'll go for one "main" IDE project with CubeMX "plugin" for the common part (also the stuff described above) and use seperate CubeMX projects for each role, then copy its initialisiation to the "main" project by hand. Not the most automated way, but doable since not too many changes are to be expected on the hardware side.