Led by The Definitive Guide to ARM® Cortex®-M4…, we have quite easily managed to compile and run a sample from GNU Tools for ARM Embedded Processors (see earlier post). However, we only got a generic Cortex-M4 startup assembly file and corresponding linker script from the sample. According to The Definitive Guide to ARM® Cortex®-M4…, there is more we can get from our vendor, ST in this case (HAL headers and code, drivers, and more generally, all sort of boilerplate code we want to have when we make full use of the board’s resources, instead of reinventing the wheel). STM32CubeF4 is just that, and quite a lot more (especially plenty of example applications and templates). It complies to The ARM CMSIS, Cortex Microcontroller Software Interface Standard, a vendor-independent hardware abstraction layer for the Cortex-M processor series that also specifies debugger interfaces.
What I am most interested in is the contents of
Projects/STM32F4-Discovery/Templates/, as it should contain exactly what we need to develop applications for the board (although I am not sure whether it includes support for C++ compilation, which I intend use, but the ARM variant used in an earlier post did have such support, so it should be easy enough to copy/paste).
Projects/STM32F4-Discovery/Templates/ contains project files for several development environments, but no Makefile. One of the supported environment is TrueSTUDIO, that seems to make use of a GNU chain, which is good for us.
I might as well take the opportunity to digress a little about the development environment topic. I won’t apologize for loving open source. No single software vendor has a chance to have nearly as many reviewers as an open source tool. Many reviewers just means higher quality, it’s that simple. Using a GNU toolchain is not even a topic of discussion for me. Using
openocd, including its integration with GDB has been very positive so far, so I do not see a reason for looking elsewhere. What is left to choose is:
- The editor.
- The debugger GUI (living without a debugger GUI is not really an alternative).
- Last but not least: the build tool.
Concerning point 1, although I have used Emacs many years, I am leaning towards Eclipse because it is the de facto standard. The reason is that I also develop software for a living, and Eclipse is probably preferable for a potential customer. It is easier to get a consensus around it. The debugger GUI issue is then solved as well (with the right plugins). When it comes to the build tool, I want to be able to build both inside and outside of Eclipse. I reckon that will ease the generation of production binaries, and I also reckon that
GNU make and its
Makefile are the natural solution for that issue.
GNU ARM Eclipse
I have investigated the fastest way to get a blinking LED example running/debugged under Eclipse:
- Download Eclipse from Eclipse IDE for C/C++ Developers. Unpack it wherever you like and start it from there.
- Install GNU ARM Eclipse, as documented under GNU ARM Eclipse plugins installation. GNU ARM Eclipse is a set of plugins, quoting the site: “currently maintained by Liviu Ionescu, a senior IT engineer, with expertise in operating systems, compilers, embedded systems and Internet technologies”.
GNU ARM Eclipse is certainly impressive. Once that was installed, using the documentation from the same site, GNU Tools for ARM Embedded Processors, and OpenOCD, I could run/debug a LED blinking example and see printouts from the program in an Eclipse console in no time, without even using STM32CubeF4. It should be however noted that some code in the plugin, I guess most of what is specific to ST MCUs and boards, comes from STM32CubeF4.