IntroToRTOSandOSEK_Module1

Delphi Business Proprietary

Introduction to RTOS / OSEKModule 1

Electronics & Safety

- 1 -Delphi Software Global College

Introduction toReal-Time Operating

Systemsand

OSEK/VDXCourse #25516

IntroToRTOSandOSEK_Module1.ppt;1

31 March, 2006Software Forward Engineering

Delphi Electronics & Safety Copyright 2003-2006 Delphi Technologies, Inc. All rights reserved.





To view the Notes that accompany this presentation:– Right-click and select Save Target As… to save this as a PowerPoint

presentation, then open the PowerPoint presentation.

– Click View, then Notes Page from the menubar. The Notes Page view will be displayed.

– If necessary, use the scroll bars to scroll tothe bottom of the page where the notes arelocated.

How to View the Notes Pages





Delphi Absolutes of Excellence

THE DELPHIA B S O L U T E S

ofE X C E L L E N C E

Focus: Your Customer

Performance Goal: Do It Right The First Time, Every Time

Method: Innovation & Continuous Improvement

Control: Customer Feedback

People: Caring

Style: Teamwork

Reward: Recognition & Security





Class Overview

Description– This course is an introduction and/or refresher for engineers in the Software

competency. The course will cover real-time operating systems concepts and the differences between an RTOS and a cyclical executive.

– The course will also provide an overview of the OSEK/VDX standard for automotive real-time operating systems and discuss issues involved in using OSEK.

– Finally, the class will cover current RTOS and OSEK related activities at Delphi.– The purpose of this course is to provide a basic introduction to real-time operating

systems, and to OSEK/VDX - a set of standards for real-time operating systems designed for use in automotive systems.

Audience– This course is intended for Software or Systems Engineers needing an

introduction to RTOS concepts or an overview of the OSEK/VDX operating system standards.





Class Objectives

Upon completion of this training, you should be able to:

– Understand the difference between cyclic executives and preemptive multitasking operating systems.

– Be familiar with RTOS concepts such as» tasks» ISRs» priorities» scheduling» synchronization

– Understand the basic concepts behind the OSEK/VDX standards.

– Know about how using an RTOS affects some system design issues.

– Be aware of RTOS- and OSEK-related activities at Delphi, and know where to find more information.





Course Outline

Module 1– Class Information & Introductions– Introduction to Real-Time Operating Systems– Real-Time Operating System Concepts

Module 2– Overview of OSEK/VDX

» The OSEK/VDX Project» OSEK OS» OSEK OIL» OSEK COM» OSEK NM

Module 3– RTOS System Architecture Issues– RTOS and OSEK Activities at Delphi– Summary

Refer to the Glossary at the end of Module 3 of this training material for

definitions of acronyms, abbreviations and other terms used. Most can also

be found in the on-line dictionary





Course Outline

Class Information & Introductions Introduction to Real-Time Operating Systems Real-Time Operating System Concepts Overview of OSEK/VDX

– The OSEK/VDX Project– OSEK OS– OSEK OIL– OSEK COM– OSEK NM

RTOS System Architecture Issues RTOS and OSEK Activities at Delphi Summary





Section 1

Introduction toReal-Time Operating

Systems





What is an Operating System? Software that provides an intermediate layer between an application

and the target hardware Provides a layer of abstraction between the application software and

the computer hardware Operating System Responsibilities:

– Manage and allocate computer resources (CPU, memory, devices, etc.)– Control execution of application program(s) and operation of I/O devices– Utilize the computer hardware in an efficient manner

Examples:– Time-Sharing / Single-User:

» OS/360 MVS» MS-DOS» MS-Windows» Max OS-X» UNIX» LINUX» VAX/VMS

– Real-Time:» ITRON» LynxOS» OS-9» QNX» VxWorks» VTRX» MicroC/OS-II» OSEK/VDX





What is a Real-Time Operating System?

A Real-Time Operating System (RTOS) differs from a user-oriented (time-sharing) RTOS:

Criteria Time Sharing System Real-Time Systems

Capacity High-throughput; efficient use of system resources

The ability of system tasks to meet all deadlines, even at high levels of resource usage (schedulability)

Responsiveness Fast average response times Predictably fast response to urgent events; known worst-case response time to events (latency)

Overload Fairness - equitable sharing of overloaded resources

When the system is overloaded by events and cannot meet all deadlines, meeting selected critical deadlines can still be guaranteed (stability)





