Embedded-Configurable Operating System

INTRODUCTION

eCos stands for embedded Configurable OS. It began with Cygnus. Then Red Hat, Inc., bought Cygnus and merged it into Red Hat. Now, eCos Centric Ltd. (UK) manages -eCos. It is royalty free, open source RTOS for embedded systems eCos is designed to be portable to a wide range of target architectures and target platforms including 16, 32, and 64 bit architectures, MPUs, MCUs and DSPs. The eCos kernel, libraries and runtime components are layered on the Hardware Abstraction Layer (HAL), and thus will run on any target once the HAL and relevant device drivers have been ported to the target's processor architecture and board. Currently eCos supports ten different target architectures (ARM, Hitachi H8300, Intel x86, MIPS, Matsushita AM3x, Motorola 68k, PowerPC, SuperH, SPARC and NEC V8xx variants of these architectures. This paper describes System requirement of eCOS & eCOS architecture. And it also compares eCos operating system to Linux RTOS

What Is Ecos:-

eCOS(embedded configurable operating system) in real time operating system and embedded hardware systems. eCOS is an open source real time embedded operating system ported to variety of architectures including embedded applications. The highly configurable nature of eCOS allows the operating system to be customized to precise application requirements delivering the best possible run time performance. eCOS uses redboot for bootstrapping. Redboot is a complete boot strap environment for embedded systems based

on the eCOS HAL (hardware abstraction layer). eCOS kernel does not need to run on the target board in order to execute the application. One of its goal is efficiency from memory point of view. That is why it tries to solve the trade between package, granularity and package cost with multiple configuration option.

SCOPE:-

eCos kernel currently does not have wireless extensions built into it and because of that there are no wireless packages available to it. This is an area open to research and development.

THE ECOS CONFIGURATION METHOD:

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, both in terms of their functionality and implementation, whereas traditionally the operating system has constrained the application's own implementation. Essentially, this enables eCos developers to create their own application-specific operating system and makes eCos suitable for a wide range of embedded uses. Configuration also ensures that the resource

footprint of eCos is minimized as all unnecessary functionality and features are removed. The configuration system also presents eCos as a component architecture. This provides a standardized mechanism for component suppliers to extend the functionality of eCos and allows applications to be built from a wide set of optional configurable run-time components. eCos is designed to be portable to a wide range of target architectures and target platforms including 16, 32, and 64 bit architectures, The philosophy of the eCos component control implementation is to reduce the size for systems that have resource limitations, even to the detriment of systems that do not have strict resource constraints. With this design philosophy in mind, minimal systems do not suffer from additional code necessary to support advanced features only used in more complex systems. One method to control software components is at run time. In this method, no up-front Configuration of the component is done. Second method Compile-time control gives the developer control of the component

behavior at the earliest stage, allowing the implementation of the component itself to be built for the specific application for which it is intended.

ARCHITECTURE OVERVIEW:

eCos is designed as a configurable component architecture consisting of several key software components such as the kernel and the HAL. The fundamental goal is to allow construction of a complete embedded system from these reusable software components. This allows you to select different configuration options within the software component, or removes unused components altogether, in

order to create a system that specifically matches the requirements of your application. By creating an eCos image that closely matches your system

requirements, the size of the software is compact, only including used components. The software application is also faster because extra code is not executed. Figure shows an example of how the core building blocks, and some of the optional Components available in the eCos system, which can be layered together to incorporate the functionality needed for a specific application. Since configuration is a key aspect of the eCos system, tools are provided to manage the complexity of the different configuration options. These tools also allow components to be added or removed as needed. The tools build the main end product of an eCos configuration, which is a library that can be linked with application code.

ECOS CORE COMPONENTS:

eCos delivers these standard components with the real-time kernel as the central core. The core components are: 

• Hardware Abstraction Layer(HAL):- providing 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.

THE HARDWARE ABSTRACTION LAYER:

The HAL isolates architectural-dependent features and presents them in a general form to allow portability of other infrastructure components. Basically, the HAL is a software layer, with generalized Application Programming Interfaces (API), which encapsulates the specific hardware operations needed to complete the desired function. The HAL consists of three separate modules

Architecture

Platform

Variant

The first HAL sub module defines the architecture. Each processor family supported by eCos is considered 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 the associated processor family. 

A second HAL sub module defines the variant. A variant is a specific processor within the processor family described by the architecture. An example of a feature that might be included at this level is support for an on-chip peripheral such as a Memory Management Unit (MMU).

The third HAL sub module defines the platform. A platform is a specific piece of

hardware that includes the selected processor architecture and, possibly, a variant. This module typically includes code for platform startup, chip select configuration, interrupt controllers, and timer devices.

HAL DIRECTORY STRUCTURE: 

