RTC Magazine

As the expanding demands of the embedded device market are being enabled by cheaper memory and faster processors, the software in today’s embedded systems is exploding. This dynamic of code explosion, larger project teams and integration of many embedded software applications, from proprietary code to purchased or open source software IP, is a much bigger challenge than we faced 10 years ago. And now we are without the benefit of in-circuit emulators to help debug them. But there is an answer. Embedded software engineers can take advantage of today’s enterprise design and development tools as they come together with embedded debugging tools to provide a complex yet robust embedded development environment.

Until recently, embedded tools were typically provided by either embedded tools vendors or RTOS vendors. In today’s embedded world, they are either provided by chip companies, RTOS companies or come from the open source community. The chip companies provide tools that can help boost the performance of and offer early support for their latest architectures. The RTOS companies provide tools that allow users to easily build applications for a given RTOS and offer awareness of that RTOS when debugging. And the open source community offers compilers, debuggers and now integrated development environments (IDEs) for embedded debugging. The latter category is having a very interesting effect on the embedded development landscape as it offers a common platform that embedded developers can use regardless of RTOS, debugger, compiler or processor.

This common platform is called Eclipse. Over the past couple years, Eclipse has gradually become the de facto standard IDE and framework for embedded systems development. There are a number of reasons for this, and looking back at the history of IDEs in the world of embedded is a good start toward understanding them.

The first real IDEs for embedded software emerged in the early 90s. Then, through the following 10 years, most RTOS, tools and a number of processor companies brought out IDE products. Many of the IDEs were proprietary, which caused issues for the embedded vendors, as they were forced to develop large software suites that were really not specific to embedded. This also posed an issue for embedded developers, as they were forced to learn a new IDE interface every time a new RTOS or processor was selected.

Some embedded vendors decided to take an IDE licensing approach. In this approach, Microsoft’s Visual Studio was viewed as a good starting point due to the large user base and also the large number of developers that Microsoft has to maintain it. Unfortunately, it left the embedded vendors at the mercy of Microsoft’s release schedule and feature set—and forced them to do a lot of work to make Visual Studio appropriate for embedded. The other obvious issue was the fact that Visual Studio is only Windows-based and therefore would not offer easy support for Solaris or Linux hosted development.

Enter Eclipse. Eclipse is an enterprise-strength, open source framework that allows tools vendors to re-use the open source parts, as well as seamlessly plug in their own software tools. Its Eclipse Public License (EPL) allows embedded vendors to produce commercial products based on the open source software. Eclipse also supports multiple host platforms and, since it is written in Java, offers portability to easily migrate to other hosts.

Although the Eclipse platform was born from the enterprise world, and is still driven by the needs of enterprise developers, the expansion of Eclipse is governed by a number of projects. Several of these projects are either aimed at embedded development, or have enough synergy with what embedded developers require that they become a very good starting point for building an embedded development environment (Figure 1).

One project, the C/C++ development tools project (CDT), brings compilation tools, a graphical build environment, an editor and a debugger to the embedded vendors. RTOS companies, for example, find this a very good place to build an RTOS-specific build system and RTOS-aware debug solution. Another project, the Device Software Development Project (DSDP), is focusing on standardization in embedded areas such as host/target management and debugging. DSDP will be working closely to integrate with the CDT project.

So, Eclipse has been shown to be a great starting point for embedded vendors. What about embedded software developers? Eclipse offers many benefits that have never been realized before in the embedded world.

First, the Eclipse platform is a common part of all Eclipse-based solutions and offers a common user interface. Although Eclipse is very flexible with regard to plug-in applications and tools, it enforces these plug-ins to adhere to a set of rules and APIs. For the embedded developer, it means that whatever RTOS or processor is being used, the overall IDE and the way tools interact with it is very consistent and allows easier migration across projects.

Second, being born from enterprise offers some huge benefits: the user base and hence quality of code is far greater than traditional embedded IDEs; the interface is more modern; and embedded projects can take advantage of a wide range of plug-ins from the enterprise world. For example, source code management and version control systems are not specific to embedded, so embedded engineers can really take advantage of products such as ClearCase, CVS and Subversion, all integrated within Eclipse.

