Courser To S

Real-Time Operating Systems
Ludovic Apvrille
Telecom ParisTech Eurecom, Oce 470 ludovic.apvrille@telecom-paristech.fr
Fall 2012
Outline
Embedded Systems in a Nutshell Introduction Architecture Real-time Systems in a Nutshell Denition Examples of real-time and embedded systems Real-Time Operating Systems Basics Advanced concepts Exceptions and interrupts Timers Real-Time UNIX Towards real-time Unix Scheduling issues Linux for real-time systems
Embedded Systems in a Nutshell Real-time Systems in a Nutshell Real-Time Operating Systems Real-Time UNIX
Introduction Architecture
Outline
Embedded Systems in a Nutshell Introduction Architecture Real-time Systems in a Nutshell Real-Time Operating Systems Real-Time UNIX
Ludovic Apvrille
Real-Time Operating Systems - Fall 2012
3 of 75
What is an Embedded System?

Denitions
Computer system designed for specic purpose
Tightly coupled hardware and software integration
An embedding system may include several embedded systems
PC vs. embedded systems
PC: general-purpose microprocessor and OS
High power consumption, heat production, large size Dedicated system
Embedded system
Dedicated hardware (e.g., DSPs) and software
Constraints of consumption, heat, size, performance, price, . . .

Ludovic Apvrille Real-Time Operating Systems - Fall 2012 4 of 75
A Few Characteristics of Embedded Systems

Environment
The system evolves in an environment that must be taken into account: Temperature, vibration, impacts, variable power supply, interferences, corrosion, re, water, radiations, etc.
Criticality

Failures may have major consequences The system should always perform correctly!
Hardware level: for example, a specication could be that the system should continue to work even if an electronic component fails (redundancy) Safety at software level: e.g., handling of possible bugs and crash
Various execution modes

Highly Available Systems
Number of 9s 3 Nines (99.9%) 4 Nines (99.99%) 5 Nines (99.999%) 6 Nines (99.9999%)
Downtime per year 9h 1h 5mn 30s
Typical application Desktop Enterprise server Carrier-class server Carrier-switch equipment
Source: Providing Open Architecture High Availability solutions, Revision 1.0, Published by HA Forum, Feb. 2001
Ludovic Apvrille
6 of 75
A Few Characteristics of Embedded Systems (Cont.)

Reduced space, weight and consumption
Example: smartphones

Memory size is small with regards to PCs Reduced computation power
Various techniques

Mix of analog, digital, software functions Hardware / software co-design System on a Chip (SoC)
Ludovic Apvrille
7 of 75
High-level Architecture
Embedded system = controlling system + controlled system + environment
Ludovic Apvrille
8 of 75
Response to External Events
Ludovic Apvrille
9 of 75
Example of Embedded Systems
Ludovic Apvrille
10 of 75
Typical Cross-Platform Environment for the Development of Embedded Systems
Ludovic Apvrille
11 of 75
View of the Target Embedded System
Ludovic Apvrille
12 of 75
Embedded Systems Initialization
Ludovic Apvrille
13 of 75
Embedded Systems Initialization (Cont.)
Starting execution at the reset vector
Code located at a predened and hard-wired address location
Putting the processor in a known state by setting the appropriate registers

Getting processors type Getting or setting CPUs clock speed
Disabling interrupts and cache memories Initializing memory controller, memory chips, and cache units

Getting the start address for memory Getting the size of memory Performing preliminary memory tests, if required
Ludovic Apvrille
14 of 75
Embedded Systems Initialization (Cont.)
Copying and decompressing early code and data into RAM
Low-level assembly language specic to the target architecture
Executing boot code initializing other hardware components

Setting up execution and interrupt handlers Initializing bus interfaces such as VME, PCI and USB Initializing board peripherals such as serial, LAN and SCSI
All the boot code is known as BSP (Board Support Package)
Ludovic Apvrille
15 of 75
Debugging
ROM Monitor
Uses serial line
On-Chip Debugging (OCD) = built-in microprocessor debugging capabilities

BDM - Background Debug Mode JTAG - Joint Test Action Group No need for underlying software support on chip Content of processor registers System memory dump Instruction under execution
OCD-aware host debugger displays information such as

Ludovic Apvrille
16 of 75
Denition Examples of real-time and embedded systems
Outline
Embedded Systems in a Nutshell Real-time Systems in a Nutshell Denition Examples of real-time and embedded systems Real-Time Operating Systems Real-Time UNIX
Ludovic Apvrille
17 of 75
What is a Real-Time System?

