eCos

1
eCos

• Presented by ???, ???
• ?????
• 2002-10-21

2
Outline

• What is eCOS
• Supported processors
• eCos Features
• eCos Kernel Details
• Main advantages of eCos
• Compare with other RTOS
• Installation
• Programming
• Commercial products that use eCos
• Where to download

3
What is eCos ?(1)

• eCos (embedded Configurable operating system) is
  an open-source, configurable, portable real-time
  operating system, developped by RedHat.
• It is designed primarily for deeply embedded
  systems eCos is targeted at high-volume
  applications in consumer electronics,
  telecommunications, automotive, and other deeply
  embedded applications.

4
What is eCos ?(2)

• The main goal behind eCos is to provide embedded
  developers with a common software infrastructure
  for delivering a diverse range of embedded
  products.
• It also plans to let developers focus on the
  applications, rather than the real-time OS.

5
What is eCos ?(3)

• The current version of eCos is 1.3.1. The
  operating system is quite small in size, and at
  its smallest, it occupies 3K of ROM and 1K of RAM
• for a kernel that includes a scheduler, memory
  management, RTC support, several threads and
  interrupt handlers.

6
Supported processors

• Advanced RISC Machines ARM7
• Fujitsu SPARClite
• Matsushita MN10300
• Motorola PowerPC
• Toshiba TX39
• Hitachi SH3
• NEC VR4300
• MB8683x series
• Intel strong ARM

7
eCos Features(1)

• Modular design for source-level
• configuration
• Rich set of synchronization primitives
• Choice of scheduling algorithms
• Choice of memory-allocation strategies
• Timers and counters

8
eCos Features(2)

• Support for interrupts and DSRs
• Exception handling
• ISO C library
• Math library
• Host debug and communications support
• Open APIs

9
eCos Kernel Details
10
The Hardware Abstraction Layer(HAL)(1)

• eCos includes a Hardware Abstraction Layer ( HAL
  ) that 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
• There are three levels at which the HAL operates

11
The Hardware Abstraction Layer(HAL)(2)

• Architecture HAL abstracts basic CPU
• architecture, including
• interrupt delivery
• context switching
• CPU startup etc.
• Platform HAL abstracts current platform,
  including
• platform startup
• timer devices
• I/O register access
• interrupt controllers

12
The Hardware Abstraction Layer(HAL)(3)

• Implementation HAL abstracts properties that lie
  between the above
• architecture variants
• on-chip device
• In the current HAL structure, there are separate
• directory trees for the architectural and
  platform
• HALs. The implementation HAL is currently
• supported in one or other of these by means of
• conditional compilation depending on how generic
  a
• Particular feature is expected to be.

13
Kernel(Memory allocation)

• The variable-block memory allocator can perform
  coalescing of memory whenever the application
  code releases memory back to the pool. This
  coalescing reduces the possibility of memory
  fragmentation problems, but involves extra code
  and processor cycles

14
Source-level debugging support

• This option enables some extra kernel code which
  is needed to support multi-threaded source level
  debugging

15
Kernel (Kernel Instrumentation)(1)

• eCos applications and components can be debugged
  in traditional ways, with printing statements and
  debugger single-stepping, but there are
  situations in which these techniques cannot be
  used.
• ex
• when a program is getting data at a high rate
  from a real-time source, and cannot be slowed
  down or interrupted.

16
Kernel (Kernel Instrumentation)(2)

• eCos's infrastructure module provides a tracing
  formalism, allowing the kernel's tracing macros
  to be configured in many useful ways.
• eCos's kernel provides instrumentation buffers
  which also collect specific (configurable) data
  about the system's history and performance.
• You can monitor a class of several types of
  events, or you can just look at individual events.

17
Kernel (Kernel Instrumentation)(3)

• 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

18
Kernel (Kernel Instrumentation)(4)

• Examples of fine-grained scheduler
• event types are
• scheduler lock
• scheduler unlock
• rescheduling
• time slicing

19
Kernel(Interrupt)(1)

• eCos uses a split interrupt handling scheme. In
  this scheme, interrupt handling is separated into
  two parts.
• Interrupt Service Routine or ISR
• Deferred Service Routine or DSR

20
Kernel(Interrupt)(2)

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

21
Kernel(Exception)

• An exception is a synchronous event caused by the
  execution of a thread.
• These include both the machine exceptions raised
  by hardware (such as divide-by-zero, memory fault
  and illegal instruction) and by software (such as
  deadline overrun).
• The simplest, and most flexible mechanism for
  exception handling is to call a function.

22
Kernel(Scheduler)(1)

• In this release two schedulers are provided
• a bitmap scheduler
• a multi-level queue scheduler
• At present the system will only support a single
  scheduler at any one time.

23
Kernel(Scheduler)(2)

• sched subdirectory sched/bitmap.cxx
• This contains the bitmap scheduler
  implementation. It represents each runnable
  thread with a bit in a bitmap. Each thread must
  have a unique priority and there is a strict
  upper limit on the number of threads allowed.

24
Kernel(Scheduler)(3)

• sched subdirectory sched/mlqueue.cxx
• This contains the multi-level queue scheduler
  implementation. It implements a number of thread
  priorities and is capable of timeslicing between
  threads at the same priority. This scheduler can
  also support priority inheritance.

25
Kernel(Counters Clocks)(1)

• Counter
• The counter objects provided by the kernel
  provide an abstraction of the clock facility that
  is generally provided.
• There are two different implementations of the
  counter objects. The first is using a single
  linked list. The other is using a table of lists,
  with the size of the table being a separate
  configurable option.

26
Kernel(Counters Clocks)(2)

• Clock
• The most frequently used clock is the real-time
  clock which serves two special purposes.
• First, it is necessary to support clock and alarm
  related functions such as cyg_thread_delay() .
• Second, it is needed to implement timeslicing in
  the mlqueue schedulers

27
Kernel(Synchronization primitives)

• To allow threads to cooperate and compete for
  resources, it is necessary to provide mechanisms
  for synchronization and communication.
• mutex/condition variables
• semaphores

28
Main advantages of eCos(1)

• 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

29
Main advantages of eCos(2)

• 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).

30
Main advantages of eCos(3)

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

31
Compare with other RTOS
32
(No Transcript)
33
Installation

• Installation (Setting up the eCos environment )
• Using the Configuration Tool on Windows / LINUX
• Windows

34
Component Repository(1)

• The eCos component repository contains
  directories for all the packages that are shipped
  with eCos or provided by third parties.
• The component repository should not be modified
  as part of application development.

35
Component Repository(2)

• Purpose
• The component respository is the
• master copy of source code for all
• system and third party components. It
• also contains some files needed to
• administer and build the system, such
• as ecosadmin.tcl

36
Programming

• Build Tree
• Install Tree
• Purpose
• The install tree is where the custom-built
  libtarget.a library, which contains the eCos
  kernel and other components, is located. The
  install tree is also the location for all the
  header files that are part of a published
  interface for their component.

37
Commercial products that use eCos

• Iomega HipZip players
• Delphi telematics products.
• Ascom Internet access devices

38
Where to download

• http//sources.redhat.com/ecos/
• for Linux
• for windows