courser to s

7/29/2019 Courser to s

1/38

Real-Time Operating Systems

Ludovic Apvrille

Telecom ParisTech

Eurecom, Office 470

[email protected]

Fall 2012

Outline

Embedded Systems in a NutshellIntroductionArchitecture

Real-time Systems in a NutshellDefinitionExamples of real-time and embedded systems

Real-Time Operating SystemsBasicsAdvanced concepts

Exceptions and interruptsTimers

Real-Time UNIXTowards real-time UnixScheduling issuesLinux for real-time systems


2/38

Embedded Systems in a NutshellReal-time Systems in a Nutshell

Real-Time Operating SystemsReal-Time UNIX

IntroductionArchitecture

Outline

Embedded Systems in a NutshellIntroduction

Architecture

Real-time Systems in a Nutshell


Real-Time UNIX

Ludovic Apvrille Real-Time Operating Systems - Fall 2012 3 of 75




What is an Embedded System?

Definitions Computer system designed for specific 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

Embedded system Dedicated system

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

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



3/38




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, fire, water, radiations, etc.

Criticality

Failures may have major consequences

The system should always perform correctly! Hardware level: for example, a specification could be that the

system should continue to work even if an electroniccomponent fails (redundancy)

Safety at software level: e.g., handling of possible bugs andcrash

Various execution modesLudovic Apvrille Real-Time Operating Systems - Fall 2012 5 of 75




Highly Available Systems

Number of 9s Downtime per year Typical application

3 Nines (99.9%) 9h Desktop4 Nines (99.99%) 1h Enterprise server5 Nines (99.999%) 5mn Carrier-class server6 Nines (99.9999%) 30s Carrier-switch equipment

Source: Providing Open Architecture High Availability solutions, Revision

1.0, Published by HA Forum, Feb. 2001



4/38




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)





High-level Architecture

Embedded system = controlling system + controlled system +environment



5/38




Response to External Events





Example of Embedded Systems



6/38




Typical Cross-Platform Environment for the Developmentof Embedded Systems





View of the Target Embedded System



7/38




Embedded Systems Initialization





Embedded Systems Initialization (Cont.)

Starting execution at the reset vector Code located at a predefined and hard-wired address location

Putting the processor in a known state by setting theappropriate 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



8/38




Embedded Systems Initialization (Cont.)

Copying and decompressing early code and data into RAM

Low-level assembly language specific 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)





Debugging

ROM Monitor Uses serial line

On-Chip Debugging (OCD) = built-in microprocessordebugging capabilities

BDM - Background Debug Mode JTAG - Joint Test Action Group No need for underlying software support on chip

OCD-aware host debugger displays information such as Content of processor registers System memory dump Instruction under execution



9/38



DefinitionExamples of real-time and embedded systems

Outline

Embedded Systems in a Nutshell

Real-time Systems in a NutshellDefinitionExamples of real-time and embedded systems


Real-Time UNIX





What is a Real-Time System?

Real-Time Systems have been defined as:

Those systems in which the correctness of thesystem depends not only on the logical results ofthe computation, but also on the time at which theresults are produced

(J. Stankovic, Misconceptions About Real-Time Computing,

IEEE Computer, 21(10), October 1988)



10/38




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 effort





Response to External Events



11/38




Jobs and Tasks

Definition 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 withperiod = 30ms

Functional: intrinsic properties of the job (e.g., taps of filter)

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.Ludovic Apvrille Real-Time Operating Systems - Fall 2012 21 of 75




Time Constraints

Time constraint = Constraint imposed on the timing behaviorof 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

Difference between the completion time and the release timeof a job



12/38




System Latency

System latency = End-to-end delay between a change ofstate in the environment, and the corresponding outputreaction produced by the system

Latency involves: delay for scanning the environment, delaydue to the OS, delay for executing calculations, delay forproducing output results (communication delay)

Jitter = incertitude ondelays

Load of the system,etc.

Should be low withregards to the latency





Determinism Issue

Computing time Each activity can use various execution branches

