+ All Categories

6_RTOS2

Date post: 08-Apr-2018
Category:
Upload: olu-adesola
View: 217 times
Download: 0 times
Share this document with a friend
13
Embedded Systems 6. Real-Time Operating Systems Lothar Thiele 6 - 1 Swiss Federal Institute of Technology Computer Engineering and Networks Laboratory 1. Embedded Systems Introduction 10. Models 2. Software Introduction 7. System Components 8. Communication 3. Real-Time Models . u Synthesis . 5. Resource Sharing 9. Low Power Design 6. Real-Time OS Software and Processing and 12. Model Based Design 6- 2 Swiss Federal Institute of Technology Computer Engineering and Networks Laboratory Programming Communication  
Transcript

8/7/2019 6_RTOS2

http://slidepdf.com/reader/full/6rtos2 1/13

Embedded Systems

6. Real-Time Operating Systems

Lothar Thiele

6 - 1Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

1. Embedded Systems Introduction

10. Models2. Software Introduction 7. System Components

8. Communication3. Real-Time Models. uSynthesis

.

5. Resource Sharing

9. Low Power Design

6. Real-Time OS

Software and Processing and 12. Model Based Design

6- 2 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

Programming Communication  

8/7/2019 6_RTOS2

http://slidepdf.com/reader/full/6rtos2 2/13

4.3.1 

Why an OS at all ?

Same reasons why we need one for a traditional computer.

Not all services are needed for any device.

Large variety of requirements and environments:

 applications, space shuttle, …).

Critical a lications with small functionalit ABS ace maker, …)

Not very critical applications with varying functionality (PDA,phone, smart card, microwave ofen, …)

6- 3 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

Why is a desktop OS not suited ?

Monolithic kernel is too feature reach.

Monolithic kernel is not modular, fault-tolerant, configurable,

, … . Takes too much space.

.

Not designed for mission-critical applications.

6- 4 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

8/7/2019 6_RTOS2

http://slidepdf.com/reader/full/6rtos2 3/13

 

Configurability 

No single RTOS will fit all needs, no overhead for

unused functions tolerated

configurability needed.

Simplest form: remove unused functions (by linker ?).

