Design teams working with microcontrollers (MCUs) have to evaluate all factors that impact device choice such as instruction-word length, code density, floating-point support and integrated peripheral functionality. Even items like design tools and specifically integrated development environments (IDEs) – factors beyond the feature set of the MCU itself – are equally important in the evaluation process. The IDE angle is especially interesting right now as some MCU vendors have turned to the Eclipse open-source-based IDE, while others are headed in different open-source or proprietary directions.
For designers, familiarity is a good thing. Engineers face increasing time-to-market demand in their workload, and familiarity with an MCU or tool set can lead to a fast start and immediate productivity.
Prevailing wisdom would suggest that teams stick with an MCU family based on a familiar instruction set architecture (ISA) anytime such a choice fits their application requirements. And without question engineers are loyal to MCU families. But the instruction set may not be the primary reason for that loyalty. In many cases a design team is working in C or C++ and not dealing directly with the ISA. Factors such as consistency in MCU peripherals (a subject for a future article) or the IDE available for the MCU may provide a bigger productivity boost.
Over the past few years, both MCU vendors and dedicated tool suppliers appeared to be moving toward the Java-based Eclipse IDE, an open-source community shepherded by The Eclipse Foundation. The IDE is the most widely known software that has come out of Eclipse, although there are many other open-source projects happening within the community.
The Eclipse IDE was initially used for enterprise software development, but has been customized by many organizations for embedded usage. It is easily customized by plug-in code and extended with new compilers and enhanced capabilities in areas such as embedded-systems debug.
The Eclipse movement presumably was a positive one as companies ranging from real-time, operating-system vendors to IC makers, adapted the IDE for their use. Embedded development teams familiar with Eclipse will find a somewhat familiar IDE when moving between customized implementations from different vendors.
Wind River Systems, embedded-software specialist, was among the first to adopt Eclipse. A number of MCU vendors also support Eclipse directly. For example, Texas Instruments’ (TI) Code Composer Studio (CCS) is Eclipse based, and TI relies on CCS as the primary development tool for its MPS430 and C2000 MCUs. TI relies on third party tools for its Stellaris ARM-based MCUs. But developers can still use an Eclipse-based IDE for Stellaris work via third parties, including Kiel, who supports Arm MCUs with an Eclipse-based IDE.
Moving away from Eclipse
Just as fast as you think you spot a trend, however, some of the latest IDE developments suggest that Eclipse may not be the future. If your design team has Eclipse experience, it’s likely you will find plenty of Eclipse-based tools, especially from third parties. But some MCU vendors believe other IDE options offer superior productivity.
Atmel was one of the first converts to Eclipse for its 32-bit MCUs. But the company has moved back to reliance on its AVR Studio IDE based on a proprietary software platform for the entire breadth of its 8- to 32-bit AVR family. Figure 1 depicts the process of selecting the appropriate target device in the IDE. AVR Studio 5 combines the functionality previously found in the 8-bit AVR Studio 4 product and the 32-bit AVR32 Studio product.
Figure 1: The Atmel AVR Studio 5 IDE unites support for 8- and 32-bit AVR MCUs in one IDE.
Atmel marketing director Haakon Skar has been candid about the company’s experience with Eclipse. It found Eclipse to be overly complex due to the breadth of the product. Skar points out that a tool designed to work with a broad set of hardware results in complexity for the development team where many features in the IDE aren’t pertinent to the project at hand. Moreover Atmel found that the plug-in-based extensibility made it difficult to deliver a seamless user experience to development teams.
Microchip hopes to avoid such issues with its new IDE, also based on an open-source framework. Microchip has long supported its MCU products with the MPLAB IDE. Based on a proprietary software platform, version 8 is the latest release. Recently the company announced plans for the MPLAB X IDE to succeed version 8. MPLAB X is based on the NetBeans Java-based IDE that started as a project within Sun Microsystems and is now promoted by Oracle.
Microchip made the move for several reasons. MPLAB 8 was a Windows-based product that used a Windows registry-based installation process. The NetBeans-based IDE will be network-centric software that can easily run on different hosts. Microchip is supporting Windows, Apple, and Linux clients with the current public beta release of MPLAB X.
The network capability includes support for distributed, collaborative development. For example, a debug session can happen on one system while the debug target is connected to a remote system.
The NetBeans IDE also will provide developers with state-of-the-art coding tools according to Microchip vice president of development systems Derek Carlson. For example, the editor can offer assistance in typing ahead and automatically completing a line of code. There are simple facilities to search for and find system variables. The widowing environment and ability to map the links between code modules is more robust than in MPLAB 8.
Microchip plans to continue to support MPLAB 8 for one to two years, but it expects that most users will gravitate to the new IDE. The company hopes to release production code later this year.
In any event, Microchip has undertaken perhaps the broadest challenge in supporting a line of differing MCU architectures with one IDE. The new IDE will work with 8-bit PIC10, PIC12, PIC16, and PIC18 families; the 16-bit PIC24 MCUs and dsPIC DSCs; and the 32-bit PIC32 MCUs that are based on the MIPS architecture.
Figure 2 depicts the new MPLAB X architecture. The diagram shows how the extensible framework supports a mix of Microchip software and third-party tools while the editor, source-level debuggers, and project manager elements are part of the baseline NetBeans IDE.
Figure 2: Microchip is integrating its own compiler technology in the NetBeans-based MPLAB X IDE along with third-party tools.
Some in the embedded development field may be perfectly happy swapping between IDEs, based on the best MCU for a project. But others will surely feel more comfortable working in one IDE as much as possible. Understand your comfort level and factors for the application will go a long way toward narrowing the choice of MCUs.