Embedded Systems

1
 Agenda

•Embedded Systems
•Characteristics of Embedded Operating Systems
•eCos
•TinyOS

2 2
 Embedded System
• Embedded system:
A combination of computer hardware and
software, and perhaps additional mechanical or
other parts, designed to perform a dedicated
function.

• In many cases, embedded systems are part of a

larger system or product, as in the case of an
antilock braking system in a car.
3
 Embedded System

• Embedded systems far outnumber general

purpose computer systems, encompassing a
broad range of applications (next Table).

4
Examples

5
Examples

6
 Embedded System

• These systems have widely varying

requirements and constraints, such as the
following:
• Small to large systems, implying very different
cost constraints, thus different needs for
optimization and reuse.

7
 Embedded System
•Relaxed to very strict requirements and
combinations of different quality requirements.
for example, with respect to safety, reliability,
real-time, flexibility, and legislation
• Short to long life times
• Different environmental conditions in terms of,
for example, radiation, vibrations, and
humidity

8
 Embedded System
• Different application characteristics resulting in
static versus dynamic loads, slow to fast speed,
compute versus interface intensive tasks, and/or
combinations thereof.

• Different models of computation ranging from

discrete-event systems to those involving
continuous time dynamics (usually referred to as
hybrid systems)
9
 Embedded System
• Due to embedded systems strongly coupled to their
environment.
• This can give rise to real-time constraints imposed
by the need to interact with the environment.
• Constraints, such as required speeds of motion,
required precision of measurement, and required
time durations, dictate the timing of software
operations.
• If multiple activities must be managed
simultaneously, this imposes more complex real-
time constraints.
10
Embedded System Organization

11
In addition to the processor and memory, there
are a number of elements that differ from the
typical desktop or laptop computer.

• There may be a variety of interfaces that

enable the system to measure, manipulate,
and otherwise interact with the external
environment.
• The human interface may be as simple as
a flashing light or as complicated as real-
12
time robotic vision.
•The diagnostic port may be used for
diagnosing the system that is being
controlled.
• Special-purpose field programmable
(FPGA), application specific (ASIC), or
even non digital hardware may be used to
increase performance or safety.
• Software often has a fixed function and is
specific to the application.
13
14
Characteristics of Embedded Operating
System
1. Real-time operation:
• In many embedded systems, the correctness of a
computation depends, in part, on the time at which
it is delivered.
• Often, real-time constraints are dictated by
external I/O and control stability requirements.

15
2. Reactive operation:
• Embedded software may execute in response to
external events.

• If these events do not occur periodically or at

predictable intervals, the embedded software may
need to take into account worst-case conditions
and set priorities for execution of routines.

16
3. Configurability:
• Because of the large variety of embedded systems,
there is a large variation in the requirements, both
qualitative and quantitative, for embedded OS
functionality.

4. I/O device flexibility:

• There is virtually no device that needs to be
supported by all versions of the OS, and the range
of I/O devices is large.

17
5. Streamlined protection mechanisms:
• Embedded systems are typically designed for a limited,
well-defined functionality.
• Untested programs are rarely added to the software.
• After the software has been configured and tested, it
can be assumed to be reliable.
• Thus, apart from security measures, embedded systems
have limited protection mechanisms.
6. Direct use of interrupts:
• General-purpose operating systems typically do not
permit any user process to use interrupts directly.

18
19
• There are two general approaches
to developing an embedded OS.

• The first approach is to take an existing OS

and adapt it for the embedded application.

• The other approach is to design and

implement an OS intended solely for
embedded use.
20
Adapting an Existing OS

• Examples include Windows, Linux, BSD

– Generally slower than special purpose OS
– Advantage is familiar interface
• Need to add
– real-time capability
– Streamlining operation
– Add other specialized and necessary functionality
for the given device

21
Purpose-Built Embedded OS
• Typical characteristics include:
– fast and lightweight process or thread switch
– Scheduling policy is real time and dispatcher module
is part of scheduler
– Small size
– Responds to external interrupts quickly
– Minimizes intervals during which interrupts are
disabled
• To deal with timing constraints, the kernel:
– Provides bounded execution time for primitives
– Maintains a real-time clock
– Provides for special alarms and timeouts
– Supports real-time queuing disciplines
– Provides primitives to delay processing by a fixed
amount of time and to suspend/resume execution
 Agenda

•Embedded Systems
•Characteristics of Embedded Operating Systems
•eCos
•TinyOS

24 24
25
 eCos:
Embedded Configurable OS
• Open source,
• Real-time OS
• Most widely used embedded OS
• Targeted at high-performance small embedded
systems.
• An embedded form of Linux or other
commercial OS would not provide the
streamlined software required. ________
eCos
Configuration Tool

The top level of the eCos

