STM32CubeIDE project setup for collaboration with version control

[Miles1]

What is the recommended way to organize a project in STM32CubeIDE so that multiple teammates to share their work via git without thrashing the settings and paths that are user-specific?

It seems like we need to eliminate all user-specific and absolute paths and only use relative paths.

We'd prefer to use the "Add necessary library files as reference in the toolchain project configuration file" setting in "Code Generator Options" to minimize bloat. This works if we make a symlink to the STM32Cube/Repository/ in the same relative location for all of us. But then we get absolute paths in .cproject. Is there a way to have the IDE to use something like ${Firmware_Repo} for these paths?

The "Copy only the necessary library files" setting spares us the git-incompatible paths, and we can dedup these across similar projects by extracting those to a common directory and linking to that, but those are a lot of hoops to jump through.

Does anyone have tips to share on project structure for a nice git workflow that's also compatible with re-running code generation from .ioc files?

[Pavel A.]

>  This works if we make a symlink to the STM32Cube/Repository/ in the same relative location for all of us. But then we get absolute paths in .cproject.  Is there a way to have the IDE to use something like ${Firmware_Repo} for these paths?

Sure, yes. You can symlink the Cube repository to common absolute path, for example under /usr/src or /usr/share.

Then define an Eclipse "build variable" Firmware_Repo to that absolute path.

You can also make paths of Cube HAL drivers and other C files under the cube repository relative to such variables. This is more cumbersome.

Need to define a Path variable in the project's Linked resources, and add these files using these path variables.

In this way we share Eclipse projects among several developers working in Linux and Windows.

-- pa

[Miles1]

Thanks for the advice Pavel.

To clarify the steps:

1. Create a symlink to the stm repo:

sudo ln -s ~/STM32Cube/Repository /usr/share/stm_repo

2. Add this as a path variable in "Window > Preferences > General > Workspace > Linked Resources"

3. Use this path variable for the firmware repo in "Window > Preferences > STM32Cube > Firmware Updater".

Unfortunately, I can't figure out how to just use the "stm_repo" variable, and must instead use "/user/share/stm_repo".

4. Create a new project. It will point to the same path set in the firmware updater.

Unfortunately, there are still lots of paths hardcoded for my machine in this project:

// .cproject
 
// I assume this is fixed with some manual ${stm_repo} replacements
<option id="com.st.stm32cube.ide.mcu.gnu.managedb
uild.option.defaults.2130474423" superClass="com.st.stm32cube.ide.mcu.gnu.managedbuild.option.defaults" ... /home/miles/STM32Cube/Repository/ST
M32Cube_FW_F4_V1.25.0/Drivers/STM32F4xx_HAL_Driver/Inc ...
 
// Same with:
<listOptionValue builtIn="false" 
value="/home/miles/STM32Cube/Repository/STM32Cube_FW_F4_V1.25.0/Drivers/STM32F4xx_HAL_Driver/Inc"/>
 
// .project
 
// This uses relative paths (e.g. ../../../../STM32Cube) and is not portable across machines
<locationURI>$%7BPARENT-4-PROJECT_LOC%7D/STM32Cube/Repository/STM32Cube_FW_F4_V1.
25.0/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c</locationURI>
 
// .mxproject
 
// Not sure what to do about these. Should .mxproject be tracked by git?
SourceFiles=Core/Src/main.c; ... /home/miles/STM32Cube
/Repository/STM32Cube_FW_F4_V1.25.0/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_tim.c; ...
HeaderPath=/home/miles/STM32Cube/Repository/STM32Cube_FW_F4_V1.25.0/Drivers/STM32F4xx_HAL_Driver/Inc ...

So I'm not sure if I'm following your instructions correctly.

Also, it would be ideal if we could jump between firmware versions, and it seems like the only way to do that is with CubeMX. Is it possible to incorporate CubeMX into the workflow you're suggesting?

[Pavel A.]

Yes, you've shown definition of path variables at workspace level.

I prefer to define them at project level because then they go into the .project file and to version control.

<variableList>
		<variable>
			<name>STM32Cube_FW_H7</name>
			<value>file:/usr/src/STM32Cube/Repository/STM32Cube_FW_H7</value>
		</variable>
		<variable>
			<name>STM32H7xx_HAL_Driver</name>
			<value>${STM32Cube_FW_H7}/Drivers/STM32H7xx_HAL_Driver</value>
		</variable>
 ............. etc......

Then you can use these path variables in .project to pull in library .c files:

Note that in locationURI element the variable names occur without ${...}. It's so "intuitive" in Eclipse... ((

Also note that sometimes Eclipse replaces curly braces to hex codes : $%7B .... %7D

<linkedResources>
		<link>
			<name>Drivers/STM32H7xx_HAL_Driver/stm32h7xx_hal.c</name>
			<type>1</type>
			<locationURI>STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c</locationURI>
		</link>
........... etc.......

It takes some time to get used to this.

WARNING: Cube MX and its CubeIDE variant have no idea about Eclipse's linked resources. Regenerating code will break them.

 > Should .mxproject be tracked by git?

AFAIK, no

> Also, it would be ideal if we could jump between firmware versions

For this you can just swap the symbolic links under the common absolute root.

In my example above, STM32Cube_FW_H7 is a link to concrete version, such as STM32Cube_FW_H7_V1.5.0 . It can be redirected to, say, STM32Cube_FW_H7_V1.8.0.

--pa

[Miles1]

Thanks for all the help.

Wanted to clarify one more thing:

> define a Path variable in the project's Linked resources, and add these files using these path variables. In this way we share Eclipse projects among several developers working in Linux and Windows.

> I prefer to define them at project level because then they go into the .project file and to version control.

<value>file:/usr/src/STM32Cube/Repository/STM32Cube_FW_H7</value>

Wouldn't that only work among Linux users? That's why I was thinking it would be better to define the link at the workspace level (outside of version control) so it won't break things for the Windows users.

[Pavel A. · Accepted solution]

> Wouldn't that only work among Linux users?

On Windows we create the same absolute path as on Linux, so it works on Windows. Of course /usr/src actually becomes C:\usr\src but Eclipse is smart enough to form Windows paths properly.

In the projects you always use unix slashes (/) and make sure Windows drive letters are removed.

When the Eclipse workspace is not on drive C: (so C: is not the current drive) then more tweaks are needed.... but basically it just works.

-- pa