Headlines

Headlines

Eclipse Enables Embedded Cross-Development for Intel XScale® Processors

By Brian Handley, Sr. Engineer Macraigor Systems LLC

The Eclipse development environment has become the de-facto industry-standard environment for hosting embedded-development tools. Many of the traditional embedded-tools vendors, which used to sell their own proprietary development tools and environments, have embraced Eclipse. They've even ported their products to run within Eclipse in order to take advantage of the sophisticated, feature-rich framework provided by the Eclipse IDE. Although these tools and environments are powerful, they can still be expensive. For projects on a tight budget, it's now possible to use the freely available, open-source Eclipse IDE—along with the open-source GNU tools (binutils, gcc, and gdb)—to construct a complete cross-development environment at little or no cost.

Of course, piecing together all of the necessary components to build such a system isn't necessarily easy. Eclipse wasn't originally built to handle cross-development or even the C or C++ languages that are typically used in most embedded projects. As a result, a significant amount of effort is needed to get Eclipse to perform this task adequately. Beyond this point, Eclipse doesn't currently have any concept of a remote debug connection on its own. If a debug interface like JTAG or even an Ethernet or serial connection to a target-resident debug monitor is used, Eclipse must be reconfigured to handle this situation. Additionally, the required GNU tools are typically available only in source format. They must be built for the particular host and target processor that are being used by a project. Getting these tools to build for a particular host-target combination can be difficult. This feat can consume engineering time that could be better spent on application development.

To build a functional, free, cross-development environment, several components must be obtained and integrated together. The Eclipse development environment is the framework into which the other necessary tools are integrated. Eclipse itself includes an editor, project manager, and debugger interface. Because the environment is intended for embedded cross-development, the C and C++ languages must be supported. This aspect requires the use of the CDT (www.eclipse.org/cdt) plug-in for Eclipse. The assembler, compiler, linker, and other code-generation utilities will be provided by open-source GNU code.

If the goal were to develop native applications in C/C++ using Eclipse, these tools would suffice. For embedded cross-development, however, a few more pieces are needed. Eclipse with the CDT plug-in has no concept of using a remote debug connection to connect to an embedded processor. Zylin AS Consulting (www.zylin.com) offers the open-source Embedded CDT and another plug-in. Together, they allow the Eclipse debugger to connect to a remote target via any debug connection. (See the Zylin Plug-Ins section later in this article.) This debug connection is typically a JTAG, Ethernet, or serial connection. If a JTAG connection to the target is needed, a method must be provided for the GNU Project Debugger (GDB) to communicate to the target using this interface. Figure 1 shows the completed development system using a JTAG target connection. This article examines each of the required components in that system.

Eclipse

According to the official Eclipse web site (www.eclipse.org), the Eclipse Foundation manages the open-source development of "projects [that] are focused on providing a vendor-neutral open development platform and application frameworks for building software." The Eclipse Foundation has created the Eclipse Platform, which provides a feature-rich integrated development environment with a well-defined interface. This interface allows additional features to plug in and work seamlessly with the existing code.

Eclipse has rapidly gained favor among embedded-tools companies. It provides a sophisticated IDE into which they can plug their tools. Plus, those companies no longer have to worry about building and maintaining their own proprietary environments. With the Eclipse Public License, the creators of derivative works based on Eclipse also can retain their distribution rights. As a result, companies can focus on their core embedded competencies and still profit from their efforts.

This is excellent news for those trying to put together a free development environment. It makes available a commercial-quality IDE, which has the backing and support of a large number of both embedded and enterprise-software tools companies. As mentioned earlier, however, Eclipse by itself provides only a framework and some generic tools like an editor, code/project manager, and debugger interface. In order to construct a cross-development system, several more packages must be obtained and integrated into Eclipse.

CDT

Eclipse was originally developed in and for the Java programming language. The basic framework remains specific to the Java language. Most embedded cross-development projects still have device drivers, operating-system (OS) code, and applications written in C, C++, or assembly language. To make Eclipse compatible with and usable for C/C++, a sub-project called C/C++ Development Tooling was created. Its goal was to build a plug-in that would add these features to the basic Eclipse framework. That plug-in is available as a free download from Eclipse at www.eclipse.org/cdt/downloads.php.

