Back in Eclipse, you should be in the C/C++ perspective. Select the target project in the Project Explorer view and execute Run→Debug. Eclipse switches to the Debug perspective and you should see virtually the same thing you did earlier with the simulation version of the thermostat. On the target, gdbserver responds that it has established a debugging session with host 192.168.1.2.
Play around with it to confirm that the target version really does behave like the simulation version. Note that program I/O is through the minicom window. When you’re finished terminate the debug session. gdbserver responds that its child process, the target executable, has exited and then gdbserver itself exits.
Figure 5.14 attempts to put this whole process into graphical perspective. GDB itself is conceptually split into two major components that you can think of as the “front end” and the “back end.” The front end is effectively a client and provides the user interface. The back end is a server that controls and interacts with the program under test.
Figure 5.14: GDB architecture.
The back end is architecture-dependent so it knows how to do things like disassemble machine code and set breakpoints. When we debugged the simulation thermostat, the back end simply ran the program under test on the workstation.
Things got a little more complicated when we moved to debugging on a remote target board. Now the back end running on the host has to know that it’s not running the program under test locally, but rather becomes a client to gdbserver running the program under test on the target. GDB provides a well-defined protocol for this communication. The primary role of gdbserver is to get and set memory locations and processor registers, and to maintain control over execution of the program under test.
The existence of a well-defined and public protocol for communicating between the GDB back end and gdbserver opens other possibilities for communicating with the target. Specifically, vendors of In Circuit Emulators (ICE) and JTAG boxes can use that protocol to make their products useable from GDB and Eclipse.
Summary
This chapter has delved deeper into the Eclipse C Developers’ Toolkit (CDT) to look at issues such as supplying your own Makefiles, cross-compiling for target embedded hardware, and debugging an application on a remote target board. We also explored the notion of using high level simulation to get started with application software testing before any target hardware is available.
The next chapter looks at the Device Software Development Platform (DSDP), another Eclipse project related to embedded software development. In particular, DSDP provides target management capabilities that further simplify the process of connecting to a remote target.
CHAPTER 6
Device Software Development Platform
The Eclipse Device Software Development Platform (DSDP) extends CDT to address specific needs of embedded device software developers. It consists of six subprojects, some of which are farther along than others:
• Target Management (TM)
• Remote System Explorer (RSE)
• Native Application Builder (NAB)
• Embedded Rich Client Platform (eRCP)
• Mobile Tools for the Java Platform (MTJ)
• Tools for Mobile Linux (TmL)
In this chapter, we’ll take a closer look at Target Management and the Native Application Builder. The Embedded Rich Client Platform is tied in with plug-in development that we’ll explore in the next chapter. Mobile Tools for Java and Tools for Mobile Linux are currently in an “incubation” stage, making them a little difficult to describe accurately and thoroughly.
But before proceeding, we should look at how Eclipse manages updates and extensions.
6.1 Adding on to Eclipse
The beauty of Eclipse is that it can be easily extended through the plug-in mechanism. Currently, your Eclipse installation includes the base platform, CDT, the Rich Client Platform (RCP), and a CVS version control system client. For this chapter we’ll install some additional features.
There are a couple of different approaches to adding features to Eclipse. The simplest approach is to download a zip file of one or more plug-ins and just unzip it in your Eclipse directory. Oddly though, plug-ins don’t seem to carry any information about what other plug-ins or features they may depend on. Thus, you may install a plug-in only to find that it doesn’t work because it’s dependent on something else that isn’t installed and isn’t identified.
Eclipse has addressed this issue with the concept of a feature, which bundles together plug-ins that are logically related to perform some useful function. Features are then published to an update site on the Internet from where they can be downloaded by the Eclipse Update Manager. Organizations that create Eclipse plug-ins are encouraged to maintain an update site and publish their plug-ins as features.
Start up Eclipse if it’s not already running and select Help→Software Updates to bring up the menu in Figure 6.1. The Available Software tab is displayed, listing update sites that can be searched for new features. You can add remote update sites in the form of URLs or Local sites, such as a CD. An Archive site is a local site packaged as jar or zip files.
Figure 6.1: Update Manager.
Several sites are already available for searching. Expand the Ganymede entry. The Update Manager goes to the selected site to discover what new features are available and presents a list of feature categories. Scroll down to and expand Remote Access and Device Development (Figure 6.2).
Figure 6.2: Expanded feature category.
Check the box next to Remote Access and Device Development to select all 11 of its features. When you click Install, the Update Manager automatically resolves any dependencies and downloads them as well. You are asked to review and confirm the items to be installed. Next, you’ll be asked to accept the license terms. Click Finish.
Install offers the option of running in the background so that you can continue working in Eclipse while the download is in progress. This is a useful feature, since downloads can take a while. When the installation has completed, Eclipse suggests that you restart the system for the changes to take effect. Some changes can be applied without restarting, but generally it’s a good idea to restart.
You can get additional details on a feature by selecting it and clicking the Properties button. Figure 6.3 is an example of the General Information category for one of the Remote System Explorer features.
Figure 6.3: Feature information.
6.1.1 Installing Features in External Directories
Normally, features are installed in eclipse/features and plug-ins are installed in eclipse/plugins. If, for whatever reason, you should need to reinstall Eclipse, all of the additional features and plug-ins you had previously installed would also have to be reinstalled. But if they’re installed in an external directory, reinstalling Eclipse itself doesn’t affect them.