ARM development: what do Cortex developers want from a modern IDE?

Posted by Magnus Unemyr on Sep 21, 2016 11:46:28 AM

In terms of ARM development, many software developers spend a major part of the work week in front of their ARM development tools; primarily the IDE with its integrated C/C++ compiler and debugger. How does a modern ARM IDE compare to what embedded developers were using a few years ago?

In this blog post, I will highlight some of the advances the embedded market has made in terms of the C/C++ IDE (including the compiler and debugger itself) – and in particular, what tool features are now available for ARM Cortex developers specifically.

ARM development: Now vs. years ago

It is safe to say that modern ARM development tools are a lot better than the tools embedded developers had to put up with a decade or so ago. Advances have been made to all steps in the development process, from editing to debugging.

The editor

Embedded developers had to put up with very basic integrated editors in the past; barely above the level of Microsoft Notepad. One of the most powerful source code editors by far today is the editor in the Eclipse IDE.
Embedded developers can now enjoy time-savers like color-coded syntax, expand/collapse of code blocks, auto-indent, content assist and code completion, code explanations using tooltips on mouse-hover, spell-checking of comments and strings, as well as auto-formatting according to a custom defined coding style.
Not to mention refactoring and the code navigation capabilities of modern editors; where a hyperlink click opens the definition of a variable, data structure or function implementation. Additional functionalities are #include file dependency browsers, object browsers, outline views, and more.
I would argue that few parts of the embedded development toolset have improved more than the editor in the past decade or so.

The compiler and linker build system

On the outset, the build system with its assembler, C/C++ compiler and linker have not changed a lot in the last few years. The compiler and linker itself (take GNU GCC and LD, for example) still runs from a command line, using a confusing set of command line options understood by few.
Like before, the build process can be managed using make files, or as is more common these days, using a managed (“graphical”) configuration and build launching system integrated into the IDE GUI.
For sure, the C/C++ compiler generates more optimized code today than ten years ago, but any compiler on the market today is now highly optimizing with very small difference across different vendors. The GNU GCC compiler, for example, produces excellent code in most cases. For dramatic code size reductions, it is often the runtime library that makes the largest impact, not the compiler itself.
The compiler optimization race has been ongoing for decades and is now at a point where it is very difficult (and increasingly expensive) for a compiler vendor to make new optimizations that result in dramatic improvements to code optimization. Or in other words, compiler vendors have to spend larger and larger financial resources to gain less and less results, as the compilers are already very mature by now.
ARM Development White Paper - TrueSTUDIO
The latest major step in this area is linker optimization, or whole program optimization, where the code optimization step is moved from the compiler to the linker. This enables optimization also across different source code files; not only within them. With also GNU GCC performing this trick now, many would argue that compiler technology is now maturing and further improvements will likely come at a slower pace – probably with less and less improvements for each new release.
One thing that has improved the build system in later years, however, is parallel compilation. With powerful multicore developer PC’s available at low cost, the build time can be massively reduced by compiling the files in the project in parallel rather than sequentially.
Another valuable feature, pioneered by Atollic TrueSTUDIO, is the build analyzer that visualizes the generated machine code binary in a graphical manner; thus removing the need to study the complex MAP file manually to work out how your code ends up in memory after the linker step.

The debugger

One of the areas where embedded developers have enjoyed most improvements in recent years is probably debugging. The ARM Cortex cores include many advanced debug capabilities that are available at no, or little, extra hardware cost for the developer (i.e. no need to buy expensive debug probes).
While very expensive high-end debuggers (often called an ICE, “in-circuit emulator”) of the past sometimes included instruction trace capabilities, the cost of getting access to instruction trace is dramatically lower today. And ARM’s new Cortex cores provide much more.

Take the Serial Wire Viewer (SWV/SWD/ITM) event- and data tracing technologies for example. With SWV, debuggers can offer the following useful features:

  • Profiling (execution time statistics)
  • Execution time measurement (of an arbitrary code block)
  • Interrupt and Exception event tracing
  • Live variable watch
  • Data access history log
  • Oscilloscope-styled data plot charts
  • Printf() redirection to a debugger console
  • Software tracing
The Cortex-M cores also include hard fault crash analysis data; that debuggers can use to visualize hard fault crash information. Modern ARM development tools can also support live variable watch, also on complex data structures, and dynamic printf() that removes the need to instrument the source code to get debug output.
The use of real-time operating systems has become more widespread; and best-in-class IDE’s have integrated support for RTOS debugging for a variety of real-time operating systems – with RTOS views that visualize different objects, like tasks, semaphores, message boxes, times, etc.
In later years, FreeRTOS has become very popular within the ARM Cortex-M market, and having built-in RTOS debugger views for FreeRTOS is pretty much a must in any modern ARM IDE these days.
It is safe to say that embedded developers of today can enjoy a plethora of new tools in their debugging toolbox – all helping to ship software of higher quality, faster. Gone are the days when your embedded target board was a black box that was very hard (or expensive) to debug.

Team collaboration and code management tools