Real-Time Systems have been dened as:
Those systems in which the correctness of the system depends not only on the logical results of the computation, but also on the time at which the results are produced
(J. Stankovic, Misconceptions About Real-Time Computing, IEEE Computer, 21(10), October 1988)
Ludovic Apvrille
18 of 75
What is a Real-Time System? (Cont.)

More precisely, a system is said to be a Real-Time System if:
It reacts to external stimuli
System interacting with its environment
It reacts to these stimuli within a limit of time, regardless of the load of the system

WCET = Worst Case Execution Time Timing correctness
Vs. usual systems

Only logical correctness Manage the average case
Best eort
Response to External Events
Ludovic Apvrille
20 of 75
Jobs and Tasks

Denition

A task is a set of related jobs joined to provide functions A job is a unit of work executed by the system
Parameters
Temporal behavior
E.g., a job lasting less than 20ms, a periodic task with period = 30ms
Functional: intrinsic properties of the job (e.g., taps of lter) Resource requirements (e.g., 10kb of memory) Interconnection: its communication with other jobs

E.g., a decoding job must send its result to a displaying job Relies on shared memory, message queues, etc.
Time Constraints
Time constraint = Constraint imposed on the timing behavior of a job
Release time
Instant of time when a job becomes available for execution
Deadline

Instant of time at which a job is required to be completed Absolute deadline = release time + relative deadline
Response Time
Dierence between the completion time and the release time of a job
System Latency
System latency = End-to-end delay between a change of state in the environment, and the corresponding output reaction produced by the system Latency involves: delay for scanning the environment, delay due to the OS, delay for executing calculations, delay for producing output results (communication delay)
Jitter = incertitude on delays
Load of the system, etc. Should be low with regards to the latency
Determinism Issue
Computing time
Each activity can use various execution branches Status of messages queues, delay of signals, etc.
Communication time
Interrupts Software or hardware exceptions
Ludovic Apvrille
24 of 75
Hard and Soft Real-Time Systems

Comparison between hard and soft systems
1. The degree of tolerance of missed deadlines 2. The usefulness of computed results after missed deadlines 3. The severity of penalty incurred for failing to meet deadlines Hard system Zero tolerance Useless Catastrophic Soft system Non-zero Not zero right after passing deadline Non-catastrophic
1 2 3
Complex real-time and embedded systems

A complex real-time and embedded system is commonly a mix of hard and soft subsystems
Example 1: A GSM Phone

Specication
Software is in charge
Of some operations performed at physical level (receiving, sending, measuring the level of the electromagnetic eld, etc.) Of logical operations such as scanning for incoming calls, maintaining connections when changing of beams, etc. 577s of voice data are transmitted every 4.6ms 577s of voice data are received every 4.6ms If the distance to the relay is increasing, data should be emitted earlier to remain synchronized with the relay (Doppler eect)
Sending and receiving voice data is a critical task

Management of the mobility issue
Ludovic Apvrille
26 of 75
Example 1: A GSM Phone (Cont.)
Constraints

Local (temporal) constraints on sending and receiving Global constraints: audio quality
Example 2: A Multimedia System

Discrete media vs. continuous media
Discrete media (=static): media characterized by their spatial dimension: text, images Continuous media (=dynamic or isochrones): media with a temporal dimension: sound, video and animations
Quality of Service (QoS)

Fundamental issue! Use of synchronization techniques
Ludovic Apvrille
28 of 75
Example 2: A Multimedia System (Cont.)
Ludovic Apvrille
29 of 75
True or False?
A real-time system runs faster than usual systems? An elevator controlling system is a real-time system? A real-time application can be executed on every operating systems?
Ludovic Apvrille
30 of 75
Basics Advanced concepts Exceptions and interrupts Timers
Outline
Embedded Systems in a Nutshell Real-time Systems in a Nutshell Real-Time Operating Systems Basics Advanced concepts Exceptions and interrupts Timers Real-Time UNIX
Ludovic Apvrille
31 of 75
Limitations of General-Purpose OS for Real-Time Systems
Scheduling policies share CPUs in fair way They dont take into account temporal constraints Communication mechanisms introduce non-deterministic temporal behavior Time is wasted at input / output management level Memory management (MMU, cache, dynamic allocation) introduces non-deterministic execution time Software timers used for managing time are not ne-grained enough
Use of a Real-Time Operating Systems

Key Characteristics
Reliability

Need to operate for a long period of time System reliability depends on all system elements
Hardware, BSP, RTOS and application(s)
Predictability

To a certain degree, and at least better than in GPOS Completion of system calls occurs within known frames
Benchmark on the variance of the response times for each system calls WCET
Ludovic Apvrille
33 of 75
Key Characteristics (Cont.)

