Embedded C/C++ software development tools come in two main flavours:

(1) GNU tools which are based on open-source technology and

(2) Proprietary tools which are based on proprietary technology provided by a specific vendor. 

If you are a developer looking at embedded development tools for future designs your first major decision is going to be do I use Open Source based tools or proprietary tools. You should look at the long-term goals of protecting your company's software assets against becoming dependent on a specific semiconductor or tools vendor, as well as performance charcteristics and ease-of-use.

Many OEMs adopt a “platform” approach to their product software strategy whereby many man-years of carefully crafted software design have resulted in software assets that are readily incorporated into different OEM product models reflecting increased product capability. OEMs across all industries are also reporting their proprietary hardware is fast becoming a commodity item and they need to focus development efforts on differentiating their products at the software level or by offering differentiating services to their customers via IoT-enabled products. This all points to the importance of software to OEM product success and the importance of using the optimal software development tools to develop and protect software assets. Engineers and engineering management have to take software asset protection seriously and not just focus on getting the current product out-the-door.

If you think your proprietary code base is protected because it’s written mostly in C or C++ with assembly language assist functions then think again. All proprietary compilers and the GNU compiler have language extensions that make your code non-portable to other compilers if used. IAR’s compiler documentation talks about “supporting a wide set of language extensions specifically tailored for embedded programming and for specific cores” – the problems occur if your engineers use these language extensions as your code is now dependent on that compiler vendor’s compiler. The same problem applies to toolsets from NXP/Freescale , TI and ARM.

A typical OEM product portfolio includes low-end products based for example on ARM Cortex-M processors and middle or high-end products based on ARM Cortex-A processors, which means the development tools should ideally span the entire spectrum of these ARM architectures. If the OEM opts to use multicore processor technology, these come with 2, 4, 8 or even 16 cores which can be the same core (homogeneous processor) or different cores (heterogeneous processor) which typically incorporates Cortex-A cores with Cortex-M cores. Heterogeneous multicore processors allow OEMs to section critical application assets that have to be secured, protected or certified for safety applications onto the Cortex-M cores, which will often run a certified RTOS, while the rest of the application such as the device user-interface or device communications are run on the Cortex-A cores and will typically be running some flavour of Embedded Linux with its rich ecosystem of application software. With this architecture, it is highly desirable that the development tools again span not only the range of processor architectures but also the range of software runtime domains which include standalone/bare-metal with no RTOS, low-end RTOS, high-end RTOS and Embedded Linux.

GNU tools were originally intended for development of workstation applications but are also used for embedded applications which have a different set of requirements governed by the embedded processor and memory constraints, as well as “real-time” response times to events in the outside world and the power consumption constraints of the embedded device. Unlike PC or workstation development, every embedded device has its own unique software requirements.

GNU tools dominate development across high-end RTOSes and Embedded Linux running on 32/64-bit processors. GNU GCC is the default software development toolchain for Embedded Linux. The Linux kernel, consisting of nearly 20 million lines of code, plus the semiconductor vendor layers plus the huge ecosystem of application packages are written in GCC. There is no alternative toolchain if you’re using Embedded Linux in your products. The same applies if you’re using RTOSes like VxWorks, QNX or Nucleus.

GNU tools have typically not been used to develop low-end OEM products based on standalone/bare-metal and low-end RTOS primarily because standard GNU tools have not included the feature set required for low-end development  – this is typically where proprietary tools have been used. As an example, GNU tools for Embedded Linux development have some pretty powerful high-end debug features available such as reverse debugging, but yet do not standardly provide support for low-end debug requirements such as JTAG debug tools with tracing capability; standard GNU tools assume high-end debug capability is available, typically with an embedded debug agent on the target device and this is not the case with standalone or low-end RTOS runtimes.

Where GNU-based tools have been made available for standalone/bare metal and low-end RTOS product development, these tools have been packaged up by semiconductor companies and made available as free downloads with community support the only technical support option.

