Overview: Our workflow is described in this section.
- IDE: STM32CubeIDE
- Version Control: git
Within git we track: along with other folders for our Src
- .cproject
- .project
- Debug.cfg
- Debug.launch
- myProject.ioc
- STM32H743ZITX_FLASH.ld
- STM32H743ZITX_RAM.ld
- Core (Folder)
With CubeIDE and git we are able to successfully clone, generate .ioc and build our project successfully. The generation properly brings in the Drivers folder, and generates the Core contents. This also leaves any manual changes to the .cproject untouched. We prefer to follow the git workflow to not track generated files, as they can be well generated.
Problem:
1: We have a need for multiple configurations in our software to support various versions/needs of the hardware we have. This way we have a single code base for the multiple similar software/hardware versions of the products we have. This would include software functionality being included/removed in the build with a #define or similar tag to support different product features/execution. This seems fairly straight forward in my opinion.
2: The part that becomes more difficult is handling .ioc/project differences, and generation. Some of the versions may not use the full list of peripherals we are using and we would like to disable these from being generated/building the project.
3: In trying to solve this problem, continuous integration (CI) came to mind, tools like Jenkins. This would allow us to automate the multiple builds to confirm a change for one project does break another. Has anyone been successful using STM32CubeIDE toolchain with Jenkins? I have found a few posts on the topic asking for help, with little to no helpful outcome. More information would be helpful.
Note: I have tried the CubeMX command line generation (ST Document UM1718 V31 Dec19) only to find out the project generation command overwrites the .cproject manual settings, something the IDE does not do in our current setup.
4: We are looking for input on how to modify our workflow, git repo or toolchain to better achieve this.
Potential Solutions:
A: Use the current git repo tracked files to generate code needed to build, use build options to configure software options. Pros:
- works within the IDE
Cons:
We were unable to get the CubeMx cli to work properly without writing over the manual .cproject changes we made, therefore Jenkins is not easily possible.
Does not support .ioc configuration based on product version (at least as I am aware of)
B: Use the current git repo tracked files, but include a common source folder and a project folder with individual project folders for each version of the product.
Pros:
- Should work with IDE
- Allows multiple .ioc configurations to be able to drop certain peripherals from a product not using it.
Cons:
- More git complexity in tracking the project, and versions.
- Building is still manual (No CI/Jenkins), so common sources changes would need user to manually build multiple projects to confirm stability.
- We were unable to get the CubeMx cli to work properly without writing over the manual .cproject changes we made, therefore Jenkins is not easily possible.
Suggestions on workflow/toolchain limitations and improvements, or other workflows/toolchains would be helpful.
