I recently came up with the idea to write a clean template project for creating new STM32F4-based projects. The effort to create new firmware projects should be minimal while still maintaining maximum control and transparency over what happens in the build stage.
Before creating this template I used a customized Makefile for my projects. Creating a new project meant copying an existing one to a new location and adapting the Makefile to the new requirements (adjusting paths, sources, librariers, targets, etc.). While this basically works, it feels kind of wrong. The bigger the project gets, the more cumbersome the effort to maintain the Makefile becomes. Another problem is that the Makefile quickly becomes too dependent on one machine. Making the project compile on a different host might become difficult then.
A different approach might make use of the GNU Arm Eclipse plugin (or some other plugin or even IDE) which is also able to quickly create new projects. The huge disadvantage is that you make yourself dependent on the plugin or IDE itself. If it doesn’t work with future Eclipse versions or if it becomes abandoned, you won’t be able to edit or compile your projects because the Makefiles are generated automatically by this plugin. Portability is even worse because you actually need a fully working IDE to compile the project (what happens, if you want to do automatic build on a build machine?)
I found an “enhancement” to the GNU make build system in CMake.
The idea is to describe in CMake’s own dialect what the project looks like and how the firmware should be built. A lot of the things I did in the Makefile are also done in the CMake file (setting up compiler flags for example). The advantage is that you don’t have to deal with the syntax of the Makefile which is in my opinion very weird and error-prone. You can better concentrate on the real work. When CMake is invoked, it will actually generate standard Makefiles again which fit the project perfectly.
Another advantage is that you can for example easily build libraries from parts of your projects and link against them during the final build stage. This leads to an overall better structure of the program.
ST’s standard peripheral library is already included in the template and a sample project is available which turns on the blue LED on a STM32F4Discovery board. OpenOCD (if installed) can be used to to easily flash the created firmware onto the chip.
As usual, everything is available as a GitHub repository:
https://github.com/ahessling/STM32F4Template
More details and instructions are to be found in the README.
Enjoy! 😉