Conceptual Model for Real-Time Systems

Event

time

Processing Time

Function

Latency

Deadline

Maximum Response Time

Response

A Real-time System must provide a response to a given input, and must do it before a specified deadline





Simple Cyclic Scheduling

0 ms

5 ms

10 ms

15 ms

Function Period (Max.) Processing Time

Function1 5 ms 1.0 ms



void main(void)

{

Initialize();

for (;;)

{

Function1();

Function2();

Function3();

DelayUntilNextCycle();

}

}

Source: LiveDevices Inc.





Calculating Processor Utilization

Ideal:– Ideally, the processor utilization of a periodic function can be calculated by

dividing its processing time by its period.– Example:

» If Function1 take 1 millisecond to execute, and runs every 5 milliseconds, it consumes 20% of the processor throughput.

Actual:– Simple cyclic scheduling may require that some tasks be run more frequently than

would otherwise be necessary, in order to keep the scheduler simple.– Those tasks therefore consume more throughput than the ideal case.

FunctionProcessing

TimePeriod(Max.)

Utilization(Ideal)

Period (Actual)

Utilization(Actual)

Function1 1.0 ms 5 ms 20% 5 ms 20%



Total: 45% 80%





Cyclic Scheduler “Overhead”

0 ms

5 ms

10 ms

15 ms





Function2 executed more often than required; uses 24% of throughput, instead of 12%.

Function3 executed more often than required; uses 36% of throughput, instead of 13%.

Overall, the system uses 80% of the throughput. Adding more functionality or an interrupt that uses 1.0 ms processing time

makes the system fully loaded. (Even if interrupts are more than 5 ms apart.)






Major/Minor Loop Cyclic Scheduling

0 ms

5 ms

10 ms

15 ms


Interrupt 1 10 ms (min.) 0.5 ms




Design: 10 ms major cycle, containing 5 ms minor cycles

Function1 and Function2 run every minor cycle; Function3 runs every major cycle

Time must be allocated for Interrupt 1 in every minor cycle (even though it will used less than half the time).

Throughput: Better, but Function3 is still executed more often than required; it uses 18% of throughput, instead of 13%.


void main(void){ int cycle;

Initialize(); for (cycle = 0; ; cycle++) { Function1(); Function2(); if (0 == (cycle & 0x1)) { Function3(); } DelayUntilNextCycle(); }}





Cyclic Scheduling: Adding a Function

0 ms

5 ms

10 ms

15 ms


Interrupt 1 10 ms (min.) 0.5 ms





Change:– Function2 reduced to 0.8 ms– Function3 reduced to 1.2 ms– New Function4 added.

There is sufficient throughput available, but Function4 must be artificially partitioned to make it fit.






Cyclic Scheduling: Observations

Advantages:– Simple in concept– Predictable behaviour– Minimal processing overhead

Disadvantages:– Design complicated by timing behaviour– Inflexible – Maintenance can be difficult– Processor time is not used efficiently

Alternative: Preemptive Multi-tasking RTOS– Improved CPU utilization– Timing behaviour more complex (but handled by the RTOS)– Separates functional design from temporal design– Increased overhead for RTOS kernel





Preemptive Scheduling: Concept

Functions are allocated to tasks Tasks are assigned priorities

– Based on the urgency of each task’s functions

RTOS manages task execution– The RTOS always runs the highest priority ready-to-run task– The RTOS preempts a lower priority task to run a higher priority task– The lower priority task is suspended until the higher priority task finishes– The lower priority task is resumed when no higher priority task is ready to run.

time

priorityhigher prioritytask activated

lower prioritytask resumed





Cyclic vs. Preemptive Scheduling

0 ms

5 ms

10 ms

15 ms

0 ms

5 ms

10 ms

15 ms

ISR1

Task1

Task2

Task3

Task4

(Idle)

priority






Why Use a Real-Time Operating System?

Maximizes CPU utilization Provides well-defined functionality and behavior Encapsulates scheduling independent of the application

– Allows time-dependent aspects to be separated from functional aspects

Hides implementation issues from application developers– Hardware– Software

Simplifies software system design Operating system becomes the interface (API), not the

hardware Supports potential code generation Provides capability for software reuse / portability





Preemptive RTOS Challenges

RTOS kernel adds processing overhead– For switching between tasks– Some code space is required for the RTOS code

