Since we’d like to compile our firmware into some usable binary we use the add_executable command and pass it all the sources generated by STM32CubeMX.
Now it’s finally time to specify a target for our project. In fact they can be named anything although they typically end in. CMake files which don’t introduce new targets aren’t by convention required to be named CMakeLists.txt. Please note that it’s perfectly fine to have multiple CMake files for bigger projects but those don’t need to use the cmake_minimum_required or project command again. project(Īt this point we’re done setting up our project in our top-level CMakeLists.txt. Those variables can then be used to create preprocessor definitions to be used inside the firmware or filenames for compiled binaries. Specifying a project version at this point has the benefits that it sets CMake’s internals PROJECT_VERSION variables. cmake_minimum_required(VERSION 3.19)Īfter we have picked a minimum CMake version we should use the project command to give our project a name, and optionally a version and a list of languages our project contains. There is no particular reason I’ve picked 3.19 but since it came out April 2021 I’d consider it a reasonable choice. CMake needs us to be explicit about it in order to determine which features we’re allowed to use. The very first line of a projects top-level CMakeLists.txt should always set the minimum requires version. Target_compile_definitions(EmbeddedCMake PRIVATE $:DEBUG>ĮmbeddedCMake PRIVATE Core/Inc Drivers/CMSIS/Device/ST/STM32F7xx/Includeĭrivers/CMSIS/Include Drivers/STM32F7xx_HAL_Driver/Inc) cmake_minimum_required(VERSION 3.19)įile(GLOB_RECURSE SRC Core/*.c Core/*.s Drivers/*.c) preprocessor definitions, include paths, sources, compiler flags, …) are set on a per-target basis.īefore we dive deeper let’s take a look at the tiny 16 line CMakeLists.txt I added with this commit. The crucial idea is that all the build settings you typically set for a C/C++ project (e.g. A target might be an executable or a library of sorts. Modern CMake relies on the notion of targets. The amount of old and now considered bad style CMake out there is staggering. But in contrast to the C++ community the modern style has not really fully caught on. Much like C++ there are almost two dialects of CMake, an old and a new modern one.
CMAKE PRINT VARIABLE CODE
In case you’ve never seen CMake code before please brace yourself for two things:Īs C/C++ developer #1 isn’t even worth a shrug but #2 poses a serious problem. HAL_GPIO_TogglePin(LD3_GPIO_Port, LD3_Pin) įor some reason CMake project files are always named CMakeLists.txt so we create one in the projects root directory. HAL_GPIO_TogglePin(LD2_GPIO_Port, LD2_Pin) HAL_GPIO_TogglePin(LD1_GPIO_Port, LD1_Pin) Once that’s done we can move on to CMake. Make sure to place to code between the /* USER CODE */ comments, otherwise it might get deleted when re-running STM32CubeMX. In order to make the LEDs toggle I’ve added the following three invocations to HAL_GPIO_TogglePin to the infinite loop inside main. STM32CubeMX default initialized NUCLEO-F746ZG The important part of the pinout are the 3 LEDs.
CMAKE PRINT VARIABLE FREE
To follow the example along feel free to take a look at the corresponding git repository.įor the initial commit I’ve created a STM32CubeIDE project based on a default initialized NUCLEO-F746ZG board. We’re going to compile the example with two different toolchains, GCC and Clang. To provide a working example I’ve used a NUCLEO-F746ZG demo board (yes, I have a demo board problem) to toggle the 3 LEDs on the board. Drop your makefiles, delete your custom python scripts and stop fiddling with your broken proprietary IDEs because we’re going to write some CMake. As of late I’ve even spotted a PR for adding CMake support to the FreeRTOS kernel which has been notoriously known for promoting a copy/paste workflow for including it into your own project.
Although embedded developers are categorically a decade late to every party we finally see some big players like Espressif or Zephyr move towards CMake as build system of choice. Ok, this might not be entirely true anymore. Well not entirely! One small build system used by embedded developers still holds out against the invaders.”
C build systems are entirely occupied by CMake.
0 kommentar(er)