All HAL packages included in the repository are found under the hal subdirectory. At this point, the architectures included in the directory structure are not important; however, it is important to get an overview of where files containing certain HAL functionality are located within the repository. It is also important to understand that not all HAL architectures follow the same directory structure.

As new platform and architecture ports are developed, the package contents are inserted in the appropriate place in the HAL directory structure. Since new ports are made available at various times, the directory structure can change often to accommodate new additions. 

First is the subdirectory common, located under the main HAL directory. This subdirectory contains the package configuration files general to all HAL architectures, including files for general interrupt configuration, virtual vector layout, and HAL debugging control. Function wrappers are contained in this subdirectory to create the commonality found

among all HAL implementations.

Another subdirectory to notice is arch, located under every architecture tree. The arch subdirectory contains files for generic support for the processor architecture.

Functionality included in this generic support consists of exception vector initialization, ROM and RAM startup configuration, common interrupt and exception handling, thread context switch handling, a generic linker script file, and common debugging functions. Some HAL architectures include a subdirectory to contain the variant code. This subdirectory is named var. Last is the sim subdirectory, which can be found under the architecture trees that support processor simulators.

THE KERNEL

The kernel is the core to the eCos system. The kernel provides the standard functionality expected in an RTOS, such as interrupt and exception handling, scheduling, threads, and synchronization. These standard functional components that comprise the kernel are fully configurable under the eCos system to meet your specific needs. A few criteria were the focus of the eCos kernel development to allow it to meet its

real-time goals:

Interrupt latency—the time taken to respond to an interrupt and begin execution of an ISR is kept low and deterministic.

Dispatch latency—the time taken from when a thread becomes ready to run to the point it begins execution is kept low and deterministic.

Memory footprint—the memory resources required for both code and data is kept minimal and deterministic for a given system configuration. Dynamic memory allocation is configurable in the core components to ensure that the embedded system does not run out of memory.

 Deterministic kernel primitives—the execution of kernel operations is predictable, allowing an embedded system to meet real-time requirements.

Examples of events that can be monitored are:

scheduler events

thread operations

interrupts

mutex operations

binary semaphore operations

counting semaphore operations

clock ticks and interrupts

ECOS SCHEDULERS:-

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 interrupt affect thread execution no single scheduler can cover all possible system configurations for different purposes we will

need to cover several scheduling policies Two types of schedulers are available in eCos; 

a multilevel queue scheduler and a bitmap scheduler. 

multilevel queue scheduler

The multilevel queue scheduler allows threads to be assigned with a priority

level from 0 to 31, with 0 being the highest priority and 31 being the lowest. At each level multiple threads can execute and preemption between levels is supported, allowing higher level threads to execute while lower level threads are halted. Time slicing is also supported within a priority level and across priority levels, allowing each thread a predetermined execution time before relinquishing resource to the next thread. The multilevel queue scheduler supports Symmetric Multi-Processing(SMP).

Bitmap Scheduler

The bitmap scheduler is a simpler, and more efficient, scheduler. It also allows 32 priority levels similar to the multilevel queue scheduler, but only one thread is allowed to execute on each level. Preemption is supported with this scheduler, but time slicing between threads is not, and is not needed because each level only allows a single thread. Again as with the choice of kernel or kernel-less functionality, eCos allows the balance between features and

efficiency of the scheduler to be configured by the user

to best match the requirements of the application.

PROCESSOR AND EVALUATION PLATFORM SUPPORT:-

Currently eCos supports ten different target architectures (ARM, Hitachi H8300, Intel x86, MIPS, Matsushita AM3x, Motorola 68k, PowerPC, SuperH, SPARC and NEC V8xx) 

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.

The main processor architectures supported include:

ARM

Fujitsu FR-V

Hitachi H8/300

Intel x86

Matsushita AM3x

MIPS

NEC V8xx

PowerPC

Samsung CalmRISC16/32

SPARC

SPARClite

SuperH

MAIN ADVANTAGES OF ECOS:-

Configurability:

It can be configured in great detail at compile time, which avoids the need to add

unwanted code to the library to be linked with the application code. Configuration is also fine-grained; so that very small details of eCos’ behavior can be tuned developers are given the ability to create their own application-specific operating

system

Portability

eCos is designed to be portable to a wide range of target architectures and platforms, including 16, 32 and 64 bit architectures, microcontrollers and DSPs

The reason that enables eCos to be highly portable is the implemented Hardware

Abstraction Layer (HAL). The eCos kernel, libraries and runtime components are layered on the HAL and therefore will run on any target once the HAL and the relevant device drivers have been ported to the specific architecture.

CONCLUSION:-

 eCos is an excellent hard real-time operating system that can be customized to suit very specific application needs. eCos offers some distinct advantages to developers of embedded applications. It's open source distribution and extensive configuration flexibility offers developers an RTOS that can be tailored to closely match the requirements of an application and the resources of the processing hardware.