Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Introductory

Designing Small-Scale Embedded Systems
with µITRON Kernel
1st
1st Apr.
Apr. 1998
1998
Hiroaki
Hiroaki Takada
Takadahiro@ertl.ics.tut.ac.jp
hiro@ertl.ics.tut.ac.jp
http://www.ertl.ics.tut.ac.jp/~hiro/
http://www.ertl.ics.tut.ac.jp/~hiro/

Toyohashi
Toyohashi Univ.
Univ. ofof Technology
Technology
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Background
Application fields of embedded systems continue toexpand to small-scale systems.
Most embedded systems are real-time systems, inthat the systems have some timing constraints.
Software for (even small-scale) embedded systems
becomes larger and more complex.
How to raise software productivity?
high-level programming language
real-time operating system (RTOS)
advanced development environments and tools
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Consumer Applications
TVs, VCRs, digital cameras, settop boxes, audio components,
air-conditioners, microwave ovens
Office Applications / PC Peripheral
printers, scanners, disk drives, copiers, FAX
Communications
answering machines, ISDN telephones, cellular phones,
modems, terminal adapters
Other Applications
automobiles (engine management, etc.), game gear,
vending machines, electronic musical instruments, (somecomponents for) factory automation
Typical Applications of Small-Scale Embedded Systems
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Contents of this Class
What is a real-time kernel? What is the advantage?
application status of real-time kernels to small-scale
embedded systems
introducing some real-time kernels for small-scale
embedded systemsµITRONOSEK/VDX OSµC/OS
basic approaches and techniques in designing asmall-scale embedded system with a real-timekernels

Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Small-Scale Embedded Systems
Following features are common to many (but not all)small-scale embedded systems.

produced in great number and in cheap
The producing cost is a larger issue than thedevelopment cost.
short development life-cycle
short time-to-market
The software is seldom modified once the productis shipped.
limited hardware resources
small memory (esp. RAM) capacity
required to fit in a single-chip MCU
high reliability (for some systems)
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

What is a Real-Time Kernel?
real-time kernel (or real-time operating system kernel)
also called as a real-time monitor
or a real-time executiveis the basic run-time software on which a realtime system is realized.
is the core module of a real-time operating system.
manages only the essential hardware resources ofa computer system (i.e. processor and memory.
There are only a few common I/O devices to besupported in case of small-scale embedded systems.

Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

functions supported by a real-time kernel
multitasking
priority-based preemptive schedulinginter-task synchronization and communication
semaphore, eventflag, mailbox, ...
basic memory management
interrupt handling
timer handling, time management
no external device handlings
Real-time kernels were difficult to apply to small-scale
embedded systems
because of the overhead of real-time kernels inexecution time
memory consumption
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

What is Multitasking?
task
A task is a unit of concurrent processing.
The programs within a task are executed
sequentially, while programs of different tasks
are executed concurrently.
task dispatching (or task switching)changing the executed task
The context of the old task is saved, and that of
the new task is restored.
schedulingselecting the executed task among the executableones
scheduling algorithm
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Priority-Based Preemptive Schedulingpriority-based scheduling
Each task is assigned a priority.
The task having the highest priority is selected
as the executed task.
Lower priority tasks are never executed until thehighest priority task is blocked (or suspended).
preemptive scheduling
If a higher priority task is started while a lower
priority task is being executed, the execution of
the lower priority task is suspended and thehigher priority task starts execution.
preemption
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Why You Need Multitasking?
modular design
relatively unimportant in case of small-scale systems

Modular design is effective for raising themaintainability and reliability of the system.
Different groups of I/O devices should be handledwith different tasks, for example.
real-time property
major concern in this class
The development and maintenance of a systemwith real-time constraints can be facilitated.
real-time constraints... typically represented with deadlines
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

eg.) task X ... short execution time & short deadline
task Y ... long execution time & long deadline
higher priority

task X
preemptiontask Yeasily realizable with a real-time kernel
without a real-time kernel .....
Task Y must repeatedly check if task X should
be executed.
degraded response; overhead for the checking
When task Y is modified, the check points
must also be reexamined.
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Application Status of Real-Time Kernels
100%
90%

ITRON-spec. OS

80%

CTRON-spec. OS

70%other commercial OS

60%

other in-house OS

50%

OS not used

40%
30%
20%
10%
0%

4bit

8bit

16bit

32bit

OS Usage vs. CPU Size
(TRON Association Survey, 1997-1998, Japan)
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

100%
90%

ITRON-spec. OS

80%

CTRON-spec. OS

70%other commercial OS

60%

other in-house OS

50%

OS not used

40%
30%
20%
10%
0%

< 64KB≥ 64KB< 256KB≥ 256KB
< 1MB

≥ 1MB

