SEMINAR REPORT ON eCOS(EMBEDDED CONFIGURABLE OPERATING SYSTEM)
Real-Time Operating Systems (RTOS) are available from a wide range of sources. A relative newcomer to the RTOS arena is the Embedded Configurable Operating System or eCos.
eCos is a excellent real-time performance, low latency and deterministic behavior make eCos a viable solution in many demanding signal processing applications. A layered architecture encourages portability and code reuse.
Similar to Linux, the eCos is open source kernel distribution. eCos is provided as an open source runtime system supported by the GNU open source development tools. Developers have full and unfettered access to all aspects of the runtime system. No parts of it are proprietary or hidden, and you are at liberty to examine, add to, and modify the code as you deem necessary.
One of the key technological innovations in eCos is the configuration system. The configuration system allows the application writer to impose their requirements on the run-time components.
An operating system (OS) is a computer program that manages the hardware and software resources of a computer, the OS performs basic tasks such as controlling and allocating memory, prioritizing system requests, controlling input and output devices, facilitating networking, and managing files. It also may provide a graphical user interface for higher level functions. The lowest level of any operating system is its kernel. This is the first layer of software loaded into memory when a system boots or starts up. The kernel provides access to various common core services to all other system and application programs. These services include, but are not limited to: task scheduling, memory management, disk access, and access to hardware devices
eCos (embedded Configurable operating system) is an open source, royalty-free, real-time operating system intended for embedded systems and applications. The highly configurable nature of eCos allows the operating system to be customised to precise application requirements, delivering the best possible run-time performance and an optimised hardware footprint. A thriving net community has grown up around the operating system ensuring on-going technical innovation and wide platform support.
A real-time operating system (RTOS) is a class of operating system intended for real-time applications. Such applications include embedded (programmable thermostats, household appliance controllers, mobile telephones), industrial robots, spacecraft, industrial control.
eCos was designed for devices with memory footprints in the tens to hundreds of kilobytes, or with real-time requirements. It can be used on hardware that doesn't have enough RAM to support embedded Linux, which currently requires a minimum of about 2 MB of RAM, not i
ncluding application and service requirements.
eCos runs on a wide variety of hardware platforms, including ARM, CalmRISC, FR-V, Hitachi H8, IA-32, Motorola 68000, Matsushita AM3x, MIPS, NEC V8xx, PowerPC, SPARC, SuperH and Nios II.
Included with the eCos distribution is RedBoot, an open source application that uses the eCos Hardware Abstraction Layer to provide bootstrap firmware for embedded systems. Even with so many commercially available run-time solutions, more than 50 percent of all embedded projects today are built using in-house proprietary, or "roll your own", real-time technologies (Venture Development Corporation). The original eCos developers (Cygnus Solutions which later became part of Red Hat) partnered with microprocessor vendors and embedded product manufacturing companies to develop eCos around the requirement of an open, technically advanced run-time solution. eCos was designed to address the following fundamental issues that force embedded product manufacturing companies to develop their own run-time technologies:
Â¢ Cost - eCos is royalty free and license cost free. It is portable across chip architectures, which makes it well-suited for software developers of high-volume applications in consumer electronics, telecommunications, automotive and other deeply embedded applications,
Â¢ Control - eCos is an open-source run-time technology which fosters innovation, reduces risk, and places customers in control of their application specific content by enabling programmers on the Internet to read, redistribute, and modify the source code for eCos.
Â¢ Technical Fit - eCos provides source-level configuration (more than 200 configuration points) to exactly match application needs and is tightly integrated with the latest version of GNUPro tools, including highly optimized compilation technology, multi-threaded debugging, graphical configuration, test suites, etc.
. eCos is a fully open source project, resulting from the efforts of a large development community on the net. The active eCos developers have many years of experience in this field through their work on other open source projects like Linux, the gcc and g++ compilers, the gdb debugger, and many other tools. The same development model has proved an overwhelming success in many other projects.
EMBEDDED OPERATING SYSTEM
An embedded operating system is an operating system for embedded computer systems. These operating systems are designed to be very compact and efficient, forsaking many functionalities that non-embedded computer operating systems provide and which may not be used by the specialized applications they run. They are frequently also real-time operating systems.
Embedded operating systems include:
Â¢ Embedded Linux
Â¢ LynxOS RTOS
Â¢ Windows CE
Â¢ Windows XP Embedded
ORIGIN OF eCOS
Â¢ A Brief History
Where It All Startedâ€Cygnus Solutions
Michael Tiemann, David Henkel-Wallace, and John Gilmore founded Cygnus Solutions in 1989.The idea behind Cygnus Solutions was to provide high-quality support and development foropen source software. Open source describes practices in production and development that promote access to the end product's source materialsâ€typically, their source code. Before open source became widely adopted, developers and producers used a variety of phrases to describe the concept; the term open source gained popularity with the rise of the Internet and its enabling of diverse production models, communication paths, and interactive communities. Subsequently, open source software became the most prominent face of open source practices.
Michael Tiemann, who contributed numerous GNU compiler ports and also wrote the first native C++ compiler (GNU C++ or G++), took on the task of working on GCC; David Henkel-Wallace worked on the binary utilities(binutils) and the library; and John Gilmore worked on GDB.John Gilmore decided to become the new GDB maintainer.Today it is called the GNUPro Developers Kit.
The kit includes:
Â¢GCCâ€the highly optimized ANSI-C compiler.
Â¢G++â€ANSI-tracking C++ compiler.
Â¢GDBâ€source- and assembly-level debugger.
Â¢Cygwinâ€UNIX environment for Windows.
Â¢Insightâ€a graphical user interface (GUI) for GDB.
Â¢Source-Navigatorâ€source code comprehension tool
GNU is a free operating system consisting of a kernel, libraries, system utilities, compilers, and end-user applications. Its name is a recursive acronym for "GNU's Not Unix", which was chosen because its design is Unix-like, but differs from Unix by being free software and by not containing any UNIX code. The plan for the GNU operating system was announced in September 1983 by Richard Stallman and software development work began in January 1984. As of 2006, GNU is being actively developed. The project to develop GNU is known as the GNU Project, and programs released under the auspices of the GNU Project are called GNU packages or GNU programs.
The idea of open source is then to eliminate the access costs of the consumer and the creator by reducing the restrictions of copyright. This will lead to creation of additional works, which build upon previous work and add to greater social benefit. Additionally, some proponents argue that open source also relieves society of the administration and enforcement costs of copyright.. The self-made protections free the general society of the costs of policing copyright infringement. Thus, on several fronts, there is an efficiency argument to be made on behalf of open sourced goods.Cygnus Solutions was founded in 1989 with the idea of providing high quality support and development of open source software. The company successfully packaged, maintained and supported a suite of tools including the GNU GCC compiler and the GNU GDB debugger. In 1997, with the success of the open source support model, Cygnus began development of a real-time operating system to complement their GNUPro tool suite. The goal was to produce a small, configurable real-time operating system that would deliver the performance of some of the best known commercial solutions, but be royalty-free. The result was the eCos.
In 1999 Cygnus Solutions was acquired by Red Hat. eCos has remained open source and is generally maintained by the engineering community that uses it. It has grown and matured over the past few years and now supports more than 16 different processors, with more being added regularly. It has been used in many commercial products including automotive, imaging, automation, video gaming and others. Military and security applications have included radar array systems, fingerprint and retina identification, and satellite communications.
eCos is designed around a single-process, single-address space, multiple-thread model. Application code is linked directly with the eCos kernel to be deployed in the target environment.
Most of eCos is written in C++, with some machine-dependent portions written in C and assembly language. eCos also includes a complete C-language kernel API. C++ is used with care taken to exploit the high-level abstractions available in that environment without introducing unnecessary overheads. To keep run-time overhead low, neither C++ exceptions nor RTTI are used within the kernel. Additionally, the kernel is completely static (for instance, there are no uses of new), and the only use of C++ templates is to provide type-checked macros. An example of the use of templates is in the memory-pool management classes, wherein a template is used to wrap generic thread synchronization, waiting, and atomicity around any of several simple memory-pool managers.
One of the key design features of eCos is its configurability. The eCos kernel comprises a set of packages, with you controlling which packages are included in the target application. Only those packages that are required by the application need to be included in the final software. Furthermore, as much as possible, all individual components within the packages are also configurable.
An example of this level of configurability might be the description of a serial I/O device in the system. The top-most choice would indicate that serial I/O is required. Then for the target platform, any of the standard serial devices may be configured into the system (or left out, as dictated by the application). Each of these devices can be configured in turn, with parameters such as the default baud rate or the size of kernel buffers to use among the possible choices.
Embedded systems have an amazing range of requirements, from 4 bit controllers up to large radar arrays with a thousand or so top of the range processors. Even if we limit the eCos target market to deeply embedded devices and to processors for which a gcc port is available, it is not possible to write a single system which meets everybody's requirements. The conventional approach forces application developers to adapt their software so that it works within the limitations of the operating system. The eCos approach is to provide a whole range of options and let the developer configure a system that best matches the needs of the application. Typical configuration options include the type of scheduler and the number of priority levels. The current release of the system has over 200 such options, and plenty more will be added as the system evolves.
Code and data size are vitally important for many embedded applications, so configurability must be achieved without adding any overheads. Some of it can be done at link time, but for maximum benefit most of it happens at compile time. It is possible for a configuration option to affect a single line of code, when this is appropriate. On the other hand a single configuration option might control the presence or absence of a complete TCP/IP stack. For system code written in C or C++ the main mechanism that is employed is C preprocessor #ifdef statements, which will be familiar to most embedded application developers .The eCos configuration system does not affect how you develop your own application code. It is not necessary to write your application in any special language, or to provide lots of configuration options in your own code, or to use a special development environment. The main output from the configuration system is a library that gets linked with your application code in the usual manner.
THE CDL LANGUAGE
All configuration options available within eCos are described in a high-level language called the Configuration Description Language (CDL). The use of CDL in eCos lets the ConfigTool support consistency and dependency checking, which guarantees that the chosen configuration works properly in the final product.
The principle unit of configuration within eCos is the package -- a complete, standalone layer of functionality that may or may not be present. In many cases, one package will require the presence of another package, but care was taken to keep these units as independent as possible.
The CDL is just a set of specially formatted comment strings within a C/C++ include file that describes the package.ConfigTool lets you specify the layout of physical memory sections in the target environment. These include RAM and ROM segments, as well as other variations. Different environments can be defined easily; such as RAM-based operations or ROM-based applications. Thesdefinitions are imported into the final eCos application, allowing for flexible control over these context to another, and so on.
PROCESSOR AND EVALUATION PLATFORM SUPPORT
eCos supports a wide variety of popular embedded processor architectures. This makes eCos a
great choice for companies using many diverse hardware architectures on different product lines .Once the eCos HAL has been ported to a new architecture.
The eCos software support is for standard commercial evaluation platforms on the market
today. The main processor architectures supported include:
Â¢ Fujitsu FR-V
Â¢ Hitachi H8/300
Â¢ Intel x86
Â¢ Matsushita AM3x
Â¢ NEC V8xx
Â¢ Samsung CalmRISC16/32
eCOS CORE COMPONENTS
Certain standard functionality is expected in a real-time embedded operating system,
including interrupt handling, exception and fault handling, thread synchronization, scheduling,
timers, and device drivers. eCos delivers these standard components with the real-time kernel as the central core.
The core components are:
Â¢Hardware Abstraction Layer (HAL)â€providing a software layer that gives general access to the hardware.
Â¢Kernelâ€including interrupt and exception handling, thread and synchronization support, a choice of scheduler implementations, timers, counters, and alarms.
Â¢ISO C and math librariesâ€ standard compatibility with function calls.
Â¢Device driversâ€ including standard serial, Ethernet, Flash ROM, and others.
Â¢GNU debugger (GDB) supportâ€provides target software for communicating with a GDB host enabling application debugging.
Both eCos and the application run in supervisor mode. In the eCos system, there is no
division between user and kernel mode.
eCos is designed as a configurable component architecture consisting of several key software
components such as the kernel and the HAL.
As application complexity and project costs continue to rise, software portability and reuse are two prime concerns of both engineers and managers. RTOSes typically address these issues with a layered software architecture that abstracts the details of the target hardware from the application, enhancing both application portability and reuse. eCos follows this paradigm with a well-defined interface between application and target-specific components.
The dashed line in Figure 1 divides the layers of software components. The first layer above the dashed line, the kernel, networking stack and file system are independent of the processing hardware or board product. These components interface with the upper compatibility and library layers to present a consistent platform for the application layer. Below the dashed line is the RedBoot ROM monitor, the HAL or Hardware Abstraction Layer and the device drivers. These components are written, configured and optimized for the specific target hardware and should be supplied by the hardware vendor.
Â¢ Hardware Abstraction Layer (HAL)
The HAL abstracts the underlying hardware of a processor architecture and/or the platform to a level sufficient for the eCos kernel to be ported onto that platform.
The eCos system was designed to be portable to different architectures and platforms with minimal effort. To accomplish this, the system is separated into layers .
The most basic layer is the Hardware Abstraction Layer (HAL). The HAL provides access to architecture and platform-specific details in a completely architecture- and platform-independent way. This means that if a higher layer of the system (the kernel, for instance) needs to use a potentially machine-dependent function, it uses the HAL version of that
function. Higher levels are also allowed access to the HAL, but in general, this is discouraged.
The HAL functions and capabilities are defined as C/C++ macros in a set of files: <cyg/hal/hal_arch.h>, <cyg/hal/hal_intr.h>, <cyg/hal/hal_cache.h>, and <cyg/hal/ hal_io.h>. Some of the macros defined in these files may be constant or even empty, depending on the platform details. The point of using the HAL in this way is to make the rest of the system totally independent of the machine details. This layering works so well that absolutely no code changes are required for a port to a new architecture outside of the HAL layer.
The HAL has been implemented according to the following general principles:
1. The HAL is implemented in C and assembler, although the eCos kernel is largely implemented in C++. This is to permit the HAL the widest possible applicability.
2. All interfaces to the HAL are implemented by CPP macros. This allows them to be implemented as inline C code, inline assembler or function calls to external C or assembler code. This allows the most efficient implementation to be selected without affecting the interface. It also allows them to be redefined if the platform HAL needs to replace or enhance a definition from the architecture HAL.
3. The HAL provides simple, portable mechanisms for dealing with the hardware of a wide range of architectures and platforms. It is always possible to bypass the HAL and program the hardware directly, but this may lead to a loss of portability.
Some of the items described by the HAL are:
Â¢ Architecture details, such as word size endianness.
Â¢ Access to common I/O devices, such as the system clock.
Â¢ Thread context details. Initialization of new thread contexts, switching from one thread context to another, and so on.
Â¢ Platform initialization. eCos expects the HAL to initialize the hardware platform.
Â¢ GDB support. Details and management of interacting with the GNU Debugger. In general, eCos doesn't care about this, but the HAL provides it.
Â¢ Cache support. The HAL can provide standardized support for instruction and data caches, the details of which depend on the platform.
Â¢ MMU support. eCos does not require the use of an MMU, nor is any particular support expected. However, on some architectures the MMU must be used, and it is up to the HAL to provide this support. For example, some architectures such as the ARM require the MMU to be enabled for the caches to operate.. Some embedded processors have a memory management unit. In some cases this must be enabled to allow the cache to be controlled, particularly if different regions of memory must have different caching properties. For some purposes, in some systems, it will be useful to manipulate the MMU settings dynamically.
Â¢ Interrupt and trap/exception handling, including setting up interrupt handlers, functions to enable and disable interrupts, and the like.
Default exception handling:Most synchronous exception vectors will point to a default exception VSR which is responsible for handling all exceptions in a generic manner.Since most exceptions handled by this VSR are errors (or breakpoints when a program is being debugged), its default behavior should be to save the entire machine state, disable interrupts, and invoke the debugger's entry point, passing it a pointer to the saved state.
Default interrupt handling:Most external interrupt vectors will point to a default interrupt VSR which decode the actual interrupt being delivered and invokes the appropriate ISR.
The default interrupt VSR has a number of responsibilities if it is going to interact with the Kernel cleanly and allow interrupts to cause thread preemption.
Portability and Performance
The HAL is a key component in eCos portability. It presents a consistent API to the upper OS layer, allowing the same application code to run on any platform that is supported with a HAL. This means that each hardware platform requires its own HAL to support the specific processor and peripheral set of the target.
As a complete package, the HAL often includes components for platform-specific resources, loading and booting, interrupt handling, context switch support, cache startup support, source level debugging, ROM monitor support, as well as other features. In keeping with the eCos goal of configurability, only HAL components that are actually required for a specific platform or application are built into the kernel. Selecting which components are built is simplified through the eCos Configuration Tool. This Graphical User Interface (GUI) displays details of each component and allows the user to choose which components will be built.
The HAL also provides some important board-specific, real-time facilities including an exception handler, an interrupt handler and virtual vectors. The exception handler allows an embedded system to recover from hardware exceptions like overflow, a bad memory access or a divide-by-zero operation. An unrecoverable situation in a military system might prove disastrous. Virtual vectors support the ROM-based monitor, allowing application debugging over an Ethernet or serial communication channel.
Handling external interrupts is a fundamental requirement of most embedded real-time systems and how they are handled is crucial to overall performance. The HAL supports two types of interrupts. Interrupt Service Routines (ISR) are used for simple tasks that can be dispatched quickly. Deferred Service Routines (DSR) are used for complex tasks that can be implemented as soon as possible, but with interrupts re-enabled to maintain low latency for the ISRs. Having both types of interrupt handling available lets a user prioritize interrupts according to system needs and still guarantee low latency.
In order for this model to work, the ISR should run quickly. If the service requirements for the interrupt are small, the interrupt can be completely handled by the ISR and no DSR is required. However, if servicing the interrupt is more complex, a DSR should be used. The DSR will be run at some later time, at the point when thread scheduling is allowed. Postponing the execution of DSRs until this time allows for simple synchronization methods to be used by the kernel.
Further, this controlled calling -- when thread scheduling is allowed -- means that DSRs can interact with the kernel, for example by signalling that an asynchronous operation has completed.
In order to allow DSRs to run with interrupts enabled, the ISR for a particular interrupt source (or the hardware) must arrange that that interrupt will not recur until the DSR has completed. In some cases, this is how the hardware works. Once an interrupt is delivered another interrupt will not occur until re-enabled. In the general case, however, it is up to the ISR to enforce this behavior. Typically the ISR will "mask" the interrupt source, thus preventing its recurrence. The DSR will then unmask the interrupt when it has been serviced thus allowing new occurrences of the interrupt to be delivered when they happen.
The eCos kernel was designed to satisfy four main objectives: 1) Low interrupt latency, the time it takes to respond to an interrupt and begin executing an ISR. 2) Low task switching latency, the time it takes from when a thread becomes available to when actual execution begins. 3) Small memory footprint, memory resources for both program and data are kept to a minimum by allowing all components to configure memory as needed. 4) Deterministic behavior, throughout all aspects of execution, the kernelâ„¢s performance must be predictable and bounded to meet real-time application requirements. Table 1 lists these key metrics.
eCos offers an interesting feature to further improve application performance: the option to build with or without an actual kernel. In simple applications that donâ„¢t require scheduling or multi-tasking, eCos functions to set up and run the hardware can be built without the kernel, improving execution speed and reducing the memory footprint. In many traditional DSP applications this type of processing is common.
Moving in the other direction, eCos can be a full-featured OS with a complete set of kernel and core components including: scheduling and synchronization, interrupt and exception handling, counters, clocks, alarms, timers, POSIX and Ã‚ÂµITRON compatibility layers, ROM monitors, RAM and ROM file systems, PCI support, TCP/IP networking support, as well as features continuously being added and contributed by third parties. As mentioned earlier, the eCos Configuration Tools allow easy configuration and building of the kernel. A complete set of kernel features is provided to support applications built using eCos. These include:
Â¢ Thread primitives. Functions to create, destroy, suspend, and resume threads are provided.
Â¢ Synchronization primitives. Multiple mechanisms for thread synchronization are provided, including mutex and condition variables, binary and counting semaphores, message/mail boxes, and general-purpose event flags. Thread synchronization:To allow threads to cooperate and compete for resources, it is necessary to provide mechanisms for synchronization and communication. The classic synchronization mechanisms are mutexes/condition variables and semaphores. These are provided in the eCos kernel, together with other synchronization/communication mechanisms that are common in real-time systems, such as event flags and message queues
Â¢ Timers, counters, and alarms. A set of flexible counter and alarm functions is provided. If the hardware provides a periodic clock or timer, it will be used to drive timing-related features of the system. Many CPU architectures now have built in timer registers that can provide a periodic interrupt. This should be used to drive these features where possible. Otherwise an external timer/clock chip must be used.
Â¢ Standard libraries. A complete Standard C run-time library is provided. Also included is a complete math run-time library for high-level mathematics functions, including a complete IEEE-754 floating-point library for those platforms without hardware floating points.
Â¢ Device drivers. A complete, extensible package supporting general-purpose I/O devices is provided. Most platform ports also come with a set of drivers for standard devices, such as serial I/O, and the like.
Configuring eCos's Scheduler
At the core of the kernel is the scheduler. This defines the way in which threads are run, and provides the mechanisms by which they may synchronize. It also controls the means by which interrupts affect thread execution. No single scheduler can cover all possible system configurations. For different purposes we will need to cover several scheduling polices. In this release three schedulers are provided :
Â¢ a bitmap scheduler
Â¢ a multi-level queue scheduler
Â¢ a lottery scheduler
At present the system will only support a single scheduler at any one time. Future systems may allow multiple schedulers to co-exist, but this will be hidden behind the scheduler API in the current release.
To make scheduling safe we need a mechanism to protect the scheduler data structures from concurrent access. The traditional approach to this is to disable interrupts during the critical regions. Unfortunately this increases the maximum interrupt dispatch latency, which is to be avoided in any real-time system.
One area within eCos that makes considerable use of configuration options is the thread scheduler. The standard system includes two completely different scheduler designs. The bitmap scheduler is a simple scheduler that supports a finite number of threads, each with a unique priority. A bitmap is kept of threads that are ready to execute, with one bit per thread (thus the name).
The other standard scheduler is a more traditional, multiple-priority, queue-based scheduler. Using this scheduler, the system supports any number of threads, each with an execution priority within some defined range. More than one thread can have the same priority and will execute on a first-come, first-served basis.
Configurability is an important feature of eCos as well as other embedded RTOSes. Unfortunately, with more flexibility usually comes more managing and maintenance of the various kernel configurations. A key component for managing this flexibility is the eCos Configuration Tool. This GUI provides a simple way to select and modify kernel components and options. Context-sensitive online help is available and a short description of each component is displayed in an interactive window as it is selected. Kernel build status and details of any component conflicts, should they arise, are displayed in an output window. Cut, paste and search functions make this interface easy to use.
Red Hat Embedded Debug and Bootstrap (RedBoot) provides a bootstrap and debugging environment for eCos-based systems. Developed as an eCos kernel-less application, it can be used to boot an eCos application on any embedded system and with many different RTOSes. Some of the features RedBoot includes are: boot scripting support, Command Line Interface (CLI) for monitor and control support, access via serial or Ethernet ports, GNU GDB debugger support, Flash image system support, and network bootstrap support using BOOTP or static IP address configuration. As with the eCos kernel, RedBoot is open source, satisfying the requirement of many military applications. RedBoot allows download and execution of embedded applications via serial or ethernet, including embedded Linux and eCos applications. It can be used for both product development (debug support) and in deplayed products in the field (Flash update and network booting). RedBoot can be used to communicate with GDB (the GNU Debugger) to debug applications via serial or ethernet, including the ability to interrupt a running application started by GDB.
. RedBoot was originally developed by Red Hat, but is now developed and maintained on the net alongside eCos as an open source project. All sources and documentation for RedBoot, and the eCos operating system on which it is based, are freely available without license or royalties. Two additional tools essential for any software development, regardless of which RTOS it is built on, are a compiler and debugger. eCos uses the GNU GCC compiler and the GNU GDB debugger. Both tools are available as free downloads from the Internet and are maintained by the GNU project and the Free Software Foundation. Another tool to round out the development environment is the Insight graphical front end for GDB. It provides many of the same basic features as commercial debugger GUIs including: source code stepping, breakpoint insertion and memory window displays, but in a free distribution. While these tools are very functional, it is important to realize that they donâ„¢t offer the vast array of features available in many commercial tool packages.
In general, when developing with eCos and the GNU tools, support is available from the software community through mailing lists where questions are posted and responded to. This type of fragmented support might not be an acceptable risk in some short commercial development cycles or critical military cycles. In contrast, many commercial RTOS solutions sell supplemental technical support, some with guaranteed quick response time, to solve problems as they arise.
As eCos originated from Red Hat, probably most famous for its distribution of the Linux Operating System, it has become a common misconception that eCos is Linux or in some way based on Linux. However eCos is a completely separate product, with a separate source base. eCos does have an EL/IX level 1 compatibility layer though, allowing it to be compatible with many of the Linux APIs.
Beyond configuration flexibility, another key goal of the original eCos kernel design was execution performance. In measured performance in actual applications eCos performs excellently. For example, when eCos was run on the Pentek Model 4205 600 MHz, MPC7455 G4 PowerPC with 2 Mbytes of external L3 cache, thread switch time was recorded at 0.98 Ã‚Âµsec. Switch times between 1 and 10 Ã‚Âµsec are typically considered very good for commercially available RTOSes or for optimized versions of real-time Linux. Table 2 shows execution times recorded for some of the other key scheduling and synchronization functions.
The license does not require users to release the source code of any applications that are developed with eCos. However, if anybody makes any changes to code covered by the eCos license, or writes new files derived in any way from eCos code, then we believe that the entire user community should have the opportunity to benefit from this. The license stipulates that these changes must be made available in source code form to all recipients of binaries based on the modified code, either by including the sources along with the binaries you deliver (or with
any device containing such binaries) or with a written offer to supply the source code to the general public for three years. It is perhaps most practical for eCos developers to make the source code available online and inform those who are receiving binaries containing eCos code, and probably also the eCos maintainers, about the location of the code
Aside from performance, a prime reason why eCos has been employed in many embedded commercial and military applications is that it can be used and distributed without royalties or licensing fees. It is distributed under a modified version of the GNU Public License (GPL). Linux is distributed under the standard GPL and this has contributed to its wide popularity. To best describe this modified version, a quick review of the standard GPL is helpful. The GPL is promoted and maintained by the Free Software Foundation (FSF). The license includes the rights to freely receive source code, modify it and redistribute it. Any software modified from the original distribution can be redistributed if the original software and the modifications are identified. The resulting software is now also covered under the GPL. Software distributed under the GPL has no warranties expressed or implied.
The eCos License Version 2.0 modifies the standard GPL to better address embedded applications. The exception requires that all eCos source files, like the kernel and networking components, for example, be fully covered under the GNU GPL. If these files are redistributed, the GPL free distribution rights are passed to the recipients and source code must be made available. Files derived from eCos source that use eCos templates or macros or contain inline eCos source code are not covered under the GNU GPL, but source code must be made available for any files that are distributed.
Application programs that call or link to eCos components or eCos-derived components, but which have no eCos source content themselves, are exempt from the GNU GPL and source code does not have to be provided. This means that software developers can distribute these applications, can charge for them and restrict them from redistribution as protected intellectual property. This model works well for both developers and their customers. It gives customers all the components needed to develop their own derivatives and applications, but the original developerâ„¢s efforts are protected. Table 3 provides an overview of how software components are covered.
How to Get Started
The complete eCos distribution, with the GNU toolchain and full documentation, can be downloaded from the eCos homepage at ecos.sourceware.org. The tool chain has been compiled and tested on Linux and Windows x86 host platforms. Source for all tools is also available for users who desire to compile on their own.
eCos operating systems that use system resources very efficiently. Still, if performance on the current processor would be inadequate, it is realistic to migrate the system to a more performant processor when required, since all source code is available and the code is written in a portable and modular fashion.,development on ARM style processors, PowerPC processors, MIPS cores, SH3/4 cores, x86 cores. Most applications can be ported easily among these CPU families. In the system consulting phase, we will advice on which CPU platform will yield sufficient performance for the application.
The advantage of eCos is the advantage of open source in general; those using it have complete control over the solution. They can add functionality as they see fit, and problems can be fixed without going back to the software developer.
It also offers more freedom in the branding of wireless devices. There is a trend toward commoditization in the marketplace. Motorola just made its processor technology available to the industry, and companies are more interested in putting together the pieces of technology and creating their own device designs, which is what open source allows.
eCOS tool set is basic. While these tools are very functional, it is important to realize that they
donâ„¢t offer the vast array of features available in many commercial tool packages.
when developing with eCos and the GNU tools, support is available from the software
community through mailing lists where questions are posted and responded to. This type of
fragmented support might not be an acceptable risk in some short commercial development
cycles or critical military cycles. In contrast, many commercial RTOS solutions sell
supplemental technical support, some with guaranteed quick response time, to solve problem
eCos has remained open source and is generally maintained by the engineering community
that uses it. It has grown and matured over the past few years and now supports more than
16 different processors, with more being added regularly. It has been used in many commercial
products including automotive, imaging, automation, video gaming and others. Military and
security applications have included radar array systems, fingerprint and retina identification,
and satellite communications.
eCos is an open source, configurable, portable, and royalty-free embedded real-time operating
system.. eCos is a rich and ubiquitous standard infrastructure for the development of deeply
embedded applications. eCos also provides all the functionality required for general
embedded application support including device drivers, memory management, exception
handling, C, math libraries, etc. In addition to runtime support, the eCos system includes all
the tools necessary to develop embedded applications, including eCos software configuration
and build tools, and GNU based compilers, assemblers, linkers, debuggers,and
EMBEDDED OPERATING SYSTEM
ORIGIN OF Ecos
Â¢ THE CDL LANGUAGE
PROCESSOR AND EVALUATION PLATFORM SUPPORT
eCOS CORE COMPONENTS
THE LICENSING MODEL