Communication time Status of messages queues, delay of signals, etc.

Interrupts Software or hardware exceptions



13/38




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 Soft system

1 Zero tolerance Non-zero

2 Useless Not zero right after passing deadline

3 Catastrophic Non-catastrophic

Complex real-time and embedded systems

A complex real-time and embedded system is commonly a mix of

hard and soft subsystemsLudovic Apvrille Real-Time Operating Systems - Fall 2012 25 of 75




Example 1: A GSM Phone

Specification

Software is in charge Of some operations performed at physical level (receiving,

sending, measuring the level of the electromagnetic field, etc.) Of logical operations such as scanning for incoming calls,

maintaining connections when changing of beams, etc.

Sending and receiving voice data is a critical task 577s of voice data are transmitted every 4.6ms 577s of voice data are received every 4.6ms

Management of the mobility issue If the distance to the relay is increasing, data should be emitted

earlier to remain synchronized with the relay (Doppler effect)



14/38




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 atemporal dimension: sound, video and animations

Quality of Service (QoS)

Fundamental issue!

Use of synchronization techniques



15/38




Example 2: A Multimedia System (Cont.)





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 operatingsystems?



16/38



BasicsAdvanced conceptsExceptions and interruptsTimers

Outline



Real-Time Operating SystemsBasicsAdvanced conceptsExceptions and interruptsTimers

Real-Time UNIX





Limitations of General-Purpose OS for Real-Time Systems

Scheduling policies share CPUs in fair way They dont takeinto account temporal constraints

Communication mechanisms introduce non-deterministictemporal 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 fine-grained

enough

Use of a Real-Time Operating Systems



17/38




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





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-specific requirements

Modular components

File systems, protocol stacks, etc.



18/38




Target System Software Initialization Sequence





Examples of RTOS

VxWorks

LynuxWorks

QNX

Windows Phone, iOS, Symbian

Linux for RT and embedded systems

CLinux RTLinux RTAI Android



19/38




Developing an Application for VxWorks with Tornado





Debuging Using WindView



20/38




Scheduling

Limitations of schedulers in general-purpose OS

Schedulers are defined 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





Memory Management

Dynamic allocations

Should be avoided at run-time

Algorithms are based on fixed-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



21/38




Input / Output Management

Limitations for RT systems

Difficult or impossible to bound the time to perform an I/Ooperation

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.





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 predefined maximum size and withpre-allocated messages



22/38




Exceptions and Interrupts

Exceptions

Events that disrupt the normal execution flow of the processorand force the processor to execute special instructions in aprivileged state

Synchronous exceptions Divide by zero

Asynchronous exceptions Pushing the reset button of the embedded system

Interrupts

= Asynchronous exceptions triggered by events externalhardware devices generate





Programmable Interrupt Controller

Hardware-implemented

Prioritizing multiple interrupt sources so that at any time thehighest priority interrupt is presented to the core CPU forprocessing

PICs have a set of Interrupt Request Lines Interrupt = physical signal on a given line

Handlers specified at PIC level ESR = Exception Service Routine ISR = Interrupt Service Routine



23/38




Programmable Interrupt Controller (Cont.)





Programmable Interrupt Controller: Example

Source Priority VectorAddress

IRQ Maxfreq.

Description

Airbagsensor

Highest 14h 8 N/A Detects theneed to deployairbags

Brakesensor

High 18h 7 N/A Informs aboutthe current

braking powerFuelLevelSensor

Med 1Bh 6 20Hz Detects thelevel of fuel

RTC Low 1Dh 5 100Hz Clock runs at10ms tick



24/38




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 additionalinterrupts

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





Classification of Exceptions

Asynchronous

Non-maskableCannot be blocked or enabled bysoftware

MaskableCan be blocked or enabled bysoftware

Synchronous

Precise Program counter points to

the exact instruction whichcaused the exception(Offending instruction)

Processor knows where toresume the execution

Non-preciseBecause of prefetching andpipelining techniques, noknowledge about the exactinstruction that caused theexception



25/38




General Exceptions Priorities





