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]

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 ecospackages 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.

Load-and-go functionality
Now that we are acquainted with the layout of the HAL directories and files, the first goal for the platform port is to create a minimal stub residing in flash that allows code to be downloaded and run from RAM. In order to ease the pain in achieving load-and-go functionality, you can utilize a ROM monitor, or, as in my case, a JTAG/BDM emulator. The emulator provides the ability to configure the PowerPC registers to interface to and program the flash.

Getting the new platform noticed
The name used for this new platform is “MY_TARGET”. Since the MBX board is used as the baseline for this porting process, a copy of this platform tree is made into the new halpowerpcmytarget directory. Next, files need to be renamed in order to reflect the new MY_TARGET platform. For example, following the eCos file naming convention, the platform package configuration file originally named hal_powerpc_mbx.cdl was changed to hal_powerpc_mytarget.cdl.

Listing 1: hal_powerpc_mytarget.cdl

## PowerPC/MY_TARGET platform HAL package configuration data#	cdl_package CYGPKG_HAL_POWERPC_MYTARGET {display	"MY_TARGET PowerPC board"parent  	CYGPKG_HAL_POWERPC		# Architecturerequires  	CYGPKG_HAL_POWERPC_MPC8xx		# Variantdefine_header  	hal_powerpc_mytarget.hinclude_dir  	cyg/haldescription  	"The MY_TARGET HAL package provides the support needed to run eCos on a MY_TARGET platform equipped with a PowerPC processor."	}

Now the options in the component definition language (CDL) file need adjusting to reflect the new target. Listing 1 shows an example of the CDL terminology for the new platform.

All references to the MBX platform need to be modified to refer to the new target instead. Other option changes include statically configuring the board clock speed, removal of the option to select a 32-bit flash for booting, and removal of the MBX platform test. Verification of the MPC8xx variant CDL file is necessary since it is utilized by the MY_TARGET platform.

The MBX platform also uses a flash device package that contains driver functions for controlling its on-board flash. This driver is located in the devsflashpowerpcmbx subdirectory. A copy of the MBX board flash device driver tree is needed to accommodate the flash used on the new target. The steps needed to accomplish this are the same as the MBX-to-MY_TARGET platform copy detailed previously.