[Design Application]
Harness Robust Debugging Techniques To Improve Embedded Linux Systems
You can use Linux and still employ a methodology that includes all of the different phases of the ever-critical debugging process.
A growing number of embedded developers are experimenting with the Linux kernel and system services as a basis for new application development. But those developers embarking on the use of Linux as a target platform are faced with a number of debugging challenges. It's not easy to debug applications and drivers in a new operating-system environment and still achieve deployment deadlines. If they establish and follow a suitable debugging methodology, however, embedded developers can most efficiently use their time and meet time-to-market requirements.
Developers need a methodology for working at different phases of the debugging process and for providing software and hardware tools that support each phase (Fig. 1). The technique would incorporate native-code debugging, simulation, host/target debugging using the Joint Test Automation Group (JTAG) port or an in-circuit emulator (ICE), read-only-memory (ROM) monitor debugging, and debugging in conjunction with the real-time operating system (RTOS). Furthermore, the methodology should be fully supported with debugging tools from within a single software environment to give developers the power and convenience necessary to deliver fully reliable applications (Fig. 2).
A number of variants of Linux are available for embedded-system use, from standard kernels to those modified to support hard real-time applications. Of course, it's possible to perform certain kinds of embedded development by implementing some standard Linux distributions, such as Red Hat and Caldera. Individual developers, though, would have to customize the distribution to get the features and footprint appropriate for their projects, and possibly rewrite drivers or other code for better response.
At the next level of sophistication, several versions of Linux have been optimized for embedded systems, primarily by refining the standard Linux scheduler, tuning Linux device drivers, and slimming down the overall distribution to include only the most valuable features for embedded applications. These small-footprint embedded versions include variants derived from standard Linux, like Hard Hat Linux, ETLinux, LEM, and µClinux.
This category is best thought of as soft real-time operating systems. They serve a large part of the market's requirements through their ability to run in resource-limited environments with a measure of real-time response characteristics. For many, this represents an acceptable Linux solution.
The last method of adapting Linux for embedded systems is inserting a second operating-system kernel into the software architecture. This technique employs a small, dedicated kernel with time management in addition to the standard Linux kernel. Installed directly over the x86 processor, the dedicated kernel runs independently from the Linux kernel. Run on a higher level than the real-time kernel, the Linux kernel shares processor time with other tasks. In other words, Linux itself runs in the background and has to satisfy only soft real-time demands as long as no other task is activated. In this model, the real-time kernel takes over the tasks that require hard real-time responses.
This approach offers the potential of getting a hard real-time OS with many of Linux's advantages. Among the offerings available in this hard real-time category are RTLinux and the RTAI (for real-time application interface) Linux.
Not unexpectedly, the technique has both an advantage and a downside. On the positive side, it permits the integration of Linux features, like the user interface, communications protocols, and other services, into embedded systems while a separate, real-time kernel manages real-time capability. The downside of this technique is that adding a second OS, regardless of its putative real-time characteristics, introduces a second set of RTOS-specific application program interfaces (APIs) and potentially starves the applications running in the "normal" Linux environment.
GNU Tools May Fall Short As for development tools, the GNU (GNU's Not Unix) tools, which are already popular with embedded developers, are "naturals" for use with embedded Linux. These tools could be a good solution for many situations as they make rebuilding kernels and parts of applications easier. But if a de-veloper depends on strong support because the em-bedded system needs special tool features, things get complicated.
Unfortunately, little documentation is available for GNU tools in such cases, which means finding a solution might be extremely time-consuming. Support contracts with GNU-tool distributors are a potential remedy, but they're not cheap. Obviously, there's no way around a certain financial cost in this area. GNU tools are fine for standard applications on native systems, but they're far from optimal for embedded use.
Because of its desktop heritage, most embedded development takes place using the x86 architecture as the target. But traditional embedded processors, such as a Motorola ColdFire or 68K, are starting to gain popularity as an embedded target. In the vast majority of cases, the host development system is a Windows PC. In a few instances, it may be a Unix system (usually Sun Solaris), or even a Linux system. This relative homogeneity of host systems makes it possible to outfit a robust embedded tool chain for Linux target development.
Most embedded programmers start with the GNU debugger (GDB). It's a standard debugger that enables programmers to start programs (specifying anything that might affect program behavior), cause the program to stop on specified conditions, and examine what has happened, as well as change things in the program.
Reprints