Even though the embedded industry was late in picking up sound software engineering principles on a larger scale, things have luckily changed. Most experienced embedded developers use both version control systems and bug databases. Some perform source code reviews too. I suspect one of the reasons the embedded industry was late in embracing these best practices is the small amount of software that went into the tiny 8-bit systems of the early days.
PC/server software (and later web applications, and smartphone apps) just had so much more code, that these development projects had to use better team collaboration and code management tools. Thankfully, the embedded industry has caught up and these (usually free) tools are now in widespread use also in our industry.
The team collaboration tools integrated into modern IDE’s are light years from the IDE’s in the earlier years. ARM developers have become used to have version control system clients (for example for Subversion/SVN or GIT) deeply integrated into the IDE; including graphical visualization of the revision change-tree of a particular file. Likewise, bug databases like Trac, Mantis or Bugzilla can be integrated right into the IDE with deep integration with the editor and team collaboration server.
A modern IDE can now include support for source code reviews and code review meetings as well (Atollic TrueSTUDIO do, for example). By employing source code reviews during your development you can improve your software quality a lot.

Isolated islands vs. one unified ecosystem

In the past, the embedded industry was a deeply fragmented market, that we all had to suffer from. Almost any electronics company had their own semiconductor division, who provided their own proprietary CPU cores that were incompatible with everything else.
These isolated silicon core islands also resulted in a deeply fragmented market for development tools and middleware software. Any development tool vendor could only support so many CPU architectures, each having a relatively small market. Thus, a lot of resources had to be spent on duplication of efforts, providing basic tools with no differentiation or value-add to all these small incompatible microcontroller eco-systems.
With ARM Cortex-M now dominating the CPU core market for embedded microcontrollers (popular device families like STM32, EFM32, Kinetis, LPC, XMC etc. are all based on ARM Cortex-M); tool and middleware vendors can spend all their resources on one common CPU architecture, and thus enjoy a much larger market for their products.
Effectively, this results in a shift from producing basic “me-too” commodity products for many different CPU families, into a market where more resources can be spent on differentiation, innovation, and value-add. This shift will provide enormous benefits for embedded developers for years to come.
Some of the benefits of a unified embedded market are:
  • Migration across different CPU vendors will be easier (second source)
  • Device prices go down
  • Less training across different CPU vendors and tools
  • Tools and middleware can be used in different projects, across different CPU families
  • Tool and middleware vendors will get better tools at lower cost
But there are more benefits, as the next section will outline.

Proprietary lock-in vs. open standards

In the past, embedded developers were locked-in to a particular CPU and tool vendor, as the source code and compiler grammar (including linker configuration files, #pragmas, inline assembly etc.) were different for each vendor – it was hard to move a project to a new CPU or development tool.
Effectively, vendors had a great lock-in effect that made it very difficult for their customers to move to cheaper or better solutions.
In the new landscape, ARM Cortex-M is the dominant CPU architecture for embedded microcontrollers, and ECLIPSE/GCC/GDB is the de-facto standard software tool solution. This breaks the walls of vendor lock-in and make it easy for developers to move a project to new CPU families or tool vendors.
ARM Development White Paper - TrueSTUDIO
 There are many free or commercial ECLIPSE/GCC/GDB tools available, and moving the project from one of them to another is a minor task. You can start with a free tool, and as your hunger for more advanced features or need for higher quality increase, you can easily upgrade to a high-end commercial ECLIPSE/GCC/GDB tool. And since the Eclipse IDE has an open plug-in architecture, an Eclipse-based ARM IDE can be extended in almost any direction - including plugins written by yourself if needed. This makes Eclipse the most open, powerful and flexible IDE by far.
When more and more companies standardize their designs on ARM Cortex-M and ECLIPSE/GCC/GDB, cost for training go down, and it becomes easier to reassign developers across different projects. This improved flexibility is worth a lot to many development departments put under stress to achieve more with less resources.
ARM is furthering fostering this situation, with their CMSIS initiatives:
  • CMSIS-DRIVER defines a generic peripheral access API standard – i.e. for device drivers or hardware abstraction layers.
  • CMSIS-RTOS is a standardized set of RTOS API’s with the aim of making it even easier to move a project from one RTOS to another.
  • CMSIS-PACK is a new standard for distribution of embedded software components like board support packages, device driver libraries, or middleware. CMSIS-PACK includes features for component discovery, dependency management, download, and installation.
  • CMSIS-DSP is a common library of mathematical and digital signal processing functions for Cortex-M devices.
  • CMSIS-SVD provides a unified mechanism to provide device information for embedded tools; for example, the data necessary to populate the SFR register view in the debugger.
  • CMSIS-DAP is a standardized debug port firmware that can be used to build a debug probe using a Cortex-M device.
Embedded developers of today can enjoy a much more flexible, unified and open landscape, and avoid vendor lock-in.

Final words

Ten years ago; there were a lot of discussions in the embedded industry on how embedded developers would work in the future. In hindsight, many of the predictions didn’t become mainstream and come in common use.
The Unified Modeling Language (UML) are used with great success in many teams, for sure, but most development teams still use C (or C++). Likewise, C or C++ has not been replaced by something else as the dominant programming language for embedded development. Overall, rapid application development (RAD) tools, or graphical programming tools (like UML) have not replaced C or C++.
But still, the embedded industry and the embedded tools market have gone from isolated islands of proprietary solutions to become more homogenous with a unified open eco-system. All embedded developers benefit from this, and we wait with great interest to see what the next decade will bring us!
To learn more on ARM development, and Cortex-M tools based on ECLIPSE/GCC/GDB, read this whitepaper:
Read our ARM development  whitepaper!

Topics: ECLIPSE, ARM Cortex, GNU tools (GCC/GDB), Debugging, Embedded Software Development, Project migration, version control, issue management, editing