Preemption requires additional stack space– Can be reduced by optimization

Critical sections– Task synchronization and data coherency must be addressed– If tasks share data, there is the possibility of incorrect data

Timing behavior is complex– Preemption must be accounted for– Tasks can start or be preempted at arbitrary times– Low-priority tasks may never get to execute (starvation)





Course Outline

Class Information & Introductions Introduction to Real-Time Operating Systems Real-Time Operating System Concepts Overview of OSEK/VDX

– The OSEK/VDX Project– OSEK OS– OSEK OIL– OSEK COM– OSEK NM

RTOS System Architecture Issues RTOS and OSEK Activities at Delphi Summary





Section 2

Real-Time Operating System

Concepts





Tasks

A task is the basic unit of execution in an RTOS– Each task “thinks” it has the CPU all to itself– The RTOS implements multi-tasking, allowing tasks to share the CPU

A task’s context is how the RTOS perceives a task A context switch occurs when the RTOS decides to run a

different task A Task Control Block (TCB) is a data structure used by the

RTOS to manage each task The TCB stores a tasks’ context, and may contain

– program counter– status register– stack pointer– CPU registers– task data





The RTOS provides a state machine for each task– Each task can be in only one state at a time– Only one task can be in the running state at a given time– The RTOS saves and restores task context in conjunction with task state

transitions

The state machine used depends on the RTOS

Task States

release

suspendedwaiting

ready

runningwait

preemptstart/resume

terminate

activate

All tasks are initially in

the suspended state.





Preemptive Scheduling

Two Schemes for Scheduling:– Non-preemptive

» Once the processor is given to a task, that task cannot be preempted by another task (even if it has higher priority), until the running task relinquishes the processor itself

– Preemptive» If a new task with a priority higher than the currently executing task becomes

ready to run, then the operating system will preempt the current task and switch to the higher priority task





Task-to-Task Context Switch

Task-to-Task Context Switch:

– Occurs when» a higher-priority task preempts the current task, or » a lower-priority task resumes after having been preempted

– Handled by the RTOS» Save the context of the currently running task» Initialize or restore that context of the new running task» Accomplish this such that the context switch is transparent to the tasks

involved





Task-to-Task Context Switch(Illustration Step 1 of 9)

C P U

PC

MSR

R0

R1

R2

R3

SP

A simple conceptual CPU: Stack Pointer (SP) Program Counter (PC) Machine Status Register (MSR) Four General-Purpose Registers (R0, R1, R2, R3)






C P U

PC

MSR

R0

R1

R2

R3

SP

Task 1, the Currently Running Task SP points to function data on task’s stack PC points to current instruction of task’s code

Task1 Stack

Func1A Data

Func1B Data

Func1B Code

…

...

...

SP

Task1 TCB

…





C P U

PC

MSR

R0

R1

R2

R3

SP

Task 2, the Highest-Priority Task Previously suspended SP in TCB points to function data on task’s stack When some event makes Task 2 ready, the RTOS will perform a context switch …

Task1 Stack

Func1A Data

Func1B Data

Func1B Code

…

...

...

SP

Task1 TCB

…

Func2B Data

Func2C Data

Func2A Data

MSR

Func2C Code

...

Task2 Stack

PC

...

R3

R2

R1

R0

SP

Task2 TCB

…






The PC and MSR state are saved on Task1’s stack Equivalent to start of interrupt processing

The RTOS takes control

Func2B Data

Func2C Data

Func2A Data

MSR

Func2C Code

...

Task2 Stack

PC

...

R3

R2

R1

R0

SP

Task2 TCB

…

C P U

PC

MSR

R0

R1

R2

R3

SP

RTOS Code…

Task1 Stack

Func1A Data

Func1B Data

Func1B Code

…

...

...

SP

Task1 TCB

…

MSR

PC






Func2B Data

Func2C Data

Func2A Data

MSR

Func2C Code

...

Task2 Stack

PC

...

R3

R2

R1

R0

SP

Task2 TCB

…

The RTOS saves the general-purpose registers on Task1’s stack

C P U

PC

MSR

R0

R1

R2

R3

SP

RTOS Code…

Task1 Stack

Func1A Data

Func1B Data

Func1B Code

…

...

...

SP

Task1 TCB

…

MSR

PC

R3

R2

R1

R0






Func2B Data

Func2C Data

Func2A Data

MSR