OS Usage vs. ROM Size
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%

OS Usage vs. Application Fields
Hiroaki Takada

ESC Spring '98

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Application Examples of Real-Time Kernels
FAX machine
CD player
MCU Type
8-bit
16-bit
2 KB
RAM size
512 Bytes
32 KB
ROM size
32 KB
Used Memory RAM
1346 Bytes
384 Bytes
ROM28.8 KB
17.8 KB
96
No. of Tasks
6
No. of Interrupt Handlers 6
7
No. of Used System Calls 12
Kernel Size RAM (ratio)
250 Bytes (19%) 146 Bytes** (38%)
ROM (ratio)
2.5 KB (8.7%)
2.3 KB (13%)
Application* Both applications adopt µITRON-specification real-time kernels.
** A stack saving technique is applied.

Real-time kernels are applicable to such small
embedded systems.
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Requirements on a Real-Time Kernel
General requirements(a) compactness(b) low overhead(c) dependability(d) predictability

esp. for Small-Scale Embedded Systems(a) scalability and adaptability
The real-time kernel code should be tunable
to a specific application.
(b) exploiting static information
Static information should be placed on ROM
area to save memory (RAM) consumption.
(c) low cost (of the real-time kernel itself)
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Introduction to the µITRON Specifications
ITRON Project
standardizing real-time operating systems andrelated specifications for embedded systems
A series of the ITRON real-time kernel specifications
have been published and are widely used.
de-facto industry standard in JapanµITRON specifications are designed for small-scale
embedded systems with limited hardware resources.
recent version: µITRON3.0
under investigations: µITRON4.0
The ITRON specifications are open in that anyone isfree to implement and sell products based on them.
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Design Principles of the ITRON Specifications
design concept: loose standardization
maximum performance cannot be obtained withstrict standardization
design principles
allow for adaptation to hardware; avoiding
excessive hardware virtualization
allow for adaptation to the applicationemphasize software engineer training easeorganize specification series and divide into levels
provide a wealth of functions

Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Functions
Functions Supported
Supported inin µITRON3.0µITRON3.0 Specification
Specification
task managementtask-dependent synchronization
basic synchronization and communication( semaphore, eventflag, mailbox )extended synchronization and communication( message buffer, rendezvous )interrupt management
memory pool management
time management
system management
The specification can be downloaded from the ITRON Home Page.
http://tron.um.u-tokyo.ac.jp/TRON/ITRON
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Implementation Status! We do not know how many real-time kernels are
implemented based on the ITRON specifications.
about 45 registered implementations for about 35
processors
several non-registered commercial implementations
implemented for almost all major processors
8-bit to 32-bit MCUs/MPUs
many in-house implementations
some freely distributed implementations

Application Statuswidely used for various application areas
most popular RTOS specification in Japan
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Implementation Examples
Two µITRON-specification kernels for an MCU
OS typeNo. of system calls
Scheduling
System call interface
Exception management

Single-chip
Task part: 29
Non-task part: 15
Fixed priority
1 task per priority
Subroutine call
None

General-purpose
Task part: 36
Non-task part: 27
Variable priority

Software interrupt
Exit exception,
CPU exception
Max. 15
Wakeup request countMax. 255
Max. 255
Semaphore countMax. 65,535
32-bitSystem timer
48-bit
0.6 – 4.4 KB
Program size
1.9 – 5.3 KB
200 Bytes
Typical RAM use*
640 Bytes
17µS
Task switching time**
32.5µS
9µS
Max. interrupt masking time**
9.5µS* OS work area and various stack areas in the following configuration
tasks: 10, semaphores: 2, eventflags: 2, mailboxes: 2, external interrupts: 2 levels** Clock 16 MHz, using on-chip memory
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

OSEK/VDX OS Specification
OSEK/VDX Project
standardizing an open-ended architecture for
distributed control units in automobiles
A real-time kernel API, and software interfaces andprotocols for communication and network
management are jointly specified.
OSEK/VDX OS Specification
very compact real-time kernel specification
targeted for automotive and distributed
applications
version 2.0 released in Oct. 1997
http://www-iiit.etec.uni-karlsruhe.de/~osek/main.html
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Designing with a Real-Time Kernel
two important design issues with a real-time kernel
How the system is decomposed into tasks?
How priorities are assigned to the tasks?
theoretically ... (various assumptions omitted)
Deadline monotonic priority assignment is the
optimal static priority assignment method, inorder not to miss any deadlines.
static ... The priority of a task is assigned statically.
deadline monotonic... Task with shorter deadline should be
assigned a higher priority.
RMA (Rate Monotonic Analysis) theories
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