configuration tool as seen by
the tool user.

Each of the items on the list in

the left-hand window can be
selected or deselected
eCos Configuration Tool
 Loading an eCos Configuration
This figure shows a typical
example of the overall process
of creating the binary image to
execute in the embedded
system.

This process is run on a source

system, e.g. Windows or Linux
platform, and the executable
image is destined to execute on
a target embedded system,
such as a sensor in an
industrial environment.
At the highest software level is the application
source code for the particular embedded
application.
• This code is independent of eCos but
makes use of application programming
interfaces (API) to sit on top of the eCos
software.
• There may be only one version of the
application source code, or there may be
variations for different versions of the
target embedded platform.

In this example, the GNU make utility is used

to selectively determine which pieces of a
program need to be compiled or recompiled (in
the case of a modified version of the source
code) and issues the commands to recompile
them.
 eCos Layered Structure
A key design
requirement for eCos is
portability to different
architectures and
platforms with minimal
effort.

To met this
requirement, eCos
consists of a layered set
of components
 Hardware Abstraction Layer

• Presents consistent API

to upper layers
• Different for each
hardware platform
 HAL Modules
• The HAL is implemented as three separate
modules:
• Architecture:
• Defines the processor family type.
• This module contains the code necessary for
processor startup, interrupt delivery, context
switching, and other functionality specific to the
instruction set architecture of that processor family.
 HAL Modules
• Variant:
• Supports the features of the specific processor in
the family.
• An example of a supported feature is an on-chip
module such as a memory management unit
(MMU).
 HAL Modules
• Platform:
• Extends the HAL support to tightly coupled
peripherals like interrupt controllers and timer
devices.
• This module defines the platform or board that
includes the selected processor architecture and
variant.
• It includes code for startup, chip selection
configuration, interrupt controllers, and timer
devices.
 eCos Kernel Design
• 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.
 eCos Kernel Design
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 behaviour:
• Throughout all aspect of execution, the kernels
performance must be predictable and bounded to
meet real-time application requirements.
 Not in eCos Kernel
• Some functionality that is typically included
in the kernel of an OS is not included in the
eCos kernel.
• E.g. memory allocation is handled by a separate
package.
• Similarly, each device driver is a separate
package.
 eCos I/O System
• The eCos I/O system is a framework for
supporting device drivers.

• A variety of drivers for a variety of platforms are

provided in the eCos configuration package.
• These include drivers for serial devices, Ethernet,
flash memory interfaces, and various I/O
interconnects such as PCI (peripheral component
interconnect) and USB (universal serial bus).
• In addition, users can develop their own device
drivers.
 eCos I/O System
• The principal objective for the I/O system is
efficiency, with no unnecessary software
layering or extraneous functionality.

• Device drivers provide the necessary functions

for input, output, buffering, and device control.

• Device drivers and other higher-layer software

may be implemented directly on the HAL if this
is appropriate.
 eCos Scheduler
The eCos kernel can be configured to provide one
of two scheduler designs:
• Bitmap scheduler
– Efficient for small number of threads active
– Each thread has different priority
• Multilevel queue scheduler
– Appropriate when number of threads is dynamic
– If it is desirable to have multiple threads at the same
priority level
– is also needed if Time slicing is desired.
Bitmap Scheduler Priority Levels
•A bitmap scheduler supports multiple priority levels, but
only one thread can exist at each priority level at any
given time.
•Scheduling decisions are quite simple with this scheduler.
•When a blocked thread become ready to run, it may
preempt a thread of lower priority.

•When a running thread suspends, the ready thread with the

highest priority is dispatched.
•A thread can be suspended because it is blocked on a
synchronization primitive, because it is interrupted, or
because it relinquishes control.
Bitmap Scheduler Priority Levels
The bitmap scheduler is configured with 8, 16, or 32
priority levels.
• A simple bitmap is kept of the threads that are ready to
execute.
• The scheduler need only determine the position of
the most significant one bit in the bitmap to make a
scheduling decision.
Multilevel Queue Scheduler Priorities
The multilevel queue scheduler supports up to 32 priority levels.
• The multilevel queue scheduler allows for multiple active
threads at each priority level, limited only by system resources.

This Figure illustrates the nature of the multilevel queue scheduler.

• A data structure represents the number of ready threads at
each priority level.
• When a blocked thread become ready to run, it may preempt a
thread of lower priority.

As with the bitmap scheduler, a running thread may be blocked on

a synchronization primitive, because it is interrupted, or because it
relinquishes control.
When a thread is blocked, the scheduler must first determine if one
or more threads at the same priority level as the blocked thread is
ready.
• If so, the scheduler chooses the one at the front of the queue.
• Otherwise, the scheduler looks for the next highest priority
level with one or more ready threads and dispatches one of
these threads.

