If you use a buffer of bytes to share strings between C (or C++) and Python, you may end up with weird results, because both languages do not represent strings the same way.
I got bitten lately and here is what I have learnt.
If you have used C to handle strings once in your lifetime, then you have run into one of the most painful things in C: null-terminated strings 😑
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 😄
(*) 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.
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!
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?
Something funny happens sometimes with 3rd party files: they generate warnings when compiled with your project settings. If you have quality indicators about the build health (automatically updated by Jenkins maybe), this is quite annoying. If you compile with an option such as -Werror to treat warnings as errors, this is a blocking issue.
In this article, we will add compiler options that will raise warnings in ST’s generated files and we will ask CMake to suppress these warnings but only for these files.