With the Eclipse framework and CDT in place, the environment is capable of supporting and enabling code development in C/C++. But this environment will only work for native application development. For embedded cross-development, some issues still must be addressed—primarily the handling of remote debug connections to a target processor. The Zylin Plug-Ins section delves into this problem further. An assembler, compiler, linker, and loader are still required to generate downloadable code for the target Intel XScale processor. The next section discusses the GNU tools that provide these utilities.

GNU Tools

The Free Software Foundation makes available free source code for a wide range of programs and utilities. It includes a set of tools that together can provide everything necessary to build, link, load, and debug an embedded application. The combination of GNU binutils (www.gnu.org/software/binutils), the GNU Compiler Collection (GCC) (www.gcc.gnu.org), and GDB (www.sources.redhat.com/gdb) provides a fairly complete toolset for building and debugging embedded applications. These tools can be used on their own for this purpose. The binutils package provides an assembler, linker, archiver, and several other utilities for code development while the GCC provides the C/C++ compiler. For its part, the GDB allows the code to be downloaded to and debugged on the target processor.

There is a downside to using these tools, however: There is no graphical user interface (GUI) and no real integration of the tools. Used by themselves, the tools basically provide a command-line interface. Yet Eclipse with the CDT is capable of sufficiently integrating these tools into an environment with a GUI. As a result, most of the command-line tool use can be avoided.

The other problem is that the GNU tools for code development are generally provided only in source form. Although the tools support a huge array of various target processors and just about any host OS and hardware that one could imagine, the user usually has to configure and build the tools. This process can be a time-consuming, frustrating experience—especially for someone who hasn't done it before. Fortunately, several embedded-tools vendors make available free, pre-built versions of the GNU tools for ARM/Intel XScale technology. These versions can be simply downloaded and installed.

Zylin Plug-Ins

An environment consisting of Eclipse, the CDT plug-in, and the appropriate GNU tools is close to being a functional embedded cross-development system. As mentioned above, however, Eclipse and the CDT don't support remote target connections to an embedded processor. They assume that debugging is occurring on the host machine. In order to download the embedded code from the host to the target and then connect to a debug agent of some type running on the target hardware, some changes must be made in the way that the CDT handles debugging.

To address this problem, Zylin AS Consulting, a Norwegian company, has created and made available Embedded CDT and another small plug-in. Together, they "understand" and properly handle embedded debugging using GDB from within Eclipse. These free plug-ins are available at www.zylin.com/embeddedcdt.html.

It also is worth noting that an Eclipse Project called the Device Software Development Platform (DSDP) is now available. This project is specifically aimed at enabling Eclipse to be used for embedded cross-development. At some point in the future, the Zylin Embedded CDT modifications may therefore become unnecessary. Further information about the DSDP project can be found at www.eclipse.org/dsdp.

Target Connection

The only piece that remains missing in the integrated cross-development system is some type of debug communication method to connect the host computer to the target processor. This connection is usually made via a serial, Ethernet, or JTAG interface. If a project is using hardware for which a board support package already exists, it may be feasible to simply run a GDB debug agent on the target. GDB may then be connected to it using a serial or Ethernet connection.

For new custom Intel XScale technology-based boards, however, the interface of choice is usually JTAG. This debug interface is built into Intel XScale processors. It provides a dedicated debug connection directly to the processor core, which has the following advantages over using a serial or Ethernet connection:

  • It is built into the processor. To work, it only requires that the processor is powered and getting a clock signal.
  • It can be used to write and debug boot code and drivers that must be implemented and tested prior to getting a debug agent running on the processor.
  • It doesn't use any valuable target resources. A serial or Ethernet debug connection usually requires dedicated hardware for the interface in addition to using processor cycles and memory for a driver.

To connect a JTAG interface device to the target using the Eclipse/GNU environment previously described, a debug agent of some sort is required. GDB has a well-defined, back-end interface called GDB Remote. It has become a common standard for connecting the debugger to an embedded processor via a JTAG. Usually, this is handled by a proprietary standalone utility. That utility, which runs on the host, provides a TCP/IP port that will accept a GDB connection on the front end and connect to the JTAG hardware device on the back end. Most JTAG-interface-device vendors provide a utility for this type of connection with their hardware.

Figure 2 shows the Eclipse Debug Perspective during a debugging session using the system described in this article. The target is an Intel®81348 I/O processor evaluation board based on Intel XScale technology. The debug connection is made via a USB-connected JTAG device.


Brian Handley has over 20 years of experience working with embedded systems. He holds B.S. in Computer Science and Engineering from MIT.