Func2C Code

...

Task2 Stack

PC

...

R3

R2

R1

R0

SP

Task2 TCB

…

The RTOS saves the stack pointer (SP) in Task1’s TCB All of Task1’s context is now saved

C P U

PC

MSR

R0

R1

R2

R3

SP

RTOS Code…

Task1 Stack

Func1A Data

Func1B Data

Func1B Code

…

...

...

SP

Task1 TCB

…

MSR

PC

R3

R2

R1

R0






Func2B Data

Func2C Data

Func2A Data

MSR

Func2C Code

...

Task2 Stack

PC

...

R3

R2

R1

R0

SP

Task2 TCB

…

The RTOS sets the stack pointer (SP) to the value previously stored in Task2’s TCB

C P U

PC

MSR

R0

R1

R2

R3

SP

RTOS Code…

Task1 Stack

Func1A Data

Func1B Data

Func1B Code

…

...

...

SP

Task1 TCB

…

MSR

PC

R3

R2

R1

R0






Func2B Data

Func2C Data

Func2A Data

MSR

Func2C Code

...

Task2 Stack

PC

...

R3

R2

R1

R0

SP

Task2 TCB

…

The RTOS pops the general-purpose register values from Task2’s stack

C P U

PC

MSR

R0

R1

R2

R3

SP

RTOS Code…

Task1 Stack

Func1A Data

Func1B Data

Func1B Code

…

...

...

SP

Task1 TCB

…

MSR

PC

R3

R2

R1

R0






The RTOS executes a RETURN-FROM-ISR (Interrupt Service Routine) operation The PC and MSR values are popped off Task2’s stack

Task2 is now the current running task, and takes control … … picking up where it was when it got suspended

C P U

PC

MSR

R0

R1

R2

R3

SP

RTOS Code…

Task1 Stack

Func1A Data

Func1B Data

Func1B Code

…

...

...

SP

Task1 TCB

…

MSR

PC

R3

R2

R1

R0

Func2B Data

Func2A Data

MSR

Func2C Code

...

Task2 Stack

PC

...

R3

R2

R1

R0

SP

Task2 TCB

…

Func2C Data






Preemption and Reentrant Code

Since a task can be preempted at any time, task code must be reentrant.

Reentrant code is code designed to maintain data integrity even though the code can be interrupted at any point, and a parallel instance of code may be invoked.

To be reentrant, code must– Use any shared variables in an atomic or protected way– Access hardware resources in an atomic way– Not call any non-reentrant functions

The concept of reentrant code is covered in detail inISRs, Concept of ‘Volatile’ Keyword & Reentrant Functionsin Embedded System Software

(http://software.delcoelect.com/STP/classes/EmbeddedC/Interrupts and Reentrant_Functions.ppt)





Task Synchronization

A resource is any entity that is used by a task– I/O device– Register– RAM variable

A shared resource is a resource that may be used by more than one task

For shared resources, task synchronization is required to prevent potential corruption of data

Techniques for task synchronization are discussed in detail later …





Schedulability Analysis

0 ms

5 ms

10 ms

15 ms

Task / Interrupt Period Processing Time Deadline

ISR1 5 ms (min) 0.2 ms ---

ISR2 10 ms (min) 0.5 ms ---

Task1 3 ms 0.5 ms 3 ms




ISR1

ISR2

Task1

Task2

Task3

Task4

(Idle)

Rn+1i = Ci +

khp(i)

Ck

Rin

Tk

Response < Deadline






Accounting for RTOS Overheads

0 ms

5 ms

10 ms

15 ms

ISR1

ISR2

Task1

Task2

Task3

Task4

(Idle)

Task / Interrupt Period Processing Time Deadline

ISR1 5 ms (min) 0.2 ms ---

ISR2 10 ms (min) 0.5 ms ---





DeadlineResponse Deadline

Response

RTOS Task/ISR Context Switch Times– Add overhead to system scheduling– Must be taken into account when analyzing schedulability– Schedulability analysis tools need to be calibrated

– for RTOS overheads– on the target processor





End of Module 1





Revision History

Revision& Date

By Description

131-MAR-06

M. Malone Derived from revision 9 of the original training, now split into 3 modules.

IntroToRTOSandOSEK_Module1

Documents

delphi business proprietary

task2 tcb sp

task1 tcb sp

time operating systems

time operating system

lower priority task

higher priority task

task context switch