Performance

CPU performance: MIPS Throughput performance: bps Performance should be measured as a whole
Compactness
RTOS memory footprint should be small
Scalability

Meet application-specic requirements Modular components File systems, protocol stacks, etc.
Target System Software Initialization Sequence
Ludovic Apvrille
35 of 75
Examples of RTOS
VxWorks LynuxWorks QNX Windows Phone, iOS, Symbian Linux for RT and embedded systems

CLinux RTLinux RTAI Android
Ludovic Apvrille
36 of 75
Developing an Application for VxWorks with Tornado
Ludovic Apvrille
37 of 75
Debuging Using WindView
Ludovic Apvrille
38 of 75
Scheduling
Limitations of schedulers in general-purpose OS
Schedulers are dened with interactivity in mind

Dynamic priorities Calculation tasks are penalized
Temporal constraints are not taken into account Schedulability analysis cannot be performed
Schedulers for Real-Time Systems

RMA, EDF, FCFS, Round-Robin, Fixed priority
Ludovic Apvrille
39 of 75
Memory Management
Dynamic allocations

Should be avoided at run-time Algorithms are based on xed-size blocks Pools of objects
Avoid frequent allocation and fragmentation
No memory compaction
Real-time compaction algorithms might be used
Most of the time, virtual addressing (i.e., MMU) is not used

And sometimes even not implemented in RTOS! Page fault introduces non-determinism
Input / Output Management

Limitations for RT systems
Dicult or impossible to bound the time to perform an I/O operation
Solutions

Drivers working closely with the kernel Deterministic delay in all inter-process communications
Communication structures with basic and deterministic algorithms
RT-FIFO, RT-signals, etc.
Ludovic Apvrille
41 of 75
IPC - Inter Process Communications
Limitations for RT systems
No deterministic transmission delay for:
Signals, pipes, message passing, semaphores, shared memory
A Few Solutions
Implementation with deterministic processing time
Example: RT-FIFO
RT-FIFO: FIFO with predened maximum size and with pre-allocated messages
Ludovic Apvrille
42 of 75
Exceptions and Interrupts

Exceptions
Events that disrupt the normal execution ow of the processor and force the processor to execute special instructions in a privileged state Synchronous exceptions
Divide by zero Pushing the reset button of the embedded system
Asynchronous exceptions
Interrupts
= Asynchronous exceptions triggered by events external hardware devices generate

Programmable Interrupt Controller
Hardware-implemented Prioritizing multiple interrupt sources so that at any time the highest priority interrupt is presented to the core CPU for processing PICs have a set of Interrupt Request Lines
Interrupt = physical signal on a given line ESR = Exception Service Routine ISR = Interrupt Service Routine
Handlers specied at PIC level

Ludovic Apvrille
44 of 75
Programmable Interrupt Controller (Cont.)
Ludovic Apvrille
45 of 75
Programmable Interrupt Controller: Example

Source Airbag sensor Brake sensor Fuel Level Sensor RTC Priority Highest Vector Address 14h IRQ 8 Max freq. N/A Description Detects the need to deploy airbags Informs about the current braking power Detects the level of fuel Clock runs at 10ms tick
46 of 75
High
18h
N/A
Med
1Bh
20Hz
Low
1Dh
100Hz
Ludovic Apvrille
Masking Interrupts
Why masking?
Reduce the total number of interrupts raised by devices
Interrupts are lost when masked
Function being processed is non-reentrant Atomic operations
How is masking done?
Disable the device so that it cannot assert additional interrupts Mask the interrupts of equal or lower priority levels Disable the line between the PIC and the core processor
Interrupts of any priority level do not reach the processor

Classication of Exceptions
Asynchronous Non-maskable
Cannot be blocked or enabled by software
Maskable
Can be blocked or enabled by software
Synchronous Precise
Program counter points to
Non-precise
Because of prefetching and pipelining techniques, no knowledge about the exact instruction that caused the exception
the exact instruction which caused the exception (Oending instruction)

Processor knows where to
resume the execution

General Exceptions Priorities
Ludovic Apvrille
49 of 75
Nested Interrupts
Ludovic Apvrille
50 of 75
Exceptions Timing
ESR and ISR should be short Designers

Should avoid situations where interrupts could be missed Should be aware of interrupt frequency of each device
Maximum allowed duration can be deduced from this information
Should take into account the fact that real-time tasks cannot execute when interrupts are being processed
Ludovic Apvrille
51 of 75
Exceptions Timing (Cont.)
Ludovic Apvrille
52 of 75
Exceptions Timing: Cutting ISRs in Two Parts
Ludovic Apvrille
Figure: The caption
53 of 75
Conclusion on ISRs
Benets about cutting ISRs in two parts