Nested Interrupts



26/38




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 thisinformation

Should take into account the fact that real-time tasks cannotexecute when interrupts are being processed





Exceptions Timing (Cont.)



27/38




Exceptions Timing: Cutting ISRs in Two Parts





Conclusion on ISRs

Benefits 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 onnext 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 asequence of code as one atomic operation

An ISR should avoid calling non-reentrant functions andblocking system calls



28/38




Timer and Timer Services

Use of Timers

Applications often have to perform jobs after a given delay has

elapsed

Programmable Interval Timers (PIT)





Initialization of the Timer Chip

Resetting and bringing the timer chip into a known hardwarestate

Calculating the proper value to obtain the desired timerinterrupt frequency and programming this value into theappropriate timer control register

Programming the timer chip with the proper mode ofoperation

Installing the timer interrupt service routine into the system

Enabling the timer interrupt



29/38




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 ofa pre-programmed period

announce time tick() Calls the Scheduler and the Soft-timer facility

Acknowledging the interrupt, reinitializing the necessary timercontrol register and returning from interrupt





Steps in Servicing Timer Interrupt



30/38




Implementing the Soft-Timer Handling Facility

Goal Allowing applications to start a timer

Allowing applications to stop or cancel a previously installedtimer

Internally maintaining the application timers

Implementation: timer ISR

The timer ISR should be as fast as possible to avoid missing nexttimer interrupts





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



31/38




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





Soft Timer Services (Cont.)

timer start()

Starts a previously created timer: a timer structure is installedinto the timer-handling facility


timer cancel()

Cancels a timer by removing the currently running timer fromthe timer-handling facility


Access to the real-time clock

clock get time() clock set time()



32/38



Towards real-time UnixScheduling issuesLinux for real-time systems

Outline




Real-Time UNIXTowards real-time UnixScheduling issuesLinux for real-time systems





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 incomputing time

Large memory footprint

Reduced set of booting devices



33/38




Towards Real-Time UNIX

Preemptive kernel

Fully reentrant libraries

Enhanced schedulers Real-time classes

Introduction of threads Faster switching

Enhancement at architecture level Increased modularity (Micro-kernels)

Add-on of real-time services within UNIX kernels Support of the POSIX interface





Preemption Latency in a Priority-Based System



34/38




Preemption Points

Adding preemption points in the kernel

Define 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 defined slice of instructions After each slice, call the scheduler (just in case) Fully preemptive kernel (see next slides)

Limitation: Defining the slice is not obvious

Too long average preemption latency is higher

Too short important overhead





Reentrant Runtime Libraries

Issue Libraries offer services such as: Input / Output operations,

dynamic memory allocations, etc.

Services may have an internal state: buffer (I/O), pointer tothe next chunk of free memory, etc.

If preemption occurs when a service is being called, internalstate of the service may be corrupted

Solutions Protection at application level: mutex, semaphore, etc.

Safe, but costly

Use a reentrant version of the library (if available) Safe, less costly (but more costly than non-reentrant librairies)



35/38




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





Limitations of Linux for Real-Time Systems

Time-sharing system Interactivity-based scheduling: strict priority-based approach is

needed in real-time systems!

Long code sections where all external events are masked Preemption is not possible

Kernel cannot be preempted When executing a system call (so, interrupts may be missed!) When executing an ISR

Virtual memory management

Device management

Partial support for POSIX.4



36/38




Towards a Linux for Real-Time Systems

Introducing a real-time scheduler Patch

Modifying the kernel Modules





Introducing a Real-Time Scheduler (Patch)

Patchs are said to be preemptive

Kernels latency is reduced

Limited to soft real-time systems

Preempt Kernel

Based on call to thescheduler wheneverpossible

Kernels data areprotected with mutex

Low Latency

Adds preemption points at carefullychosen places in the code

Approach is less systematic

Performance study demonstratesits efficiency with regards to thePreempt kernel patch



37/38




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)





Architecture of the Linux Kernel



38/38




Architecture of RTAI


courser to s

Documents