Conditional compilation (using #if and #ifdef commands).

ynam c ata m g t e rep ace y stat c ata.

- .

6- 5 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

_     d    s .    p

     d     f

    a     d    o     2     /     t    o    r    n    a     d    o_

     t_     t    o    o     l    s     /     i     d    e     /     t    o

    r    n

    c     t    s     /     d    e    v    e     l    o    p    m    e

    r     i    v    e    r .    c    o    m     /    p    r    o     d    u

     t     t    p    :     /     /    w    w    w .    w

     i    n     d

6- 6 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

 © Windriver

8/7/2019 6_RTOS2

http://slidepdf.com/reader/full/6rtos2 4/13

 

Device drivers handled by tasks instead of integrated drivers:

Improve predictability; everything goes through scheduler

Effectively no device that needs to be su orted by all versionsof the OS, except maybe the system timer.

RTOS Standard OS

6- 7 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

Interrupts can be employed by any process 

For standard OS: would be serious source of unreliability.

Embedded programs can be considered to be tested … .

It is possible to let interrupts directly start or stop tasks (by storing thetasks start address in the interrupt table). More efficient and

.

However, composability suffers: if a specific task is connected tosome interrupt, it may be difficult to add another task which alsoneeds to be started by the same event.

6- 8 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

8/7/2019 6_RTOS2

http://slidepdf.com/reader/full/6rtos2 5/13

8/7/2019 6_RTOS2

http://slidepdf.com/reader/full/6rtos2 6/13

-

2. OS must mana e the timin and schedulin 

• OS possibly has to be aware of task deadlines;

- .

• OS must provide precise time services with high resolution.

3. The OS must be fast 

• Practically important.

6-11Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

Process management :

Execution of quasi-parallel tasks on a processor usingprocesses or threads (lightweight process) by

• , ,• preemptive tasks (fast context switching) and quick

interru t handlin

CPU scheduling (guaranteeing deadlines, minimizingprocess waiting times, fairness in granting resources such ascomputing power)

Process synchronization (critical sections, semaphores,,

Inter-process communication (buffering)

6-12 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

8/7/2019 6_RTOS2

http://slidepdf.com/reader/full/6rtos2 7/13

 

6-13 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

Minimal Set of Process States :

terminate

runwait

end_cycleTIMER

wait dispatch

readsignal

preemption

activate

6-14 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

8/7/2019 6_RTOS2

http://slidepdf.com/reader/full/6rtos2 8/13

 

Run :

tas enters t s state as t starts execut ng on t e processor

Ready :  

because the processor is assigned to another task.

Wait :

A task enters this state when it executes a synchronization primitive towait for an event, e.g. a wait primitive on a semaphore. In this case,the task is inserted in a ueue associated with the sema hore. Thetask at the head is resumed when the semaphore is unlocked by asignal primitive.

A periodic job enters this state when it completes its execution and hasto wait for the beginning of the next period.

6-15 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

A thread is an execution stream within the context of a thread. ., .

The key difference between processes and threads : multiplethreads share arts of their state. 

Typically shared : memory.

Typically owned : registers, stack.

Thread advantages and characteristics

Faster to switch between threads; switching between user-level.

Typically, an application will have a separate thread for eachdistinct activity.

Thread Control Block (TCB) stores information needed tomanage and schedule a thread

6-16 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

8/7/2019 6_RTOS2

http://slidepdf.com/reader/full/6rtos2 9/13

 

6-17 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

Process synchronization :

In classical operating systems, synchronization and mutualexclusion is performed via semaphores and monitors.

- ,into scheduling is necessary (priority inheritance protocols,….).

Further responsibilities :

Initializations of internal data structures (tables, queues, taskdescription blocks, semaphores, …)

6-18 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

8/7/2019 6_RTOS2

http://slidepdf.com/reader/full/6rtos2 10/13

 

Problem : the use of shared resources for implementingmessage pass ng sc emes may cause pr or ty nvers on

and blocking.

6-19 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

Synchronous communication :

Whenever two tasks want to communicate they must besynchronized for a message transfer to take place (rendez- 

They have to wait for each other.

Problem in case of d namic real-time s stems: Estimatin the maximum blocking time for a process rendez-vous.

In a static real-time environment, the problem can be solvedoff-line by transforming all synchronous interactions intoprecedence constraints.

6-20 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

8/7/2019 6_RTOS2

http://slidepdf.com/reader/full/6rtos2 11/13

 

Asynchronous communication :

as s o not ave to wa t or eac ot er

The sender just deposits its message into a channel andcontinues its execution similarl the receiver can directlaccess the message if at least a message has beendeposited into the channel.

- .

Mailbox : Shared memory buffer, FIFO-queue, basicoperations are send and receive, usually has fixed capacity.

Problem : Blocking behavior if channel is full or empty;alternative approach is provided by cyclical asynchronous

.

EmpfängerSender

6-21Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

mailbox

4.3.2 

-  

because they are designed to be fast, rather than to be 

redictable in ever res ect 

 

QNX, PDOS, VCOS, VTRX32, VxWORKS.

6-22 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

8/7/2019 6_RTOS2

http://slidepdf.com/reader/full/6rtos2 12/13

 

Real-time extensions to standard OS :ttempt to exp o t com orta e ma n stream .

RT-kernel running all RT-tasks.- .

+ Crash of standard-OS does not affect RT-tasks;- RT-tasks cannot use Standard-OS services;

6-23 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

RT-tasks cannot use standardOS calls.Commercially available from

n as oz a

sm a s www. sm a s.com

Linux-Kernel

scheduler

- as - asdriver

RT-Linux RT-Schedulerinterrupts

I/O

Hardwareinterrupts

6-24 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory 

8/7/2019 6_RTOS2

http://slidepdf.com/reader/full/6rtos2 13/13

 

Research systems trying to avoid limitations :

Include MARS, Spring, MARUTI, Arts, Hartos, DARK, and Melody

Research issues: 

low overhead memory protection,

temporal protection of computing resources

RTOSes for on-chip multiprocessors

- .

6-25 Swiss Federal Institute of Technology 

Computer Engineering and Networks Laboratory