Third, Eclipse allows different embedded products to “play” together under one IDE and with a common look and feel. So, compilers from one company, debuggers from another and test and validation tools from yet another can all work seamlessly together. Eclipse also offers an opportunity for these separate companies or products to actually interact with each other, as the plug-in mechanism has integration and expansion points to allow close interaction between plug-ins.

Finally, the open environment of Eclipse allows embedded developers to actually write their own plug-ins. This offers the ability to build company- or application-specific tools and have them interact with the IDE from the embedded vendor(s) of their choice.

Eclipse also allows embedded software developers to take advantage of software design tools, advanced code management and build systems, and swap out different tools and components without changing environment. This becomes more and more important with the larger and more complex systems—and as more software IP is either purchased or obtained from the open source community.

High-level design languages have been around in the embedded software industry for many years, but only recently have they become more usable, more standard and more needed. As code size explodes, coding in traditional programming languages such as C and C++ becomes too inefficient for the number of debugged lines of code that can be written in a day. These languages also cannot show multiprocess and multiprocessor solutions very adequately. Moving up a level of abstraction to a high-level design tool allows system engineers to describe a system and the interactions in a system in a standard design language—the Unified Modeling Language (UML). Most UML tools have an Eclipse interface that lets them fit into the standard embedded IDE and also generate C or C++ code (usually linked in with the RTOS of choice) that can then go into the traditional build and debug system of the embedded user. This offers a huge productivity gain, as one line of UML can equate to tens of lines of embedded C or C++. Hence, the number of lines of code that can be generated in a day goes up dramatically.

By offering a standard interface to the embedded build system, Eclipse also abstracts away the interface to compilation tools. This means that bringing a new or different compiler into the build process is relatively easy as Eclipse offers the interface to it. This allows embedded software developers to either change compilers to increase performance of the code generated or easily migrate to a different processor architecture. The compiler has always been the last tool an embedded engineer is willing to change, as it is often very closely tied to the processor. But now, with C++ and UML being more widely used, the interaction between the embedded software engineer and his compiler is growing more distant.

Embedded debuggers have always had their own look and feel, and moving between them has always been a challenge—even if they were being used on the same project as each other. With Eclipse, the functionality of different debuggers now has a more uniform feel, and they all plug in to the standard IDE. In Eclipse, moving between different tools often means a change of “perspective” (an Eclipse term). This generally changes all the windows in the Eclipse IDE to match whatever tool is being used and is achieved via a single button click. This means that the embedded developer can have a whole arsenal of tools (including multiple debuggers) that have their own perspective.

For complex embedded systems, this means that very specific tools (such as JTAG emulation, simulation and other complex debugging products) can be available—but without having the cost of one per user. If the tools are closely integrated with one another, then they may well share a perspective, with each one having different views or windows within it. They can also share communication channels, thus providing an even greater integration between debug products.

Another increasing requirement of modern debuggers is the ability to debug multiple processors. This has traditionally been very difficult for most debuggers because they have often needed to spawn clone copies of themselves for each processor being debugged. This soon eats up screen real estate and doesn’t allow easy communication between debug sessions. The flexibility of the Eclipse framework allows multicore-aware debuggers to enhance their user interface with a single perspective and then communicate within the views (windows) with each other. This can make for a simple yet powerful debugging interface for large, complex systems.

The embedded software explosion is requiring that the tools and methodologies for building and debugging systems are closer to those found in the enterprise space. For the embedded world, the Eclipse platform offers a consistent, enterprise-strength IDE that can bring tools together that are open source, enterprise and embedded-specific in order to help embedded software engineers meet both their projects requirements and deadlines.

LynuxWorks embraces open standards and provides Real Time Operating Systems based on POSIX and Linux standards and a comprehensive embedded tool suite based on the Eclipse framework. For more information please visit www.lynuxworks.com.

LynuxWorks
San Jose, CA.
(408) 979-3900.
[www.lynuxworks.com].