-,

National Conference on Embedded in Control,Computing and

Communication, 19to 21 March 2007
NCECCUBE-07
International Institute of Information Technology, Pune India
Embedded Configurable Operating System
Author 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 C ompatibility
E l
E ] ( ! ]
I P OS I X I I ~I TR ON ~
S erver
I
K ernel
I
Networking F ile
S tack S ystem
Target I ndependent
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Target S pecific
1
R edBoot
Hardware Abstraction Layer Device Drivers
R OM
(HAL)
M onitor I nterrupts I E xceptions I I V ectors I IF lash I I S erial I I E thernet 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, M M U 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 RedBoot 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 the 6.
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, spinlocks,
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 aspecific
combination of conditions are represented by the flag.
eCos supports SMP with spinlocks. 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
indemanding 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, J ohn Stankovic, Marty Humphrey, Michael
Marley, and J ohn Hask-ins.A survey of configurable component-
based operating systems for embedded applications.
IEEE Micro, 21(31):54-68,2001.
Author A:
Lecturer
Bharati Vidyapeeth University Collge
Pune -411043
Vandana _mahad ik@yahoo.co.in
Mob- 9822413385
Author B:
H.O.D ofComp& IT
Bharati Vidyapeeth University Collge
Pune -411043
suhas patil@yahoo ..com
Author C:
Lecturer
Bharati Vidyapeeth University Collge
Pune -411043
gauravirao@rediffmail.com