-,

National Conference on Embedded in Control,Computing andCommunication, 19 to 21 March 2007

NCECCUBE-07International Institute of Information Technology, Pune India

Embedded Configurable Operating SystemAuthor A :Vandana Mahadik Autor B: Prof. S.H.Patil Author C :Prof ..Gauri Rao

Abstract -This paper focuses on efficient

implementation of 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.

Keywords: embedded system , operating system,

real-time, Redboot

l. Introduction

eCos stands for embedded Configurable OS. It began

with Cygnus. Then Red Hat, Inc., bought Cygnus and

merged it

into Red Hat. Now, eCosCentric 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

Application

Libraries Compatibility ElE](!] IPOSIX II ~ITRON ~Server

IKernel I Networking File

Stack System

Target Independent----------------------------------------Target Specific

1 RedBoot Hardware Abstraction Layer Device DriversROM (HAL)Monitor Interrupts IExceptions IIVectors I IFlash II Serial II Ethernet I

Target Hardware

Figure I. eCOS Architecture

A. Hardware Abstraction Layer (HAL)

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

it's own HAL to support the specific processor

and peripheral set of the target. The HAL is

typically built up with three modules: We have

identified three levels at which the HAL must

operate[2]

The architecture HAL abstracts the basic CPU

architecture and includes things like interrupt

delivery, context switching, CPU startup etcThe

variant HL encapsulates features of the CPU

variant such as caches, MMU and FPU features.

It also deals with any on-chip peripherals such as

memory and

architectural actual

interrupt controllers. For

variations, the

implementation of the variation is often in the

architectural HAL, and the variant HAL simply

provides the correct configuration definitions.

The platform HAL abstracts the properties of the

current platform and includes things like

platform startup, timer devices, 110 register

access and interrupt controllers.

The HAL also provides some important board

specific, teal-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. reo Two types of

interrupts are supported. 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 ISR's. Having both types of interrupt

handling available, lets a user prioritize

interrupts according to system needs and still

guarantee low latency. Virtual vectors support

the ROM based monitor, allowing application

debugging over an Ethernet or serial

communication channel.

The HAL has been implemented according to the

following general principles:

I. The HAL is implemented in C and assembler,

although the eCos kernel is largely implemented

and benefits of choosing eCOS RTOS as

Embedded OS.

II. System requirements

The eCos net distribution is supplied with full

support for configuration of eCos on all host

platforms via both a graphical configuration tool

and a command-line tool. It is intended to be

used in conjunction with GNU development

tools which are available freely on the net. At a

minimum, the gee compiler, gdb debugger and

binutils tools are required to build eCos[2].

A. eCos is distributed under the GPL license with

an exception which permits proprietary

application code to be linked with eCos without

itself being forced to be released under the GPL.

B. Full-featured, flexible, configurable, real time

embedded kernel. The kernel provides thread

scheduling, synchronization, timer, and

communication primitives. It handles hardware

resources such as interrupts, exceptions, memory

and caches.

C. The Hardware Abstraction Layer (HAL) hides

the specific features of each supported CPU and

platform, so that the kernel and other run-time

components can be implemented in a portable

fashion.

D. Support for IlITRON and POSIX Application

Programmer Interfaces (APIs). It also includes a

fully featured, thread-safe ISO standard C library

and math library.

E. Support for a wide variety of devices including

many serial devices, ethernet controllers and

FLASH memories. There is also support for

PCMCIA, USB and PCI interconnects.

F. A fully featured TCP/IP stack implementing IP,

IPv6, ICMP, UDP and TCP over ethernet.

Support for SNMP, HTTP, TFTP and FTP are

also present.

G. The Red Boot ROM monitor is an application that

uses the eCos HAL for portability.

H. Many components include test programs that

validate the components behavior. These can be

used both to check that hardware is functioning

correctly, and as examples of eCos usage.

III. The eCos Architecture

eCos is based on a layered software architecture.

Application portability and reuse of software is

enhanced by abstracting the details of the target

hardware from the application. The dashed line

in Figure I 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 and configured for the

specific target hardware [I]

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 or

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

B. eCos Kernel

The eCos kernel was designed to satisfy four

main objectives: Low interrupt latency, the time

it takes to respond to an interrupt and begin

executing an ISR. Low task switching Latency,

the time it takes from when a thread becomes

available to when actual execution begins. Small

memory footprint, memory resources for both

program and data are kept to a minimum by

allowing all components to configure memory as

needed. Deterministic behavior, throughout all

