Dear ST,
This has been reported in other posts before, but I would like to make a clear suggestion.
The problem is that IOC file changes are hard to merge in Git (or in other SCM) with diff tools because:
- Some parameter names use indexing. Inserting something means changes on following lines.
- Some parameter values are lists of items on a single line. It is painful to merge 1000 characters long line.
- It is not intuitively clear what some parameters mean. There's no grouping or context. Risk of making bad merge.
Therefore I make a suggestion to switch over to a file format that is still human readable, has a hierarchical structure and is source code tools friendly. It would be even better if it is based on some existing widespread format so developers can build their own development tools to parse or create IOC and use it as a SSOT (single source of truth) or as an output from other SSOT system.
Two such standards come to my mind: YAML and JSON.
I wouldn't recommend XML because of tedious end tags and high risk of breaking the syntax with diff tools. Linux (and Zephyr) devicetree would be interesting, but it is a bit hard to imagine how it fits in.
A smooth transition by supporting old and new file types loading and having option to choose save format would be great.
One final idea:
Add (future) support for hardware variants and versions. Sometimes in projects the goal is to have a single firmware that runs on slightly different PCBs and sometimes during the product lifetime PCB changes are made that place stuff to other MCU pins. In that case, in the very early start-up phase firmware must detect hardware variant and version and pick the right configuration. It is not just about file format, but picking the right file format and its structure is important to make it work. (At least some) AUTOSAR Classic MCAL tools have this feature.
