In this episode, we will use Docker to set up and manage our build environment.

The embedded world doesn’t always embrace the latest software development techniques. I acknowledged this in the previous episode about unit tests. Four years ago, when I started this series, I was totally unaware of Docker for instance. Since then, I have used it for non-embedded projects and I think it could have solved some issues I encountered in the past. I would like to share my experience and demonstrate that it can perfectly fit in an MCU project.

It’s been almost four years, and it’s about time to revive this series on CMake and STM32 (or MCUs in general, STM32 just serves as a tangible example).

Funny enough, I’m not working with microcontrollers anymore… This is a very recent change in my professional career, even if I think I will probably work again with MCUs sooner or later. However, I still use CMake to build C++ projects! The real reason to resume this series is my desire to write an article about Docker for builds. In 2020, I had never used Docker at all. Today, I use it very often, and I’m convinced it could have solved some build and environment issues back then.

In episode 4, we started to use C++ but we didn’t (*) add C++ specific compiler options. In this episode we will see how to do this. Because guess what: C++ and C are different languages and compiling C code with C++ specific options may not be a good idea 😄

Generator expression

(*) This isn’t completely true: to fix a linker error I suggested to add -fno-exceptions and this is clearly a C++ specific option. I didn’t show any CMake code but if you tried on your computer, I suppose you simply added it like this and compilation went fine:

In this episode, we will see that some files generated during the build are not deleted during the clean process and we will solve this issue with CMake, of course.

What is cleaned?

Once the build is done, we can have a look at the content of the output directory:

λ pwd
D:\cmake_stm32\cmake-build-debug

λ cmake --build .
...
[ 76%] Building C object CMakeFiles/nucleo-f413zh.out.dir/BSP/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_usb.c.obj
[ 80%] Building C object CMakeFiles/nucleo-f413zh.out.dir/BSP/Src/main.c.obj
[ 84%] Building C object CMakeFiles/nucleo-f413zh.out.dir/BSP/Src/stm32f4xx_hal_msp.c.obj
[ 88%] Building C object CMakeFiles/nucleo-f413zh.out.dir/BSP/Src/stm32f4xx_it.c.obj
[ 92%] Building C object CMakeFiles/nucleo-f413zh.out.dir/BSP/Src/system_stm32f4xx.c.obj
[ 96%] Building ASM object CMakeFiles/nucleo-f413zh.out.dir/BSP/startup_stm32f413xx.s.obj
[100%] Linking C executable nucleo-f413zh.out
   text    data     bss     dec     hex filename
   7564      20    2668   10252    280c nucleo-f413zh.out
mingw32-make[2]: Leaving directory 'D:/cmake_stm32/cmake-build-debug'
[100%] Built target nucleo-f413zh.out
mingw32-make[1]: Leaving directory 'D:/cmake_stm32/cmake-build-debug'

λ ls -l
total 632
-rw-r--r-- 1 z19100018 1049089   1427 avr.  29 12:17 cmake_install.cmake
-rw-r--r-- 1 z19100018 1049089  53118 mai    1 12:26 CMakeCache.txt
drwxr-xr-x 1 z19100018 1049089      0 mai    2 15:13 CMakeFiles/
-rw-r--r-- 1 z19100018 1049089  42893 mai    1 12:42 Makefile
-rw-r--r-- 1 z19100018 1049089   7584 mai    2 15:13 nucleo-f413zh.bin
-rw-r--r-- 1 z19100018 1049089  11154 mai    1 12:42 nucleo-f413zh.cbp
-rw-r--r-- 1 z19100018 1049089  21433 mai    2 15:13 nucleo-f413zh.hex
-rw-r--r-- 1 z19100018 1049089 203655 mai    2 15:13 nucleo-f413zh.map
-rw-r--r-- 1 z19100018 1049089 289884 mai    2 15:13 nucleo-f413zh.out

λ ls -l CMakeFiles\nucleo-f413zh.out.dir\BSP\Src\
total 52
-rw-r--r-- 1 z19100018 1049089 18416 mai    2 15:13 main.c.obj
-rw-r--r-- 1 z19100018 1049089 14956 mai    2 15:13 stm32f4xx_hal_msp.c.obj
-rw-r--r-- 1 z19100018 1049089  6224 mai    2 15:13 stm32f4xx_it.c.obj
-rw-r--r-- 1 z19100018 1049089  7916 mai    2 15:13 system_stm32f4xx.c.obj

Yes, it was 15:13 when I built the project. Let’s clean it and see what files are still here and what files have been deleted.

I have been using C++ for the last 4 years… there is no way I get back to C! This episode is not about explaining why I think C++ is better than C. It is simply about running C++ on STM32 with CMake. By the way: we will make LEDs blink!

Adding user code in code generated by STM32CubeMX

If we change the MCU configuration with STM32CubeMX and generate the code again, the previous files are overwritten. How can we create our own program if everything is erased each time the code is generated?