How Deadlines Look Like?
Example 1. (input – output relation)
An LED must be lighted on within 500 msec aftera switch is pushed.
deadline = 500 msec
Example 2. (input – output relation)
A robot arm must be stopped within 200 msec
after a collision is detected.
deadline = 200 msec – [mechanical time]
Example 3. (input – input relation)
A data must be taken out of a buffer within 10 msec
after the system receives the data. (Otherwise, thedata may be overwritten by the next data.)
deadline = 10 msec
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Decomposing into Tasks
Basic Guidelines
Programs (or routines) started with different eventsshould be included in different tasks.
Each task is started with a kind of event.

Programs with different deadlines should be
included in different tasks.
Deadline monotonic priority assignment becomes
possible.
Another Guideline (from another motivation)
decomposition for modular designeg.) Different groups of I/O devices should be
handled with different tasks.
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Basic Design Flowapplication code fragments
listing up deadlines
grouping codefragments into tasks

theoretical approachwith RMA
experimental approachassigning priorities
schedulability test
success
application system
Hiroaki Takada

failedtuning process

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Another Type of Timing Constraints
Example.
A series of data must be sent to an output port every
100 msec. (Permissible error of the period is 1%.)translate
The program to send a data to the port should bestarted at 99 msec after the previous data is sent,
and its deadline is 2 msec.
How if some pre-processing is necessary for
preparing the next data and its execution time islonger than 2 msec?
The deadline of the pre-processing is longer.
Decompose into separate tasks !
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Realizing Mutual Exclusion
mutual exclusion... When a task is accessing a shared resource,
the other tasks must not access it.
disabling task dispatchings (or interrupt services)while a task is accessing a shared resource
using a semaphore
A semaphore (or an equivalent) is supported withmost real-time kernels.

disadvantages
priority inversion problem
Contending tasks may be blocked.

Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

stack resource policy
sometimes called as priority ceiling protocol
Before a task accesses a shared resource, the priority of thetask is temporarily raised to the same or a higher level thanany other task that can access the same shared resource.
After the access, the priority of the task is recovered to its
original level.

advantages
Tasks are never blocked for mutual exclusion.
limitations
A task must not be blocked while it is accessing
a shared resource.
Which task accesses which shared resourcemust be known beforehand.
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

APIs with µITRON Kernel
creating a task (statically)
cre_tsk / CRE_TSK
The initial priority of the task is passed as a parameter.

starting / terminating a task
sta_tsk / ext_tsk
changing the priority of a task
chg_priobtaining / releasing a semaphore
wai_sem / sig_sem
Many other APIs (about 100) are defined in the µITRON
specifications.
Only used code is linked to the application.
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Blocked vs. Terminated
A blocked task will resume execution from theblocked point.
The task context must be saved during the task
is blocked.
A terminated task will be started from the beginning.
The task context need not be saved when it isterminated.
All the tasks that are never blocked can share a stack(if the real-time kernel supports it).
Apply to the other synchronization pattern !

! Notice that the name of task states are different
for each real-time kernel.

Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Task States with µITRON Kernel
NON-EXISTENT
cre_tsk

DORMANT
ext_tskRUNNINGterminateddel_tsk

ter_tskscheduledpreempted

sta_tskREADY

WAITINGWAITING-SUSPENDED
SUSPENDED
Hiroaki Takada

blockedDesigning Embedded Systems with µITRON Kernel

ESC Spring '98

Relaxing the Basic Guidelines
Naive application of the basic guidelines may result
in too large number of tasks.
not good for saving memory space
The basic guidelines can be relaxed.
A task with longer deadline can be included
in a task with shorter deadline.
An event-driven task can be included in aperiodic task if the period is enough shorter
than the deadline of the event-driven task.
many others ...

Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

Summary
A real-time kernel is an effective even for small-scale
embedded system.
trade-off between the elegant programming styleand the efficiency (esp. memory consumption)
A basic approach in designing with a real-time kernel
is introduced.
How to decompose the system into tasks?
How priorities are assigned to the tasks?
An effort in the ITRON Project
establishing “application design guidelines” forreal-time systems
important for the circulation of software components
Hiroaki Takada

Designing Embedded Systems with µITRON Kernel

ESC Spring '98

For Further Information
ITRON Home Page
http://tron.um.u-tokyo.ac.jp/TRON/ITRON/
RMA (Rate Monotonic Analysis)[6] A Practitioner's Handbook for Real-Time Analysis:
Guide to Rate Monotonic Analysis for Real-Time Systems

Intermediate Courses on RTOS Use
311–321 Multitasking Design and Implementation Issues
in Embedded Systems
331–341 RTOS Design: How Your Application is Affected

presentation material of this class(will be available within a week)
http://www.ertl.ics.tut.ac.jp/~hiro/escs98-ohp.pdf
Hiroaki Takada