Share code between Libraries

[Ubus99]

Hi, I need to support 6 libraries for 3-5 MCUs each, and recently I have struggled to keep up.

Many users complain about bugs I thought I squashed ages ago, only for me to realize that I never updated the code for that specific MCU.

Is there a way to synchronize the projects?

The code is nearly identical, only the #include for the header file in my .cpp file and the driver included in that header change.

[Peter BENSCH]

Include files (.inc) can be inserted into the project either as a physical copy or as a relative reference (aka link). Such a link then points to a single file within your file system so that all projects can share it. You would therefore only have to update these include files included by the link in order to be able to use this current version for all connected projects.

But you must not forget that after a change, all the projects concerned must be recompiled and linked. 😉

Does it answer your question?

Good luck!

Regards

/Peter

[Ubus99]

Hi Peter,

I think we are talking about two entirely different things.

I write static libraries and distribute them over Git.

Each of these Libraries consists of one header to interface and multiple c/cpp files.

Since many users also use multiple MCUs in one workspace, I name all of my Libraries "functionChipName" to make them easy to distinguish.

Consequently, each c/cpp file also needs to include the header with the right name, and because static libraries are locked to one specific chip, the header file also needs to include the corresponding HAL driver.

I would like to know if there is a way to synch everything except those include statements, so that I can change the actual function code centrally, and have it compiled and committed for different target chips.

[mattias norlander]

Hi,

What you are looking for is a common use case. In my view it is quite similar to the use case when customer wants to develop multiple "versions" of their product which embeds different STM32 MCUs to optimize the BOM.

In most scenarios such customer is going to end up creating a CDT project instead of an STM32Cube project. The CDT project will allow you to specify the -mcpu=cortex-mX directive per build configuration. One project. Multiple build configuration to allow you to build libraries targeting different MCUs and including different header-files and source files. From a maintenance point of view this saves a lot of headache while till giving you the fleibility you need.

I don't know the current structure of your GitHub repo. Maybe this approach would be "incompatible" with the hard work you already have put into your project/code structure. If not, I would opt for this approach.

Your "library customer" can still use any project type of their choice (for example STM32CubeMX generated project) and still link your CDT built libraries. No issues. Maximum flexibility.

Are the libraries supplied as unmanaged or managed projects? In other words do you supply a custom makefile or is the makefile auto-gengerade (managed) by CubeIDE?

In case of managed project:

File > New > C/C++ Project > Static libary > Empty project > MCU ARM GCC >

Select the MCU you target. Essentially this only sets the -mcpu flag...

You have a CDT project which is empty.

Now duplicate the build configuration and choose another MCU (mcpu). Set the source code, includes, defines uniquely per build configuration.

In case of unmanaged project:

File > New > Makefile project with existing code > Givet it a name to create IDE project files (.project/.cproject). Point to the code location

Select MCU ARM GCC > Finish

Might be some tweaks needed to find the Makefile depending on the file structure...

I think that roughly should summarize the approach you are looking for. Please provide feedback on what works / does not work. There may be some rough edges. We have some fixes in the next release for these.

If you want to rely on CMake as build system we can also give some guidance on this. There is a document in the pipe...