4

Normally, I used to include device specific headers & sources provided by the chip vendor (ST) and CMSIS-Core headers in version control. There are not many of them and I didn't have a habit to update them. I use STM32 microcontrollers, but I don't use the CUBE framework or the Standard Peripheral Library.

Recently, I needed to use CMSIS-DSP libraries. CMSIS-DSP library comes with a large number of header and source files. I decided to use the precompiled library (libarm_cortexM4lf_math.a), which is around 5.4 MB. But now I started to question if they should go into the version control.

I know that managing the binary files in version control isn't a good idea. But as far as I know, CMSIS is not updated very often. So I'm confused. These are the options I can think of:

  1. Include CMSIS headers and static binaries in repo: It may be good idea if I decide not to update these libraries. CMSIS itself doesn't get new releases very often and even if a new version is released, it may not be necessary to update it in the project. Or I may skip a few releases before I update it in my project.
  2. Include CMSIS header and source files in repo: Similar to option 1, but git will be happier to work with text files instead of a 5+ MB binary. But I'm not sure if letting 3rd party code changes to contaminate my source history is a good idea (Option 1 suffers the same problem, but header files only).
  3. Don't include CMSIS in repo: This results in a clean repo, but then I have to manually copy library files into project directory after cloning the project. I can also specify a system wide installation folder for CMSIS and add it to the project but it causes a "works-on-my-machine" situation.
  4. Find a way to fetch the library automatically: The first thing comes to mind is git submodules. However, I'm not sure if fetching the whole CMSIS repo will work, because I need to restructure it as there are lots of unneeded files, including precompiled binaries. I guess I need some kind of post processing script?

What is the best approach here? Can there be other options?

There is a similar question here: Storing third-party libraries in source control It seems people have different opinions about the subject. But I believe using CMSIS in an embedded C project is a specific case and deserves its own question.

Tagli
  • 2,412
  • 2
  • 11
  • 14
  • if they are part of the project, are source code required to build the project the obviously they need to be there. Likewise source code or built libraries that are also part of the project. But these items could be in one big repo or in separate but if it is source code to the project shouldnt it be controlled? – old_timer Feb 01 '20 at 01:03
  • How much will you modify? What is your process? What do you gain by each approach? Some people never allow binaries in source control as a policy. Trying to manage software you will never change is a waste of time, given no other barriers. Some processes will mandate that everything must be built from source. Including an archive bundle with patches in version control that integrate in a build will often work well. There is no right answer as it depends on unknown future events. I would not put the binaries in source control. Build info is often as important as source. – artless noise Feb 01 '20 at 16:34
  • @Tagli Very interesting question. I am wondering how about the option #4 but not to the whole CMSIS library but a subset of it hosted elsewhere? – KansaiRobot Jul 12 '21 at 07:16

1 Answers1

2

IMO embedded projects which use CMSIS should have the used version included. CMSIS is not as standardized as C standard library and very often newer versions are not compatible with the older ones.

The linked post is 12 years old and (IMO) the size of the repo is far not as important as it was then. Storage, memory, computing power and uplink connection bandwidth of the computers used by the embedded programmers nowadays are not comparable to the computers used 12 years ago.

0___________
  • 60,014
  • 4
  • 34
  • 74
  • The linked post is still relevant. The code size represents an effort to maintain the code. LOC, etc. metrics. If you do not significantly modify the source, then upgrade paths are easier. If a CMSIS version upgrade breaks compatibility, there can also be 3rd parties that provide patches or revision control systems. Why would you put something in a revision control if you are never going to change it? A release tarball with a SHA or other reference is fine. If a project is 100K upward lines of code and your changes are a patch file of 40 lines why use a repository. – artless noise Feb 01 '20 at 16:11
  • @artlessnoise uC projects are significantly different than portable C projects. Tarballs are extremely rare here, and projects (real code lines) larger than 100k lines are even less common than the tarballs. Your comment is from the another universe – 0___________ Feb 01 '20 at 16:17
  • Everything I said applies. The 100K/40 was a ratio; that is what is important. If you don't significantly modify things repositories are a barrier to being productive. Also, your answer about things being different now, seems in direct contrast to your complaint about my comment. – artless noise Feb 01 '20 at 16:25
  • After ~1 year asking this question, I concluded that this answer is the most practical one as it allows simply git clone & build. 3rd party libraries don't need to be updated often in my projects. – Tagli May 15 '21 at 08:40