aspect of execution, the kernels performance

must be predictable and bounded to meet real-

time application requirements. eCos is a full

featured as with a complete set of kernel and

core components including: scheduling and

synchronization, interrupt and exception

handling, counters, clocks, alarms, timers,

POSIX and, J 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 allows

easy configuration and building of the kernel.

C. 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 wil1

need to cover several scheduling policies Two types of

schedulers are available in eCos; a multilevel queue

scheduler and a bitmap 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). 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.[3]

D. Redboot

RedBoot, the Red Hat Embedded Debug and Bootstrap

firmware, is a complete bootstrap environment for

embedded systems.

Functionality - Redboot includes the following basic

functional ity

1. Remote monitoring support: connectivity between

host and target systems over serial and Ethernet

interfaces (gdb stub)

2. Simple command line interface available via serial

or Ethernet

3. Flash memory management download

/update/erase of multiple flash boot images boot

direct from flash

4. Network booting :inc setup and download

(bootp/dhcp,tftboot)

5. Attribute configuration: user control of aspect such

as system time and date (if applicable default flash

image to boot from default failsafe image static IP

address etc.

Configurable and extensible :easily adapted to the6.

r-7.

target environment

Universality: Redboot supports support GNUPro

,ecos and Embedded linux use on the embedded

target as well as other operating systems

D. eCos Thread Synchronization

eCos supports numerous synchronization mechanisms

for communication between threads and for

coordinating the use of shared resources. All of the

following synchronization methods are supported in

eCos: mutexes, counting semaphores, flags, spin locks,

condition variables, and mailboxes. Mutexes or mutual

exclusion objects allow threads to share resources

serially. Each thread in turn locks the resource, uses it,

and then unlocks it for next thread to use. Counting

semaphores use a count associated with each resource

to track its availability. If the resource is not in use the

first thread to request it will be granted the resource. If

however, several threads are waiting on the resource the

highest priority thread will be given access first. Flags

are 32-bit words where each bit in the word can

represent a resource condition. Threads can execute

when a single condition is met or when a specific

combination of conditions are represented by the flag.

eCos supports SMP with spin locks. As a thread needs a

resource it checks a status flag, if the resource is in use

the thread "spins" in a tight loop polling the flag until

the resource is free. Condition variables allow a thread

that is using the resource to signal another thread(s)

when theresource becomes ready. This might be used

when the controlling thread has processed data and is

now signaling a second thread that the data is available

for reading. Mailboxes allow threads to pass messages

between them.

Iv, Operating system comparison

Os requirement RTLin-ux eCOS

1 Real time thread API F P

2 Real time Thread P P

Messaging

3 Supported for N N

distributed clock

synchronization

4 Communication with P F

non real time process

5 Multiple Scheduler F P

Policies

6 C++ standard Library P N

7 Real time P N

Networking

Table 1: Comparison of operating System

Support

Legend :F(full support)

P(partial support)

N(No support)

V. Benefits of choosing RTOS eCOS

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. No runtime licensing fees and

free tools make it attractive to developers with tight

budgets. Excellent real-time performance, low latency

and deterministic behavior make eCos a viable solution

in demanding processing

applications. When the advantages and disadvantages

of using eCos are weighed, it appears that in many

r> embedded applications eCos offers a highly desirable

solution. eCos, like may operating systems and

software products in the past, is in the early stages of

gaining developers acceptance and familiarity. It has

certainly met the goals of the original developers to

produce a small, configurable real-time operating

system that would deliver performance, and be royalty

free. eCos is worth evaluating for your next embedded

application.

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

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

REFERENCES

[I] EMBEDDED SOFTW AREDEYELOPMENT

WITH eCOS ™ Anthony J. Massa

[2. ]http://ecos.sourceware.org

[3] www.ecoscentric.com

[4] http://sources.redhat.com/ecos/.

[5] L. Fernando Friedrich, John Stankovic, Marty Humphrey, Michael

Marley, and John Hask-ins.A survey of configurable component-

based operating systems for embedded applications.

IEEE Micro, 21 (31 ):54-68,2001.

Author A:LecturerBharati Vidyapeeth University CollgePune -41 1043Vandana _mahad ik@yahoo.co.inMob- 9822413385

Author B:H.O.D ofComp& IT

Bharati Vidyapeeth University CollgePune -411043suhas patil@yahoo ..com

Author C:LecturerBharati Vidyapeeth University CollgePune -411043gauravirao@rediffmail.com