How to conditionally select between pin configurations at compile time?

[SHugh.2]

We have a project where, due to various issues found during development, I've modified the PCB layout and changed a few pin allocations.

Is there any way to include multiple configurations from CubeMX and select between these at compile time?

This would allow us to gradually transition from the old hardware to the new rather than having to upgrade all units to the new PCB before we can release any software updates.

It's something I've done many times in the past on the PIC where I/O was configured in the code, but as it's all handled within Cube for the STM32 it isn't as obvious how to achieve it.

[ONadr.1]

I would do it as a conditional translation depending on some value corresponding to the HW version.

[SHugh.2]

That's what I'm hoping to do, however we can't work out how to do such a translation. In other toolchains I've just set a #define for the hardware revision and had #if #elseif compiler directives to select which set to choose.

I should say I'm not involved in the software side of things here, I'm purely hardware for this project so I have very little knowledge of the STM toolchain, however I'm told by colleagues who are doing the software that they can't find a way to achieve this.

Any tips would be most welcome.

[Paul1 · Accepted solution]

Workaround for Compile Time:

• Create a project for each board
• Put all your own common/shared code in folder(s) separate from the projects
• Link that folder to each project = You can define additional source & include paths in project: Project>Properties>C/C++ General>Paths and Symbols, Then Source Location, and then Includes.
• Use a header file in each project to define things for common code (Could #define for IO ports, though better is to define a higher level IO routine that calls a custom routine in each project like IO_SetDriveSignal(bool bActive) that hides the customization of each board from the higher level code and creates more readable code.

We use this method for a batch of boards that share a common circuit for about half the STM32, with different IO on the other half. Even allows us to use same bootloader for all those boards, just putting an ID in a "config" FLASH block to differentiate.

Paul

[SHugh.2]

Thanks, that sounds like what we need. I'll pass it on and see how the team gets on with it.

One question, does that approach cause any issues with source control? I'd imagine that is why common code is in a separate place, but not sure if anything else may be problematic.

[ONadr.1]

If the program is well written, then no problem should arise.

[Andrew Neil]

"I should say I'm not involved in the software side of things here, I'm purely hardware for this project so I have very little knowledge of the STM toolchain"

So wouldn't it make more sense for (one of) your colleagues who is/are doing the software to be posting this?

[Paul1]

We kept the similar projects and shared code in one repo which made easy for us, but there are other styles that may work.

[SHugh.2]

Maybe, but I've got experience of doing this on other platforms and they haven't, so it's pretty much six of one and half a dozen of the other.

[Andrew Neil]

If you have your version control "root" above everything, that shouldn't be a problem.

eg,

vc-root----+---- Common stuff ...
           |
           +---- Cube Variant 1 ...
           |
           +---- Cube Variant 2 ...
           |
           :
           :
           etc...

Many VCS support some kind of "sub-project" structure, so that could be an alternative.

In Git, it's Submodules...

https://git-scm.com/book/en/v2/Git-Tools-Submodules#:~:text=Submodules%20allow%20you%20to%20keep,and%20keep%20your%20commits%20separate.