In addition, the multilevel queue scheduler can be configured for

time slicing.

If a thread is running and there is one or more ready threads at the

same priority level, the scheduler will suspend the running thread
after one time slice and choose the next thread in the queue at that
priority level.
• This is a round-robin policy within one priority level.
• Not all applications require time slicing.
 eCos Thread Synchronization
• The eCos kernel can be configured to include one or
more of six different thread synchronization
mechanisms.
• Classic mechanisms
– Mutexes
– Semaphores
– Condition variables
• synchronization/communication mechanisms
– Event flags
– Mailboxes
• SMP support(symmetric multiprocessing)
– Spinlocks
Mutex is used to enforce mutually exclusive access to a resource,
allowing only one thread at a time to gain access.

The mutex has only two states:

• locked and
• unlocked.

Similar to a binary semaphore:

• When a mutex is locked by one thread, any other thread
attempting to lock the mutex is blocked;
• when the mutex is unlocked, then one of the threads blocked on
this mutex is unblocked and allowed to lock the mutex and gain
access to the resource.

49
The mutex differs from a binary semaphore in two respects.
• the thread that locks the mutex must be the one to unlock it.
•But it is possible for one thread to lock a binary semaphore and
for another to unlock it.
• The other difference is that a mutex provides protection against
priority inversion, whereas a semaphore does not.

The eCos kernel can be configured to support either a priority

inheritance protocol or a priority ceiling protocol.

50
Mutexes and Condition Variables
A condition variable is used to block a thread
until a particular condition is true.

Condition variables are used with mutexes to

allow multiple thread to access shared data.

In eCos, condition variables are typically used in

conjunction with mutexes to implement long-term
waits for some condition to become true.
 TinyOS
• 400 bytes of code
• Not a real-time OS
– No kernel
– There are no processes;
– OS doesn’t have a memory allocation system
– interrupt and exception handling is dependent on
the peripheral; and
– Nonblocking, so there are few explicit
synchronization primitives. ___________
TinyOS takes the process of streamlining to a much further point,
resulting in a very minimal OS for embedded systems.

The core OS requires 400 bytes of code and data memory,

combined.

TinyOS represents a significant departure from other embedded

operating systems.
• TinyOS is not a real-time OS.
• The reason for this is the expected workload, which is in the
context of a wireless sensor network.
Because of power consumption, these devices are off most of the
time.
• Applications tend to be simple, with processor contention not
much of an issue.
53
In TinyOS, there is no kernel as there is no memory protection and it
is a component-based OS;
• There are no processes;
• The OS itself does not have a memory allocation system
• interrupt and exception handling are dependent on the
peripheral; and
• it is completely nonblocking, so there are few explicit
synchronization primitives.

54
Wireless Sensor Network Topology
TinyOS was developed primarily for use with
networks of small wireless sensors.

A number of trends have enabled the development

of extremely compact, low-power sensors.

Low cost, small size, low-power-consuming

wireless sensors make can be used in a host of
application.

This figure shows a typical configuration.

56
 TinyOS Goals
• With the tiny, distributed sensor application in
mind, the following goals were set for TinyOS:
– Allow high concurrency
– Operate with limited resources
– Adapt to hardware evolution
– Support a wide range of applications
– Support a diverse set of platforms
– Be robust
 TinyOS Components
• Embedded software systems built with TinyOS
consist of a set of modules – called components
• Such as:
– Single-hop networking
– Ad-hoc routing
– Power management
– Timers
– Nonvolatile storage control
 TinyOS Scheduler
• Operates across all components
• Only one task executes at one time
• Simple FIFO queue
• Scheduler is power aware
– Puts processor to sleep when no task in
queue
 TinyOS
Resource Interface
• TinyOS provides a simple but powerful set of
conventions for dealing with resources.
– Dedicated
– Virtualized
– Shared
 Sheet
Review Questions page 604-605

1. What is an embedded system?

2. What are some typical requirements or constraints on
embedded systems?
3. What is an embedded OS?
4. What are some of the key characteristics of an embedded
OS?
5. Explain the relative advantages and disadvantages of an
embedded OS based on an existing commercial OS
compared to a purpose-built embedded OS.
6. What are the principal objectives that guided the design of
the eCos kernel?
7. In eCos, what is the difference between an interrupt service
routine and a deferred service routine?
8. What concurrency mechanisms are available in eCos?
9. What is the target application for TinyOS?
10. What are the design goals for TinyOS?
11. What is a TinyOS component?
12. What software comprises the TinyOS operating system?
13. What is the default scheduling discipline for TinyOS?
Recommended Web sites:
• eCos:
Downloadable software,
information, and links on eCos

• TinyOS Community Forum:

Downloadable software,
information, and links on TinyOS

63