Lower priority interrupts can be handled Reduces the chance of missing interrupts Increase concurrency because devices can start working on next operations earlier
General guide for implementing ISRs

An ISR should disable interrupts of the same level An ISR should mask all interrupts if it needs to execute a sequence of code as one atomic operation An ISR should avoid calling non-reentrant functions and blocking system calls
Timer and Timer Services

Use of Timers
Applications often have to perform jobs after a given delay has elapsed
Programmable Interval Timers (PIT)
Ludovic Apvrille
55 of 75
Initialization of the Timer Chip

Resetting and bringing the timer chip into a known hardware state Calculating the proper value to obtain the desired timer interrupt frequency and programming this value into the appropriate timer control register Programming the timer chip with the proper mode of operation Installing the timer interrupt service routine into the system Enabling the timer interrupt
Ludovic Apvrille
56 of 75
Timer Interrupt Service Routine
Updating the system clock

Absolute time (calendar) Elapsed time (since power up)
Calling a registered kernel function to notify the occurrence of a pre-programmed period
announce time tick ()
Calls the Scheduler and the Soft-timer facility
Acknowledging the interrupt, reinitializing the necessary timer control register and returning from interrupt
Ludovic Apvrille
57 of 75
Steps in Servicing Timer Interrupt
Ludovic Apvrille
58 of 75
Implementing the Soft-Timer Handling Facility

Goal

Allowing applications to start a timer Allowing applications to stop or cancel a previously installed timer Internally maintaining the application timers
Implementation: timer ISR

The timer ISR should be as fast as possible to avoid missing next timer interrupts
Ludovic Apvrille
59 of 75
Inaccuracy Due to Processing Delays
ISR triggers asynchronous events to signal a task of the expiration of its timer
E.g., sending of a message, release of a semaphore
Task scheduling delay, context switch Higher priority task may be running
Ludovic Apvrille
60 of 75
Soft-Timer Services
timer create ()

Allocates a new structure for a timer Inputs: expiration time, function to be called at timer expiration Returns: id of the timer
timer delete ()

Structure of the timer is removed from memory Input: id of the timer
Ludovic Apvrille
61 of 75
Soft Timer Services (Cont.)

timer start ()
Starts a previously created timer: a timer structure is installed into the timer-handling facility Input: id of the timer
timer cancel ()
Cancels a timer by removing the currently running timer from the timer-handling facility Input: id of the timer
Access to the real-time clock

clock get time () clock set time ()
Towards real-time Unix Scheduling issues Linux for real-time systems
Outline
Embedded Systems in a Nutshell Real-time Systems in a Nutshell Real-Time Operating Systems Real-Time UNIX Towards real-time Unix Scheduling issues Linux for real-time systems
Ludovic Apvrille
63 of 75
Limitations of UNIX for RT Systems

Time-sharing based scheduling Services are not always reentrant Blocking input / output operations Timing issues

Time accuracy Precision of timer
Heavy management of IPC induces non-determinism in computing time Large memory footprint Reduced set of booting devices
Ludovic Apvrille
64 of 75
Towards Real-Time UNIX

Preemptive kernel Fully reentrant libraries Enhanced schedulers
Real-time classes Faster switching Increased modularity (Micro-kernels) Support of the POSIX interface
Introduction of threads
Enhancement at architecture level
Add-on of real-time services within UNIX kernels
Ludovic Apvrille
65 of 75
Preemption Latency in a Priority-Based System
Ludovic Apvrille
66 of 75
Preemption Points
Adding preemption points in the kernel
Dene a slice of time during which no preemption is allowed (e.g., 2,000 instructions) Rewrite all kernel primitives:
The duration during which no preemption is allowed must always be shorter than the dened slice of instructions After each slice, call the scheduler (just in case) Fully preemptive kernel (see next slides)
Limitation: Dening the slice is not obvious

Too long average preemption latency is higher Too short important overhead
Reentrant Runtime Libraries

Issue
Libraries oer services such as: Input / Output operations, dynamic memory allocations, etc. Services may have an internal state: buer (I/O), pointer to the next chunk of free memory, etc. If preemption occurs when a service is being called, internal state of the service may be corrupted
Solutions
Protection at application level: mutex, semaphore, etc.
Safe, but costly Safe, less costly (but more costly than non-reentrant librairies)
Use a reentrant version of the library (if available)
Using Open Source OS for Embedded Systems
No royalties when distributing the embedded system Source code is available

