I often get questions on what tool to choose for embedded development; and after a number of years in this industry I have learnt that no tool fits all, and that many developers have very different opinions on what is important. Additionally, different developers have different needs and skill levels too.
Having said that, I have also seen a large number of development projects and learnt what is important for most embedded developers, and how to approach the tool selection process. Last week, I again got the question on what embedded tools are best from a company looking for STM32 development tools. That triggered me to take a step back and think about how to select the right tools (for STM32, or any other ARM Cortex device like Freescale Kinetis or NXP LPC for that matter) from a slightly more philosophical point of view.
A number of questions can of course be asked. To start with, what is important for you?
- Do you prefer a commercial quality product that gets the job done, or is it more important with a free or low-cost solution that may or may not work as intended?
- What is the cost of project failure or delay? Does senior management accept that commercial risk, in return for a few dollars saved on tool purchase?
- Are powerful tool capabilities or short learning curve and ease of use of primary interest?
- Do you want to conform to the new open industry standards, such as the ECLIPSE IDE and the GNU gcc/gdb compiler and debugger toolchain, or rely on proprietary products with a vendor lock-in?
- Do you want to work in an open and thriving tools eco system (the ECLIPSE IDE with its vast Eclipse plug-in eco system comes to mind here), or is extensibility and flexibility less of an issue?
- Do you want a tool that only fits the needs right now, or do you want to future proof yourself with a tool that you can grow with as your needs increase over time?
- Do you just need a basic edit/compile/debug IDE, or are you looking for a more complete embedded development platform, with features for software quality (such as MISRA-C coding standards checking, code complexity analysis), team collaboration (version control system and bug database GUI integration), advanced debugging (hard fault crash analysis, event/data/instruction tracing, dual-core debugging, RTOS aware debugging) and so on?
- Do you need technical support and perhaps also training options, providing a safety net in case you run into problems?
- Do you need deep integration with STM32 technologies, like STM32CubeMx and ST-LINK?
For commercial development projects, my take on this is quite easy.
Embedded projects with commercial importance should be developed using quality tools having technical support. The price for the software license is negligible for a project running for several months or longer. If higher tool quality, available technical support and more powerful features only shaves off some percent of the development time, the tool cost has easily paid for itself right there. One bug alone can cost more to find and fix than the license cost of a tool that helps you find the bug more quickly (or even avoid it in the first place).
For the full project, it is likely much more expensive to use a free or low-cost tool, compared to a supported high quality tool that comes with a license fee (think total cost of project completion here, not only the cost of the tool license).
Not to mention minimizing project risks (technical as well as commercial) and potential launch delays if the development tools are not rock solid, offers strong debugging capabilities, and other features to improve the software quality in your product.
Other factors may be more debate-able. I am a strong fan of open, extensible and flexible eco-systems, as they are more likely to reduce training cost over time, improve and extend faster as needs change, and they avoid vendor lock-in.
The Eclipse C/C++ IDE and the GNU gcc/gdb tools are a typical example of this. Even if you start with one Eclipse IDE with the GNU tools, you can move to another Eclipse IDE based on gcc/gdb with ease, as it is an Eclipse->Eclipse GUI migration, and GNU->GNU command line tool migration requiring no source code changes to C/C++ files, assembler files, linker configuration files etc. If you chose a proprietary IDE/compiler, there is no second-source vendor offering source code compatibility should you need to change tool supplier for whatever reason later on.
What about tool features then? If you chose an Eclipse based IDE, you are in a good position as Eclipse is incredibly powerful to start with, offering almost unlimited extensibility with 3rd party Eclipse plugins from many open source projects and commercial vendors. Proprietary IDE’s are highly unlikely to offer the same feature set, extensibility or flexibility.
It is however true that embedded developers (and STM32 and other Cortex-M developers are no different) have special needs not addressed by standard Eclipse, or for that matter free or low-cost embedded IDE’s based on Eclipse.
Special features and capabilities of interest to STM32 and other Cortex-M developers are likely:
- Project wizard with out-of-the-box support for target devices, boards and JTAG probes
- Integration with STM32 technologies like STM32CubeMX and ST-LINK
- JTAG probe configuration and debug launching capabilities
- CMSIS-SVD compatible SFR peripheral register browser
- Real-time variable watch
- Serial Wire Viewer (SWV) event- and data tracing
- Interrupt and exception analysis and statistics
- Profiling and performance measurements
- printf() re-direction to a debugger console
- Data tracing with memory access history log and oscilloscope styled real-time variable plot graphs
- ETM/ETB instruction tracing
- Hard fault crash analyzer
- RTOS kernel aware debugging for the RTOS in use; such as FreeRTOS, Micrium uC/OS, SEGGER embOS, ExpressLogic ThreadX, etc.
It is up to each development project to determine the value of tool capabilities. I am however of the opinion that many of these capabilities can vastly reduce development time and minimizing risk of project failure, project delays, or poor software quality.
While all developers may not need to use all of the above capabilities for STM32 and Cortex-M development, they should at a bare minimum be evaluated and understood such that an active decision has been made. In my mind, it is likely too many developers and engineering managers that put their project and company at commercial risk, for very marginal cost savings that in the end are replaced by cost overruns when inferior tools extend the development time and enforce project delays.
And so as I wrote in the beginning, no tool fits everyone, and different developers and projects have different needs and skill-sets. But a tool for a project of commercial importance should be selected carefully, based on a serious understanding of what the tool cost is vs. risk of introducing even higher costs by choosing a tool that is a bad fit for the actual needs. Think total cost of project completion and risk mitigation here.
You can also download our whitepaper: