eCos is an open-source, royalty-free, real-time operating system targeted to embedded applications and supported by the GNU development tools. This makes test driving eCos extremely inexpensive. Initially, the main hurdle is configuring the tools and source code to get your platform up and running. The source code to eCos is provided and the rights to change or add to the source are granted to the user. These rights are covered by the eCos Public License.[1]

One of the key aspects of eCos is its configuration system. It allows the programmer to control what functionality and features are included at runtime. Selecting from package modules, the programmer can layer different functionality, such as an Ethernet driver and networking support or a different scheduling algorithm, according to the needs of the application. Unwanted features can be eliminated easily to reduce the resource footprint. The configuration system also enables developers to employ third-party components to extend and enhance the functionality of the operating system.

eCos was designed for portability to a wide variety of 16-, 32-, and 64-bit processors and platforms. eCos is assembled from different components layered on each other to add the needed support for a given system. The base of this layered architecture is the hardware abstraction layer (HAL). Once the HAL has been ported to run on a given target's processor and any specific configuration needed for the target platform itself is added, eCos can be up and running quickly. Currently, numerous target architectures are supported by eCos and more ports will be added as programmers make them available. Table 1 lists the architectures supported at the time this goes to press.[2]

Table 1 Supported architectures
ARM	NEC V8xx
SuperH	PowerPC
Intel x86	MIPS
Matsushita AM3x

eCos is designed to support real-time applications by providing features such as preemptable tasks, low interrupt latency, different methods for synchronization, and a selectable scheduling policy. Device drivers, memory management, exception handling, timers, counters, and standard C and math libraries are all available. Complete development and debug tools are also provided, including software configuration and build tools, GNU-based compilers, assemblers, linkers, debuggers, and simulators. The eCos host tools are available in Linux and Windows versions.

eCos components

Hardware abstraction layer
The first component in the eCos system architecture is the hardware abstraction layer, which can be broken down into three sub-modules. The first HAL sub-module defines the architecture. Each processor family supported by eCos is said to be a different architecture. Each architecture sub-module contains the code necessary for CPU startup, interrupt delivery, context switching, and other functionality specific to the instruction set architecture of that processor family.

A second HAL sub-module defines the variant. A variant is a specific processor within a processor family. An example of an eCos feature at this level is support for an on-chip peripheral like a memory management unit (MMU).

The third HAL sub-module defines the platform. A platform, or board, is a specific piece of hardware that includes the selected processor architecture and variant. This module includes code for startup, chip select configuration, interrupt controllers, and timer devices.

Kernel
The eCos kernel consists of a scheduler and mechanisms for thread synchronization, exception handling, interrupt handling, and timers.

The scheduler is the heart of the kernel and contains two modes of operation: bitmap and multi-level queue scheduling. Currently, only one scheduler is supported at a time. The bitmap scheduler represents each thread, which must have a unique priority, with a bit in a bitmap. The multi-level queue implements a number of thread priorities, where threads of the same priority can be timesliced.

Thread synchronization is accomplished through the use of mutexes and semaphores. These can be combined with event flags and message queues for thread communication.

Exception handlers are routines for handling machine exceptions raised by hardware and software. Passed to the handler routines are a pointer to context information that was previously registered with the handler, the exception number, and an error code. Exception handlers may be set up globally, per-thread, or both.

Interrupt handlers process events caused by external devices. Since delivery of interrupts to the software is architecture specific, eCos provides a generalized scheme of utilizing an interrupt service routine (ISR) and a deferred service routine to maintain low interrupt latency.

Finally, the timer-related elements of the kernel include counters, clocks, and alarms.

Drivers
The driver component provides different means for I/O, including simple serial ports and Ethernet devices. The general mechanism for accessing a particular device is via a handle. Each device is given a unique name such as "/dev/ser1" or "/dev/tty1". Basic functions are provided to send and receive data from the device, as well as to manipulate the state of the driver or the actual device itself. Typical drivers included for specific platforms are Ethernet, flash, PCMCIA, and serial.

Development tools
The GNU development tools provide the build and debug capabilities and binary utilities support. These tools have been described in this magazine.[3],[4]

Third-party support
Along with the core functionality, additional features are available that greatly extend the capabilities of eCos for different applications. Additional functionality and third-party support for eCos include:

• POSIX 1003.1-EL/IX compatibility
• uITRON 3.0 compatibility
• RedBoot ROM monitor
• Filesystem
• Networking
• Web server
• PCI library
• USB slave support

Figure 1: eCos Configuration Table

eCos can be configured and built from either the command line or by using the Configuration Tool. The Configuration Tool gives the programmer a hierarchical representation of the eCos configuration, allowing the programmer to easily change the configuration or add and remove particular packages. Along with this, the Configuration Tool features the capabilities to build eCos and run the platform tests provided. Figure 1 shows the main screen of the Configuration Tool. I used version 1.3.1.2 of the Configuration Tool for this port, but a new alpha release is available. In addition to the tests for eCos and its individual packages, example applications are included.