Maintenance can be performed for as long as desired Systems can be built from this source code
Ludovic Apvrille
69 of 75
Limitations of Linux for Real-Time Systems
Time-sharing system
Interactivity-based scheduling: strict priority-based approach is needed in real-time systems! Preemption is not possible When executing a system call (so, interrupts may be missed!) When executing an ISR
Long code sections where all external events are masked
Kernel cannot be preempted

Virtual memory management Device management Partial support for POSIX.4
Ludovic Apvrille
70 of 75
Towards a Linux for Real-Time Systems
Introducing a real-time scheduler
Patch Modules
Modifying the kernel
Ludovic Apvrille
71 of 75
Introducing a Real-Time Scheduler (Patch)

Patchs are said to be preemptive

Kernels latency is reduced Limited to soft real-time systems
Preempt Kernel
Low Latency
Based on call to the scheduler whenever possible Kernels data are protected with mutex
Adds preemption points at carefully chosen places in the code Approach is less systematic Performance study demonstrates its eciency with regards to the Preempt kernel patch
Real-Time Operating Systems - Fall 2012 72 of 75
Ludovic Apvrille
Modifying the Kernel (Modules)

Basic idea: the Linux kernel will never be real-time
Another scheduler is added to the kernel

Priority-based scheduling policy Non real-time tasks are scheduled by the default Linux scheduler Real-time tasks are programmed as linux kernel modules
Hard real-time system
Two main implementations

RTAI (http://www.rtai.org/) RTLinux (FSMLabs)
Ludovic Apvrille
73 of 75
Architecture of the Linux Kernel
Ludovic Apvrille
Figure: The caption
74 of 75
Architecture of RTAI
Ludovic Apvrille
Figure: The caption
75 of 75

Courser To S

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Courser To S

Hochgeladen von

Copyright:

Verfügbare Formate

Real-Time Operating Systems

Real-Time Operating Systems - Fall 2012

What is an Embedded System?

Computer system designed for specic purpose

Tightly coupled hardware and software integration

An embedding system may include several embedded systems

PC vs. embedded systems

PC: general-purpose microprocessor and OS

High power consumption, heat production, large size Dedicated system

Dedicated hardware (e.g., DSPs) and software

Constraints of consumption, heat, size, performance, price, . . .

A Few Characteristics of Embedded Systems

Various execution modes

Highly Available Systems

Number of 9s 3 Nines (99.9%) 4 Nines (99.99%) 5 Nines (99.999%) 6 Nines (99.9999%)

Downtime per year 9h 1h 5mn 30s

Typical application Desktop Enterprise server Carrier-class server Carrier-switch equipment

Real-Time Operating Systems - Fall 2012

A Few Characteristics of Embedded Systems (Cont.)

Memory size is small with regards to PCs Reduced computation power

Real-Time Operating Systems - Fall 2012

Real-Time Operating Systems - Fall 2012

Response to External Events

Real-Time Operating Systems - Fall 2012

Example of Embedded Systems

Real-Time Operating Systems - Fall 2012

Typical Cross-Platform Environment for the Development of Embedded Systems

Real-Time Operating Systems - Fall 2012

View of the Target Embedded System

Real-Time Operating Systems - Fall 2012

Embedded Systems Initialization

Real-Time Operating Systems - Fall 2012

Embedded Systems Initialization (Cont.)

Starting execution at the reset vector

Code located at a predened and hard-wired address location

Putting the processor in a known state by setting the appropriate registers

Getting processors type Getting or setting CPUs clock speed

Real-Time Operating Systems - Fall 2012

Embedded Systems Initialization (Cont.)

Copying and decompressing early code and data into RAM

Low-level assembly language specic to the target architecture

Executing boot code initializing other hardware components

All the boot code is known as BSP (Board Support Package)

Real-Time Operating Systems - Fall 2012

Uses serial line

On-Chip Debugging (OCD) = built-in microprocessor debugging capabilities

OCD-aware host debugger displays information such as

Real-Time Operating Systems - Fall 2012

Denition Examples of real-time and embedded systems

Real-Time Operating Systems - Fall 2012

Denition Examples of real-time and embedded systems

What is a Real-Time System?

Real-Time Operating Systems - Fall 2012

Denition Examples of real-time and embedded systems

What is a Real-Time System? (Cont.)

It reacts to external stimuli

System interacting with its environment

WCET = Worst Case Execution Time Timing correctness

Vs. usual systems

Only logical correctness Manage the average case

Denition Examples of real-time and embedded systems

Response to External Events

Real-Time Operating Systems - Fall 2012