git workflow with STM32CubeIDE + .ioc file generation causing tedious merge conflicts

PLane.1 · ‎2020-05-27

Using the STM32CubeIDE + .ioc file generation we are seeing very tedious merge conflicts with the .ioc file.

To give a small taste of the .ioc merge conflict:

<<<<<<< HEAD
Mcu.IP4=SPI1
Mcu.IP5=SYS
=======
Mcu.IP4=SYS
Mcu.IP5=UART4
>>>>>>> My Commit

Simple enough for a small conflict like this, but becomes exponentially more annoying the larger the conflict is, or the larger the project/.ioc file is. To have to manually handle these types of conflicts during the development process does not allow us to follow a smooth git/development workflow. I can only imagine it will occur with any rebase/merge with a .ioc change in both, and that time adds up quickly.

Is there a way to avoid these time consuming conflicts? a better/recommended workflow for using STM32CubeIDE + git?

What we came up with is, initializing the .ioc with all of the setup we think we need, and then develop. Which is a work around at best, because any changes or modification will result in the same time consuming conflict.

Cartu38 OpenDev · ‎2020-05-29

According to me i would strongly advice you to not ry to solve any confict within .ioc file. Such file is kind of private file (tool metadata). You have to take it at it is. But of course always good to get everything under revision control (Git is a good choice by the way :-)) Just git add & commit it !

PLane.1 · ‎2020-05-29

So the conflict happens because SPI was added to master, and UART3 was added to the branch. Then rebasing master with the SPI changes the .ioc has different values assigned to Mcu.IP# and MCU.Pin# These appear to be randomly generated numbers based on what the .ioc is adding, so as long as the # is unique and incrementing everything works. The conflict can not simply be ignored and committed, that is not how git works. And if the .ioc file doesnt have the correct information then the project isnt generated correctly. So this adds unwanted overhead.

The problem I am having is not with HOW to solve the conflict, but that the conflict is a major inconvenience during development based on the .ioc being a list of Mcu.IP# that correspond to what was added in the .ioc, so using git, and developing non-linearly with multiple developers adding peripherals as features are being added.

This type of conflict will happen repeatedly during development based on the way the .ioc works. In absence of a recommended git workflow with this platform that doesnt cause this issue. I would like to recommend that ST consider the STM32Cube ecosystem's use with git more closely. The .ioc in this case is not making development and source control any easier, especially if you want a clean history.

berendi · ‎2020-05-29

> developing non-linearly with multiple developers adding peripherals as features are being added.

I can't even imagine how it could work at all. Developers working in parallel grabbing resources that were free at the last merge? What happens if two of them picks the same pin? Or a more subtle one, pick two peripherals which need the same DMA channel? The same PLL output at different frequencies? Someone took the only timer yesterday which can trigger the ADC?

> What we came up with is, initializing the .ioc with all of the setup we think we need, and then develop.

Right.

Make a single person responsible for assigning hardware resources to features, who can carefully consider all dependencies.

Then freeze the .ioc hard.

PLane.1 · ‎2020-05-29

Sorry if I misrepresented the first point, There is clearly communication to what hardware we intend to use, and a plan for that. So its not completely the wild west as implied. To be clear the issue is not that the users chose the same peripheral, its all in the way that the .ioc is structures to work by creating a numbered list.

So in the case where the .ioc is generated with all peripherals at the start. Usually when developing with git its better to implement what is needed for that feature? And this recommendation makes me think the .ioc does not play well with git, and this is a workaround for it. There are bound to be .ioc changes during development, I am not aware of a time that I have every not made some change during the course of a project.

We can certainly consider doing this and setting up the .ioc file all at once.

Miles1 · ‎2020-09-01

> I can't even imagine how it could work at all. Developers working in parallel grabbing resources that were free at the last merge? What happens if two of them picks the same pin?

This is a common challenge in software development that we've already found plenty of solutions for.

If the .ioc format was designed more carefully by ST, we'd be able to see these attempts to reuse the same resource as merge conflicts. If these merge conflicts are resolved incorrectly by the developer, then CubeMX should catch this (for example, produce an error that two peripherals are configured to use the same DMA channel). This process is similar to how you can manually resolve merge conflicts in c/c++ code, but if you make a mistake, the compiler will detect the problem.

Unfortunately, the existing ST tooling does not seem to consider the use case of having multiple developers collaborating via git. I also wonder if that's the workflow they use internally.