Some commercial development tools packages use the same Eclipse-based, GNU ARM tools as tools offered for download free of charge by semiconductor vendors or from the Free Software Foundation and Eclipse websites. These commercial products offer a packaged solution but very little or no technical benefit over the free entry level GNU solutions.

Tools with an Eclipse IDE provide a standard interface that can be used across all OEM products. Eclipse is the de-facto standard IDE which is not supported by vendors like IAR & Keil – these come with old-style proprietary IDEs. The power of Eclipse comes with the plug-in concept which allows additional capability to be added simply by downloading and installing the plug-in. For example, this is how FreeRTOS or MQX support is added to Somnium DRT along with support for NXP Processor Expert, NXP Sensor Fusion and Kinetis SDK.

Eclipse also opens up other programming languages such as Ajax, Java, Lua and AspectJ to the OEM development team and many other classes of software tools such as testing and source code control tools.

Proprietary software development tools provided by independent tool vendors, like IAR and Keil, along with proprietary tools  provided by semiconductor vendors like NXP and TI have typically dominated development of products based on standalone/bare metal and low-end RTOS runtimes. Use of these proprietary tools for low-end OEM product development breaks the software platform continuity and creates a dividing line between OEM products based on standalone/bare metal or low-end RTOS runtimes and OEM products based on high-end RTOS or Embedded Linux; this adds cost through additional development & testing effort when the OEM moves its software codebase to another MCU/MPU.  This cost is not present if a GNU-based solution is deployed for all OEM product development.

OEM developers that buy proprietary development tools (and RTOS) from semiconductor vendors run the risk of making their software assets dependent on using that vendor’s silicon – a desirable outcome for the semiconductor vendor but an undesirable outcome for the OEM. With the rapid pace of technology advancement at the processor level, OEMs need to protect their software assets by being independent of any semiconductor vendor and being in a position to move their software platform to a new semiconductor vendor with minimal effort and cost to the platform codebase. This effectively puts the OEM in control of the processors that can be used in their products… a desirable outcome for the OEM.

OEM developers that buy proprietary development tools from the independent tool vendors again run the risk of their software assets become dependent on using the proprietary vendor’s tools and being forced to use two sets of tools: one set for low-end product development on a bare-metal system and GCC-based tools for high-end product development. For the OEM, this situation adds upfront license purchasing cost, learning time costs, maintenance costs, and it fundamentally breaks the “platform” approach to software development.

Device OEMs are moving in the direction of using software to provide product differentiation and engineering groups are adopting a “platform” approach to their own software assets and to the runtimes deployed in families of products with ever-increasing software content.

The use of GNU-tools technology for software development across all runtime environments comprising:

• standalone/bare metal with no RTOS,
• low-end RTOS e.g. FreeRTOS, MQX, TI-RTOS, uCOSII
• high-end RTOS e.g. VxWorks, QNX
• Embedded Linux

promotes a platform approach for OEM software assets, helps OEMs to protect their software assets from becoming vendor dependent and provides the OEM with competitive advantages.

GNU tools dominate development across high-end RTOSes, Embedded Linux, 32/64-bit Cortex-A based embedded applications which are typically used in mid-to-high-end OEM product development.

Eclipse-based IDEs are the de-facto standard framework for any kind of code development. Eclipse plug-ins enhance the capability of the framework and open up new classes of tools for testing and source-code control to the OEM development team.

Proprietary development tools and IDEs as provided by ARM/Keil, IAR, NXP, TI have typically dominated development across low-end RTOSes and standalone/bare-metal runtimes. Using proprietary tools and IDEs is not a good long term strategy for OEMs to employ as it fails to provide a path to middle/high-end product development using high-end RTOS or Embedded Linux.

In order to have optimal support for the development of their important software assets, which are independent of any specific vendor, OEMs should use a GNU/Eclipse-based development tool focused on and optimized for standalone/bare metal with no RTOS and low-end RTOS such as FreeRTOS running on Cortex-M architectures.  This fills the gap that has traditionally existed in a GNU-based solution.