Porting the eCos HAL

The first task when using eCos, or any RTOS for that matter, is getting it up and running on your own target hardware. For eCos, this is accomplished by porting the HAL to the new target.

I recently had the task of moving from an evaluation platform supported by eCos to custom hardware. In our application, Motorola's MPC860 PowerPC was the chosen processor. After reviewing the platforms available and supported by eCos for this processor, I decided the Motorola Computer Group's MBX860 board offered the features needed to code much of my application. The choice to utilize a development board was also motivated by the fact that the actual hardware would not be available for a few months. An evaluation board is not necessary to get eCos up and running. A PC can be used as the target platform or one of the supported processor simulators. The MBX860 board gave me a jump start on the software task and also provided a baseline platform to which I could return for testing. In addition to the development board, I obtained a background debug mode (BDM) emulator for the MPC860. The BDM/JTAG emulator assisted in the initial phase of bringing up my custom hardware and was very useful for downloading new code for testing. Using the emulator to download code expedited the process of updating the flash when code modifications were made.

HAL porting can be broken up into three types: platform, variant, and architecture porting. Platform porting typically requires the least amount of effort. Utilizing a current platform as a baseline, additional modifications for specific board initialization and memory layout are areas that need to be addressed.

Variant porting can be a more intensive task than platform porting, depending on what is currently available for a specific processor. Functionality that can be redefined and, therefore, needs to be addressed in the new variant are cache, memory management units, interrupts, and other features that may override implementations in the standard architecture HAL.

The most painstaking porting project is an architecture port. This is because you must ensure that suitable development tools for your target architecture actually exist. If a toolchain is available, you can then proceed to implement the new architecture HAL. Basing the new HAL on an existing architecture (the MIPS architecture should be used if possible) is the starting point. Then a platform port is also needed to get the target board functioning properly.

Prior to taking on the project of a variant or architecture port, it is a good idea to publicize your intention on the eCos discussion board to see if there are others already undertaking the same task.[5] If luck is on your side, you may even be able to find a port that has been contributed back to the eCos maintainers for testing and public release.

Before going forward with the eCos port, I have already gone through the initial board debug and have flash ROM properly up and running. Some low-level device testing was performed in order to validate the digital schematic design.

HAL directory and file layout
The main source code root is located in the ecos\packages directory, under which are the specific eCos packages. The HAL sub-module directory structures necessary for this port, based on the PowerPC architecture and MPC8xx variant, are described in Table 2, where the mytarget directory contains the new platform port. Descriptions of some of the key files located in these four sub-modules are given in Table 3.

Table 2: PowerPC HAL sub-module directory layout
HAL sub-module	Directory	Description
Common	hal\common	Contains the configuration options and functionality shared by all HALs, including generic debug functionality, driver APIs, and tests.
Architecture	hal\powerpc\arch	Includes functionality specific to the architecture and default implementations that can be overridden by a variant or platform implementation. For example, single-stepping debug capabilities, exception and interrupt vector handlers, cache definitions, co
Variant	hal\powerpc\mpc8xx	Covers any features additional to the CPU core such as extensions to cache or exceptions/interrupts, configuration options, and drivers for other on-chip devices. For example, the PowerPC contains the mpc8xx, ppc60x, ppc40x, and quicc variants.
	hal\powerpc\quicc
Platform	hal\powerpc\mytarget	Contains any configuration options specific to the platform., including platform initialization, memory layout, processor speed options, diagnostic and debugger I/O functions, and possible off-chip interrupt controller code.

Table 3: Key HAL files
HAL sub-module	Location and file	Description
Common	src\hal_if.c	Wrappers from the calling interface API to the features used for the implementation
Common	src\hal_stub.c	Wrappers for features required by the generic GDB stub
PowerPC architecture	cdl\hal_powerpc.cdl	Architecture-level package configuration data
PowerPC architecture	src\hal_intr.c	Interrupt handling functions
PowerPC architecture	src\powerpc.ld	Linker script file containing architecture-specific linker macros
PowerPC architecture	src\vectors.S	Exception vector, interrupt vector, and other initialization code, including the reset vector
MPC8xx variant	cdl\hal_powerpc_mpc8xx.cdl	MPC8xx package configuration data
MPC8xx variant	src\var_intr.c	MPC8xx-specific interrupt handlers
MPC8xx variant	src\var_misc.c	Variant initialization and miscellaneous MMU functions
QUICC variant	src\quicc_smcl.c	Basic serial I/O driver containing initialization, read, and write functions for the SMC1 port
MY_TARGET platform	cdl\hal_powerpc_mytarget.cdl	Platform package configuration data
MY_TARGET platform	src\mytarget.S	Platform-specific initialization