The GNU gcc compiler is one of the most widely used C/C++ compilers in the world. It is the basic build tool for building all EmbeddedLinux and Android systems, as well as all desktop or server Linux operating systems and their applications. The GNU compiler is also used to build many commercial real-time operating systems, such as RTOS products from Enea, QNX, WindRiver and more.
And so it is safe to say it is very well proven in field. But how well does the GNU gcc compiler fit developers using ARM Cortex-M devices, for example STM32, Kinetis, EFM32 or LPC? And what capabilities and core support does it offer to ARM Cortex developers?
The GNU compilers are highly optimizing compilers that support both the C and C++ languages. The GNU C compiler (gcc) supports the C language, while the GNU C++ compiler (G++) supports the C++ language. And so, there are actually two GNU compilers in the toolchain, not one.
The GNU C/C++ compilers have a number of extensions that make them well suited for embedded development, including fine-grained control using many command-line options, inline assembly, and compiler #pragmas that helps control the compiler behavior in great detail. Furthermore, the GNU compilers have extensive support for a large number of target processors and language dialect standards.
Some of the feature highlights are:
- Highly optimizing C/C++ compiler
- Supports inline assembly
- Supports interrupt handlers in C
- Supports a large number of generic and target specific #pragmas
- Generates optimized production code or debug instrumented code
- Generates information for linker optimization (dead code & data removal)
- Generates reports (disassembly list files)
- Extensive set of command line options to control the operation
- Support for “whole program optimization” or LTO (link time optimization, not to be confused with dead-code or dead-data removal). This enables optimization across C-files, not only inside them. This capability enables the linker to perform resequencing of the code, thus further reducing code size.
The following C language standards are supported:
- C89 (original ANSI-C, X3.159-1989)
- C90 (original ANSI-C, ISO/IEC 9899:1990)
- C94/C95 (amendment 1, AMD1)
- C99 (ISO/IEC 9899:1999, supported with few exceptions)
- C11 (supported with some exceptions)
- GNU language extensions
The following C++ language standards are supported:
- C++98 (ISO/IEC 14882:1998, supported with few exceptions)
- C++03 (ISO/IEC 14882:2003, supported with few exceptions)
- C++11 (ISO/IEC 14882:2011, preliminary support)
The GNU compilers support almost all CPU architectures in common use, such as Intel x86, Renesas SH and RX, PowerPC, MIPS etc. This blog post is focused on ARM processors, so it should be mentioned that the GNU compilers have excellent support for the ARM cores, including for example:
Please note however that all GNU gcc compilers for ARM (even if they have the same version number) do not have identical target support or capabilities. This is because the GNU gcc version number is applied to the source code of the compiler, not the readymade gcc binary.
Two GNU gcc compilers for ARM with the same version number do thus not necessarily have the same features, bug fixes or CPU support, as they can be built from the same source code using different “build recipes”. Here at Atollic for example, we built and test our own version of the GNU gcc compiler to make it the best fit for our customer’s needs.
Prospective GNU tools users must weigh a number of important factors before deciding whether or not GNU and open-source tools are the best option for their particular situation. Among these are cost, time, and requirements for capabilities that pertain to the tool selection.
Commercially packaged and extended GNU tools, like Atollic TrueSTUDIO, solves many of the problems that face developers trying to use free versions of the GNU tools. For example, these questions are valid ones for Cortex-M developers who consider using the GNU tools:
- Build the tools yourself or buy a readymade solution, and how to handle quality assurance and validation?
- What level of integration with the Eclipse IDE is needed?
- How to connect the debugger to a JTAG debug probe, for example ST-LINK or SEGGER J-Link?
- How will Flash loading and Flash debugging be handled?
- What about device specific debug features?
- Do I want to perform system analysis and real-time event- and data tracing using the ARM Serial Wire Viewer (SWV/SWO/ITM) technology?
- Do I need to use ETM/ETB instruction tracing to record execution history for later analysis, for example using the SEGGER J-Trace debug probe?
- Can I use the hard fault crash analysis capabilities of Cortex-M cores, on devices such as STM32, Kinetis or LPC?
- Is there any support for dual core debugging?
- What about kernel-aware RTOS debug support, for popular real-time operating systems like FreeRTOS, OpenRTOS, embOS, uC/OS, ThreadX, etc.?
- What level of technical support is required if the project runs into problems?
And so while the GNU tools are freely available, there are some factors that need to be considered when choosing the best compiler solution for ARM Cortex-M development; and it really doesn’t matter if the device is STM32, Kinetis, LPC or any other Cortex-M device.
Either if you chose a commercially supported and extended Eclipse and GNU tool like Atollic TrueSTUDIO, or if you go with a free low-end alternative, the GNU gcc compiler is great choice. It is highly optimizing, rock solid, and well suited for ARM Cortex-M embedded development. It also offers second source suppliers and avoids vendor lock-in, which is not the case with the proprietary compilers.
Since the GNU tools and the ECLIPSE IDE on ARM Cortex devices now is a de-facto standard in the embedded industry, developers now have a wide variety of GNU tool offerings to choose from, either free low-end tools or highly capable tools with state-of-the-art capabilities, like the Atollic TrueSTUDIO IDE for ARM.
If you want to read more on using the GNU tools on ARM, read this whitepaper:
If you want to read more on ARM Cortex development and debugging, read this whitepaper: