CENG-336 Introduction to Embedded Systems Development

CENG-336 Introduction to Embedded Systems Development
RTOS – Real-time Operating Systems

What is Real Time? “A real time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred.” - Donald Gillies 2

Real Time System A system is said to be Real Time if it is required to complete it’s work & deliver it’s services on time. Example – Flight Control System All tasks in that system must execute on time. Non Example – PC system CENG-336

Soft Real Time Systems In a soft real-time system, it is considered undesirable, but not catastrophic, if deadlines are occasionally missed. Also known as “best effort” systems Most modern operating systems can serve as the base for a soft real time systems. Examples: multimedia transmission and reception, networking, telecom (cellular) networks, web sites and services computer games online databases CENG-336

Hard Real Time Systems air traffic control vehicle subsystems control
A hard real-time system has time-critical deadlines that must be met; otherwise a catastrophic system failure can occur. Absolutely, positively, first time every time Requires formal verification/guarantees of being to always meet its hard deadlines (except for fatal errors). Examples: air traffic control vehicle subsystems control Nuclear power plant control CENG-336

Hard and Soft Real Time Systems (Operational Definition)
Hard Real Time System Validation by provably correct procedures or extensive simulation that the system always meets the timings constraints Soft Real Time System Demonstration of jobs meeting some statistical constraints suffices. Example – Multimedia System 25 frames per second on an average CENG-336

What is an operating system?
An organized collection of software extensions of hardware that serve as... control routines for operating a computer (for example, to gain access to computer resources (like file I/O)) an environment for execution of programs CENG-336

CENG-336

Role of an OS in Real Time Systems
Standalone Applications Often no OS involved Micro controller based Embedded Systems Some Real Time Applications are huge & complex Multiple threads Complicated Synchronization Requirements Filesystem / Network / Windowing support OS primitives reduce the software design time CENG-336

What is Real Time OS? “Real time in operating systems: The ability of the operating system to provide a required level of service in a bounded response time.” - POSIX Standard 10

Real-Time Operating System
An RTOS is an OS for response time- controlled and event-controlled processes. It is very essential for large scale embedded systems. CENG-336

When is RTOS necessary? Software for a large number of small-scale embedded system use no RTOS and these functions are incorporated into the application software. For small-scaled systems, RTOS’s function can be replaced by C. For example, instead of the memory allocation and de-allocation functions of RTOS, the C function , malloc and free can be used. Software can directly handle inter-process communication CENG-336

When is RTOS necessary? However, RTOS is essential when…
A common and effective way of handling of the hardware source calls from the interrupts I/O management with devices becomes simple using an RTOS Effectively scheduling and running and blocking of the tasks in cases of many tasks In conclusion, an RTOS may not be necessary in a small-scaled embedded system. An RTOS is necessary when scheduling of multiple processes and devices is important. CENG-336

Three key requirements:
The timing behavior of the OS must be predictable. ∀ services of the OS: Upper bound on the execution time! RTOSs must be deterministic: unlike standard Java, short times during which interrupts are disabled, almost all activities are controlled by scheduler. 14

3. OS must be fast 2. OS must manage the timing and scheduling
OS possibly has to be aware of task deadlines; (unless scheduling is done off-line) OS must provide precise time services with high resolution. 3. OS must be fast Practically important. 15

Features of RTOS’s Scheduling. Resource Allocation.
Interrupt Handling. Other issues like kernel size. CENG-336

RTOS – Real-time Operating Systems Based on Lecture Notes by Tuna Tuğcu

Three Central Concepts
Concurrency – several concurrent threads of execution Reactivity – external input is reacted to rather than requested Real time – timing behavior of reactions is important CENG-336 Introduction to Embedded Systems Development 18

Computer science:: concurrency
Concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. Computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors. A number of mathematical models have been developed for general concurrent computation CENG-336

Introduction to Embedded Systems Development
Concurrency For cost effectiveness, we should map many tasks onto fewer processors (resource sharing) For independent tasks, concurrency is trivial. We are interested in tasks that are cooperating CENG-336 Introduction to Embedded Systems Development 20

Reactivity The active view: the environment (user) acts because the program demands it (traditional programming) The reactive view: the program acts because the environment (”user”) demands it (embedded systems) CENG-336 Introduction to Embedded Systems Development 21

Computer system classification
Transformational systems compute output values from input values, then stop. numerical computations, compiler Interactive systems constantly interact with their environment. The system delivers a service to the user. operating systems, databases Reactive systems continuously react to stimuli from the environment. Reaction time is dictated by the environment. signal processors, process controllers CENG-336

Real Time Someone asks about the current outdoor temperature. Which response is better? A correct reading of 20°C delivered 12 hours later A false reading of 10°C delivered immediately In a real time system, a “late” response is just as bad as a wrong one Methods and models for controlling the timing behavior of programs, in addition to their functionality CENG-336 Introduction to Embedded Systems Development 23

Some Horror Stories CENG-336 Introduction to Embedded Systems Development

Goals To give some examples of real real- time systems that have actually been produced To illustrate various ways that the concept of time may affect system design To warn about the consequences of bad real time system design! To motivate programmers to do better! CENG-336 Introduction to Embedded Systems Development

Apollo 11 Lunar Landing Basic facts: First manned lunar landing (July 20, 1969) A small 2-person spacecraft descended to the lunar surface, while mothership stayed in lunar orbit Both spacecrafts equipped with a computer for navigation and guidance (notice the time & space): 100 kHz 16-bit CPU 38K RAM & core memory programmed in assembly language priority-based event-driven OS of 2K CENG-336 Introduction to Embedded Systems Development

Apollo 11 Lunar Landing (cont’d)
During the landing phase, the role of the lunar lander computer was to measure altitude and control the overall attitude of the spacecraft In the middle of descent, with only minutes to go before landing, the computer started to display “1202 alarm” This alarm kept repeating itself every 10 seconds As the minimum altitude for aborting was approaching, the software engineers had to decide whether the alarm was fatal or not The advice was to ignore the alarm, and the landing also proceeded successfully CENG-336 Introduction to Embedded Systems Development

Problem: Computer too slow to handle all tasks concurrently CENG-336 Introduction to Embedded Systems Development

Solution: During descent (landing) CENG-336 Introduction to Embedded Systems Development

Solution: During ascent (take-off) CENG-336 Introduction to Embedded Systems Development

Cause of the alarms Descent (landing) consequence #1: event buffer overflow every 10s consequence #2: about 20% of the CPU cycles spent in the rendezvous radar interrupt handler CENG-336 Introduction to Embedded Systems Development

The engineers knew “1202 alarm” meant overflow of some event buffer, not clear which one However, because of the fixed priorities used, judgment was that whatever events and computations being lost, they would be the least important ones The decision to ignore the alarms was taken on basis of that “gut feeling” (instinctive feeling about a given situation) rather than knowledge Analysis and simulations during the 24h moon stay found the exact alarm cause (the erroneous switch) (The engineer in charge of the decision to proceed was later awarded the President’s Medal together with the astronauts!) CENG-336 Introduction to Embedded Systems Development

Therac-25 The Therac-25 was a computer that controlled therapeutic radiation machine for the treatment of tumors Deployed in the mid 80’s, it was a modernized successor to a highly successful, but slow and bulky machine: the “Therac-20” Massive radiation overdoses generated by the machine resulted in deaths or severe injuries for at least six people in the USA and Canada ( ) The machine was redesigned in 1987 as the result of multiple federal investigations CENG-336 Introduction to Embedded Systems Development

Therac-25 (cont’d) CENG-336 Introduction to Embedded Systems Development

Therac-25 (cont’d) DEC PDP-11 responsible for Scanning operator input Positioning the turntable with the tungsten shield Setting up the electron gun, bending magnets, and various other devices Performing treatment timing Executing extensive safety checks Controlled via an ASCII-based terminal in a remote room, using cursor keys for moving between input fields CENG-336 Introduction to Embedded Systems Development

Therac-25 (cont’d) CENG-336 Introduction to Embedded Systems Development

Therac-25 (cont’d) Accident cause: The operator erroneously enters X-ray mode, realizes the mistake, and switches back to electron mode – all within 8 seconds During that time window, the treatment phase task is ignoring the keyboard entry flag because it is delaying in a busy-wait loop while bending magnets are being set up Thus, the new mode is never copied over to the variable read by the gun emission control task The other tasks register the edit, though, so the turntable is moved and the screen updated accordingly This results in the patient being exposed to unshielded, high energy radiation, with no indication to the operator CENG-336 Introduction to Embedded Systems Development

Therac-25 (cont’d) The Therac-25 software was written in assembly language by a single person, who also wrote the context-switching “kernel” Few people seem to have had any clear idea of how the software really worked Safety analyses for the machine never took timing errors into account It turned out that the Therac-20 also contained the same bugs, but the hardware sensors and fuses were used as an extra safety net against high radiation CENG-336 Introduction to Embedded Systems Development

Mars Pathfinder Unmanned spacecraft that landed on Mars in 1997 Famous for its high-resolution panoramic pictures of the Mars surface Also famous for utilizing balloons in a “bouncing” landing procedure, and for deploying a surface vehicle on wheels Not so well-known: Severe computer problems on the Pathfinder that resulted in frequent system resets and loss of data The cause: A classical example of priority inversion CENG-336 Introduction to Embedded Systems Development

Mars Pathfinder (cont’d)
CENG-336 Introduction to Embedded Systems Development

Mars Pathfinder (cont’d)
The Pathfinder software ran under the VxWorks RTOS VxWorks can be run with a tracing option, which records every activity within in the kernel During simulations on an exact replica of the Pathfinder, engineers were able to reproduce the resets, and the problem was identified Fortunately, a C interpreter had been left in the Pathfinder’s version of VxWorks, and a fix could be uploaded that turned on priority inheritance for the info bus mutex The mutex in question was actually hidden within a higher-level synchronization construct, that didn’t offer any priority inheritance option! CENG-336 Introduction to Embedded Systems Development

Ariene-5 Blow-up Launch of Ariane-5 took place in French Guyana (June 4, 1996) The rocket contained a fairly sophisticated, fault tolerant computer system, with software written in Ada About 40 seconds after take-off, the rocket self-destructed at an altitude of approximately 4000 meters Telemetry data, and memory readouts from computer units recovered from the debris enabled identification of the cause of events at a high level of detail CENG-336 Introduction to Embedded Systems Development

Ariene-5 Blow-up (cont’d)

The rocket started to disintegrate at 39s after liftoff, which caused automatic self-destruction Disintegration was the result of an angle-of-attack of more than 20°, which in turn was caused by full nozzle deflections on all engines Nozzle deflections were commanded by the OBC software on basis of data transmitted by SRI2 SRI2 was actually not transmitting inertial data, but bit-patterns corresponding to debug information SRI2 had aborted because of an unhandled floating- point exception, and so had SRI1 one cycle earlier CENG-336 Introduction to Embedded Systems Development

The FP exception was due to an error fitting a 64-bit floating-point value into a 16-bit integer Exception handling for this conversion had been turned off in order to squeeze CPU utilization below 80% (as dictated by RM analysis) The unexpected value occurred in a task used for guiding the rocket while still at the launch pad This task was left running for 40s after lift-off, due to extra time allocated in case of short pauses during countdown (to avoid realigning the gyros) The analysis that outruled exceptional values for the variable after lift-off was most likely based on trajectory data for Ariane-4! CENG-336 Introduction to Embedded Systems Development

Conclusions If something can go wrong in a real-time concurrent system, it will eventually go wrong Because of the time dimension, the argument “It works now” has little value for a real-time system Correctness of a real-time system should ideally be established by some form of software verification, with clearly stated assumptions The problem is “This is easier said than done” with current technology Extensive testing can find many errors, but never give full correctness guarantees We, as programmers, can help by choosing program structures that are clearly correct by construction CENG-336 Introduction to Embedded Systems Development

RTOS – Realtime Operating Systems

What’s an Operating System?
Properties of a generic OS: Provides environment for executing programs Process abstraction for multitasking / concurrency Scheduling Hardware abstraction layer (device drivers) File systems Communication CENG-336 Introduction to Embedded Systems Development

Do I Need One? Not always (e.g., if you wish to control the processor behaviour with your own code; like in PIC) Simplest approach: “cyclic executive” loop do part of task 1 do part of task 2 do part of task 3 ... end loop CENG-336 Introduction to Embedded Systems Development

Cyclic Executive (CE) Advantages Simple implementation Low overhead Very predictable Disadvantages Can’t handle sporadic events (occuring by chance no reason or cause can be identified, exhibiting random behavior; patternless) Everything must operate in lockstep Code must be scheduled manually CENG-336 Introduction to Embedded Systems Development

Agenda Managing Real Time tasks Embedded OS Kernels RTOS scheduler CENG-336 Introduction to Embedded Systems Development

Managing Real Time tasks - Foreground/Background
The background is a single loop which executes forever, calling subroutines to do application-specific jobs. The foreground consists of interrupt service routines (ISRs) called by asynchronous events such as a clock tick or the arrival of a byte at a communications port. The processor pauses executing the background loop in order to service an interrupt. Interrupts may be prioritised, so that an ISR may itself be interrupted so that a more important event may be serviced. Background ISR ISR Foreground ISR (more important) CENG-336 Introduction to Embedded Systems Development

Managing Real Time tasks ...
OK for simple real time systems ISR processes briefly then returns. Typically just gets data from interrupting device and defers it for “substantial” processing to a task in the background loop. Memory only as required by application(s). Minimal interrupt latency (time taken to break off from “current” task and service an interrupt). All tasks have same priority and are executed in sequence in the backgound loop eg (with reference to the diagram above): = check input from device 1 = monitor status of device 2 = do a computation = do output to device 2 CENG-336 Introduction to Embedded Systems Development

Cyclic Executive + Interrupts
Works fine for many signal processing applications Insanely cheap, predictable interrupt handler: When interrupt occurs, execute a single user- specified instruction This typically copies peripheral data into a circular buffer No context switch, no environment save, no delay CENG-336 Introduction to Embedded Systems Development

Drawbacks of CE + Interrupts
Main loop still running in lockstep Programmer responsible for scheduling Scheduling static Sporadic events handled slowly CENG-336 Introduction to Embedded Systems Development

Managing Real Time tasks ...
Application software must implement services such as Timeouts, time delays, messaging, communication between tasks resource management Typically, application software is in background while communications, timer management, etc. are in foreground. Code is hard to maintain as the application(s) develops/grows A better approach in general is to use a multitasking operating system kernel. CENG-336 Introduction to Embedded Systems Development

Managing Real-Time tasks ...
The kernel manages CPU time and other system resources required by various application tasks We are interested in multitasking kernels The “application software” consists of a number of tasks which can run concurrently. The tasks may have different priorities. Each task is (in general) triggered by an event in the environment of the software. A Kernel can be preemptive or non- preemptive... (explained later) CENG-336 Introduction to Embedded Systems Development

Why Operating Systems? The “first” computers had none Application software loaded into the RAM and ran on the hardware Embedded software was like this until surprisingly recently Not an efficient way to manage a desktop PC! Key presses, mouse events happen from time to time and have to be handled A byte may arrive at the serial port and have to be saved (MSN, GTalk, etc.) In general, a computer has many tasks on the go at once One or more (many) applications “house-keeping” – managing memory, disk drives, network interfaces, input & output devices CENG-336 Introduction to Embedded Systems Development

Why an Embedded OS? Demanding applications need access to system resources for a variety of some “strict” requirements: Critical applications with high functionality (flight control, medical applications..) Critical applications with low functionality (pace maker, Atomatic Brake System) Non-critical & technology-rich applications (telephones, smart card..) CENG-336 Introduction to Embedded Systems Development

Why not use another GP OS?
Kernel is typically feature rich (many unused functions) Not (modular, fault tolerant, fast, configurable, predictable,…) Takes big space (memory) Not power optimized Not designed for mission critical applications (scheduling). CENG-336 Introduction to Embedded Systems Development

Batch Operating Systems
Original computers ran in batch mode (transformational system): Submit job & its input Job runs to completion Collect output Submit next job Processor cycles very expensive at that time Jobs involved reading, writing data to/from tapes Cycles were being spent waiting for the tape! CENG-336 Introduction to Embedded Systems Development

Timesharing Operating Systems
Solution Store multiple batch jobs in memory at once When one is waiting for the tape, run the other one Basic idea of timesharing systems Fairness is the primary goal of timesharing schedulers Let no one process consume all the resources Make sure every process gets “equal” running time CENG-336 Introduction to Embedded Systems Development

Cooperative Multitasking
A cheap alternative Non-preemptive (no priorities) Processes responsible for relinquishing (giving up) control Examples: Original Windows, Macintosh A process had to periodically call get_next_event() to let other processes proceed Drawbacks: Programmer had to ensure this was called frequently An errant program would lock up the whole system Alternative: preemptive multitasking CENG-336 Introduction to Embedded Systems Development

Concurrency Provided by OS
Basic philosophy: Let the operating system handle scheduling, and let the programmer handle function Scheduling and function usually orthogonal Changing the algorithm would require a change in scheduling CENG-336 Introduction to Embedded Systems Development

Why OSs? ... What is needed (at the very least) – A scheduler managing several applications running at once Each application may get a few milliseconds of processing in turn At the and of a tasks turn with the CPU then it’s state (the values of the CPU registers, …) is saved the CPU registers are loaded with the next task’s state the next task gets a few milli-seconds processing We get the appearance/illusion of several tasks running at once An interrupt mechanism whereby an event in the environment (a key press, a byte arriving at the serial port …) causes the CPU to interrupt processing the current task, and need arises to service the interrupt, before resuming the task. An alternative might be to include in the schedule a task to poll all the peripherals but this would be much less efficient. Why? CENG-336 Introduction to Embedded Systems Development

Interrupts Some events can’t wait for next loop iteration Communication channels Transient events A solution: Cyclic executive plus interrupt routines Interrupt: environmental event that demands attention Example: “byte arrived” interrupt on serial channel Interrupt routine: piece of code executed in response to an interrupt CENG-336 Introduction to Embedded Systems Development

Handling an Interrupt 1. Normal program execution 2. Interrupt occurs 3. Processor state saved 4. Interrupt routine runs 6. Processor state restored 5. Interrupt routine terminates 7. Normal program execution resumes CENG-336 Introduction to Embedded Systems Development

Interrupt Service Routines
Most interrupt routines: Copy peripheral data into a buffer Indicate to other code that data has arrived Acknowledge the interrupt (signal the hardware) Longer reaction to interrupt performed outside interrupt routine E.g., causes a process to start or resume running CENG-336 Introduction to Embedded Systems Development

Why OSs? ... Also handy; provides Means of running tasks sending each other messages Means of arbitrating fair sharing of system resources between tasks Means of enforcing mutual exclusion where necessary These are all services provided by a modern operating system kernel So called to distinguish it from the command shell, a task which manages user input and output to/from the system In case of PCs, via a graphical “desktop” CENG-336 Introduction to Embedded Systems Development

Non-Preemptive Kernels
Low priority task ISR High priority task When a task relinquishes the CPU, the highest priority task in the list of tasks waiting for the CPU executes. But lower-priority task cannot lose the CPU to a higher-priority task until it is done. The higher priority task waits for the other to relinquish (withdraw) the CPU. The lower priority task can still be interrupted by an ISR; but it resumes processing after the ISR returns, and the higher priority task still only gets the CPU when the lower priority task has relinquished (withdrawn) it. A non-preemptive kernel can suffer from “priority inversion” problems, where a low-priority task can take a long time and lock out a more important higher priority task. CENG-336 Introduction to Embedded Systems Development

Preemptive Kernels Low priority task ISR High priority task In this case, a higher priority task can grab the CPU off the lower priority task as soon as it becomes ready to execute, before the lower priority task relinquishes it. The lower-priority task waits (among other tasks of equal priority) to resume. If the higher priority task becomes ready to run while an ISR (which interrupted the lower priority task) is executing, it gets the CPU on return from the ISR, and the lower priority task must wait for the higher one to relinquish the CPU before it can resume. CENG-336 Introduction to Embedded Systems Development

Tasks Each task thinks it has the CPU to itself Each task has its own stack space Each task has a priority A task may well take the form of a sequence of initialisation code; followed by a loop which iterates forever (or until a flag is set to exit it) Body of loop will contain application code A task calls functions which are preferably reentrant: Can be safely called by more than one function at a time Interrupting them does not corrupt their data Typically implemented using local variables Reusable and reentrant Code CENG-336 Introduction to Embedded Systems Development

Tasks ... A task passes through several states in its “life cycle”: When “born” it resides in memory “starting” tells the kernel its start address, address of stack top, priority; the kernel may pass run-time arguments to the task Once “ready”, it joins the prioritised queue of tasks waiting for CPU cycles. Under control of the kernel it will context-switch between the “running” state where it is receiving processing cycles and the “ready” state. CENG-336 Introduction to Embedded Systems Development

Tasks ... born (dormant) waiting/blocked event, timeout start wait, i/o request, etc. interrupted ISR task completion ready running context switch dead CENG-336 Introduction to Embedded Systems Development

Tasks ... Task states & “life cycle”: When running it may be forced to wait for a resource, a mutex another task to reach a certain stage (precedence) I/O (“blocked”) a time delay to expire, etc. Once the relevant event has occurred, the resource is available, a timeout has expired, etc., the task returns to the “ready” state. The running task may be interrupted by an ISR (as seen in previous slides, return may be followed immediately by a context switch.) CENG-336 Introduction to Embedded Systems Development

Scheduling & Context Switching
The scheduling task repeatedly decides whether there is a higher-priority task to run. This happens when ... a task has to wait for a time expiry or i/o or a mutex lock, etc a task sends a signal or message to another task an ISR sends a signal or message to a task (but after all nested ISR calls have returned). The result is either a context switch -- if a higher-priority task has become ready to run; or a return to the task interrupted by the scheduling task, otherwise CENG-336 Introduction to Embedded Systems Development

Scheduling & Context Switching
The context is the “dynamic state” of a task. It includes current values in CPU register, floating point register, memory management registers, etc. pointer to “current” TCB (Task Control Block) and/or Task-Id The switch causes these registers to be saved on the “old” task’s stack, and to be loaded from the “new” task’s stack. CENG-336 Introduction to Embedded Systems Development

Tasks and Threads A “multithreaded” program is one that is made up of concurrent tasks in a similar way to this. A thread is like a task, but part of a larger software entity, a program A “heavyweight” thread may have its own stack space, like a task, and some existence independent of its parent program. A “lightweight” thread may share stack space and other software resources with the parent program. A daemon is a thread which can carry on running after the parent has completed. (Normally a program is deemed to have finished when all its threads have finished.) CENG-336 Introduction to Embedded Systems Development

Tasks and Threads ... Threads have a life cycle similar to tasks as above In Java, for example, a Thread object has A run() method normally programmed with an infinite loop A sleep(int n) method to put the thread into a waiting state for n milliseconds A notify() method to fire an event to “wake up” a thread in a waiting state A yield() method to give up the CPU and return to the ready state. CENG-336 Introduction to Embedded Systems Development

Real-Time is “not Fair”
Main goal of an RTOS scheduler meeting deadlines If you have five concurrent homework assignments and only one is due in an hour, you work on that one. Wouldn’t you? Fairness does not help you meet deadlines! CENG-336 Introduction to Embedded Systems Development

OS for Embedded Systems
Configurable (eliminate unused functions) Direct control of devices by tasks (applications) is enabled: Standard OS : Real Time OS: Application Application Middleware Middleware Device Drivers Operating System Device Drivers Real Time Kernel * Kernel is the basic central part of an OS (no user interface etc.) Tasks are directly connected to interrupts CENG-336 Introduction to Embedded Systems Development

RTOS An OS that supports the construction of real time applications: Timing must be predictable (upper bound on execution time for all services) All activities are controlled by a scheduler Short times for disabled interrupts OS must manage timing and scheduling Aware of task deadlines Provide precision time services (timer mgmt.) OS must be fast CENG-336 Introduction to Embedded Systems Development

RTOS ... Mainly an OS (with scheduling and memory management) with “further” care Most of the Kernel resources are opened for access to the application CENG-336 Introduction to Embedded Systems Development

Typical RTOS Task Model
Each task is represented as a triplet: (execution time, period, deadline) Usually, deadline = period Can be initiated any time during the period Execution time Period Deadline Time Initiation CENG-336 Introduction to Embedded Systems Development

Real-Time Operating System (RTOS)
Most moderate and complex RT systems have RTOS. Some functions of RTOS are similar to normal OS: Managing interfaces to the low-level hardware. Scheduling and preempting tasks. Memory management. Providing common services: I/O, standard devices (keyboard, printer) Some functions of RTOS differ: Scalability. Scheduling policies and synchronization methods. Support for embedded, diskless target environment. RTOS is tailored and optimized for embedded systems. RTOS provides the ability to boot from ROM. Many RTOS can operate from ROM. CENG-336 Introduction to Embedded Systems Development

Scalability RTOS is structured so that only the needed components are included in the RTOS image executing on the target. Kernel: the innermost core, provides the most essential features of the RTOS. Other features are added as necessary. Scalability makes RTOS widely applicable to small, single-processor applications and to large, distributed ones. RTOS vendors call this as “microkernel” architecture, emphasizing the small size of the minimalist kernel. CENG-336 Introduction to Embedded Systems Development

Scheduling RTOS most commonly provides priority- based preemption for control of scheduling. The higher priority task always preempts the lower-priority tasks when the former becomes ready. Average performance is a secondary concern (fairness may be sacrificed also). The primary concern is that system meet all computational deadlines, even in the absolute worst case. CENG-336 Introduction to Embedded Systems Development

Priority-based Scheduling
Typical RTOS based on fixed-priority preemptive scheduler Assign each process a priority At any time, scheduler runs highest priority process ready to run Process runs to completion unless preempted CENG-336 Introduction to Embedded Systems Development

Priority-based Preemptive Scheduling
Always run the highest-priority runnable process 1 2 3 CENG-336 Introduction to Embedded Systems Development

Priority-Based Preemptive Scheduling
Multiple processes at the same priority level? A few solutions: Simply prohibit Each process has unique priority Time-slice processes at the same priority Extra context-switch overhead No starvation dangers at that level Processes at the same priority never preempt the other More efficient Still meets deadlines if possible CENG-336 Introduction to Embedded Systems Development

Rate-Monotonic Scheduling
RMS Common way to assign priorities Result from Liu & Layland, 1973 (JACM) Simple to understand and implement: Processes with shorter period given higher priority E.g., Period Priority (highest) (lowest) CENG-336 Introduction to Embedded Systems Development

Key RMS Result Rate-monotonic scheduling is optimal If there is fixed-priority schedule that meets all deadlines, then RMS will produce a feasible schedule However, task sets do not always have a schedule Simple example: (Exec Time, Period, Deadline) P1 = (10, 20, 20) / P2 = (5, 9, 9) Requires more than 100% processor utilization CENG-336 Introduction to Embedded Systems Development

RMS Missing a Deadline p1 = (10,20,20) p2 = (15,30,30) utilization is 100% 1 2 Would have met the deadline if p2 = (10,30,30), utilization reduced 83% P2 misses first deadline CENG-336 Introduction to Embedded Systems Development

When Is There an RMS Schedule?
Key metric is processor utilization: sum of compute time divided by period for each process: U =  (ci / pi) No schedule can possibly exist if U > 1 No processor can be running 110% of the time Fundamental result: RMS schedule always exists if U < n * (2 1/n – 1) Proof based on case analysis (P1 finishes before P2) CENG-336 Introduction to Embedded Systems Development

n Bound for U 1 100% Trivial: one process 2 83% Two process case 3 78% 4 76%  69% Asymptotic bound CENG-336 Introduction to Embedded Systems Development

Asymptotic result: If the required processor utilization is under 69%, RMS will give a valid schedule If the required processor utilization is over 69%, RMS might still give a valid schedule, but there is no guarantee Converse is not true. Instead: EDF CENG-336 Introduction to Embedded Systems Development

EDF Scheduling Earliest Deadline First (EDF) RMS assumes fixed priorities Can you do better with dynamically-chosen priorities? Earliest deadline first Processes with soonest deadline given highest priority CENG-336 Introduction to Embedded Systems Development

EDF Meeting a Deadline p1 = (10,20,20) p2 = (15,30,30) utilization is 100% 1 2 P2 takes priority because its deadline is sooner CENG-336 Introduction to Embedded Systems Development

Key EDF Results Earliest deadline first scheduling is optimal If a dynamic priority schedule exists, EDF will produce a feasible schedule Earliest deadline first scheduling is efficient A dynamic priority schedule exists if and only if utilization is no greater than 100% CENG-336 Introduction to Embedded Systems Development

Priority Inversion RMS and EDF assume no process interaction Often a gross oversimplification Consider the following scenario: 1 2 Process 1 tries to acquire lock for resource Process 1 preempts Process 2 Process 2 acquires lock on resource Process 2 begins running CENG-336 Introduction to Embedded Systems Development

Priority Inversion Lower-priority process effectively blocks a higher-priority one Lower-priority process’s ownership of lock prevents higher-priority process from running Nasty: makes high-priority process runtime unpredictable CENG-336 Introduction to Embedded Systems Development

Nastier Example Higher priority process blocked indefinitely Process 2 delays process 3’s release of lock 1 2 3 Process 1 tries to acquire lock and is blocked Process 1 preempts Process 2 Process 2 preempts Process 3 Process 3 acquires lock on resource Process 3 begins running CENG-336 Introduction to Embedded Systems Development

Priority Inheritance Solution to priority inversion Temporarily increase process’s priority when it acquires a lock Level to increase: highest priority of any process that might want to acquire same lock i.e., high enough to prevent it from being preempted Danger: Low-priority process acquires lock, gets high priority and hogs the processor So much for RMS CENG-336 Introduction to Embedded Systems Development

Priority Inheritance Basic rule: low-priority processes should acquire high-priority locks only briefly An example of why concurrent systems are so hard to analyze RMS gives a strong result No equivalent result when locks and priority inheritance is used CENG-336 Introduction to Embedded Systems Development

Summary Cyclic executive A way to avoid an RTOS Adding interrupts helps somewhat Interrupt handlers Gather data, acknowledge interrupt as quickly as possible Cooperative multitasking But programs don’t like to cooperate CENG-336 Introduction to Embedded Systems Development

Summary Preemptive Priority-Based Multitasking Deadlines, not fairness, the goal of RTOSes Rate-monotonic analysis/scheduling Shorter periods get higher priorities Guaranteed at 69% utilization, may work higher Earliest deadline first scheduling Dynamic priority scheme Optimal, guaranteed when utilization 100% or less CENG-336 Introduction to Embedded Systems Development

Summary Priority Inversion Low-priority process acquires lock, blocks higher-priority process Priority inheritance temporarily raises process priority Difficult to analyze CENG-336 Introduction to Embedded Systems Development

Priority Inversion Task 1 (high) Task 2 (medium) Task 3 (low) 1 2 3 4 5 6 This can happen even in Preemptive kernels. Eg: 3 task with low, medium, high priority: Task 3 (low) runs while 1 and 2 wait for some event. At point 1, 3 acquires an exclusive lock on a resource. At point 2, task 1 becomes ready and preempts task 3 At point 3, task 1 wants the resource but it is still locked by task 3; so task 1 waits and task 3 resumes At point 4, task 2 becomes ready and starts running, preempting task 3. Task 2 runs until done, point 5 and task 3 resumes, not task 1 because the latter is still waiting for the resource locked by task 3 Finally at point 6, task 3 releases the resource and task 1 acquires it and can run. Effectively task 1 has been trapped at the level of task 3 until 3 releases the resource. CENG-336 Introduction to Embedded Systems Development

Priority Inheritance - a Solution
Task 1 (high) Task 2 (medium) Task 3 (low) 1 2 3 4 5 6 In a kernel that supports priority inheritance, As soon as task 1 wants the resource (point 3) locked by task 3, task 3 is temporarily promoted to task 1’s priority so that it can continue running until it releases the resource (point 4) Then, task 1 becomes ready because it can acquire the resource released by task 3. Task 1 releases the resource at point 5, but keeps running also task 2 is ready, because it has the highest priority Finally at point 6, task 1 finishes and task 2 can run. Task 3, with the lowest priority, waits. NB Task 2 could have become ready at point 2 or any after thereafter, with no difference in outcome.. CENG-336 Introduction to Embedded Systems Development

Interrupts The kernel can always interrupt the currently running task except when kernel or application has disabled interrupts (by means of a system call) In effect, ISRs have “super-high” priority. They are prioritised among themselves and the ISR of a high-priority interrupt can interrupt the ISR of a lower one. “Software interrupts” are triggered by software -- usually in other tasks “System calls” “Hardware interrupts” are raised by, eg, interrupt request (IRQ) “lines” -- each is a bit in a CPU IRQ register. Setting bit n to 1 notifies the CPU that Interrupt number n has occurred. Each interrupt has a number. (low number -> high priority) which indexes into the Interrupt Vector Table -- an array of addresses of (pointers to) ISRs ISR must tell the kernel it is processing an interrupt could be interrupted by a higher priority ISR: Interrupts can be nested) tell the kernel is has finished processing an interrupt context switch or return to interrupted task CENG-336 Introduction to Embedded Systems Development

Interrupts -- the steps
A task is running; there is an interrupt requests If kernel has interrupts disabled, nothing happened until interrupts are enabled Then (or immediately) the kernel saves the task context looks up the ISR in the vector table The ISR runs notifies kernel of ISR entry processes -- possible signals another task notifies kernel of ISR exit If no higher priority task has become ready The original interrupted task’s context is restored and the task resumes If a higher-priority task has become ready The higher priority task’s context is restored and it resumes. The time interval from the interrupt request until the ISR starts is the interrupt response time. The time interval from the ISR exit to task resumption is the interrupt recovery time. (10s of s) CENG-336 Introduction to Embedded Systems Development

Clock Tick A piece hardware generates interrupts at a regular interval Hz; usually derived from power line frequency (Why 18.2 Hz in an 80x86 ?!?!?!?) Used to provide delays and timeouts The ISR for a clock tick calls a kernel service to signal a tick. This may well cause a context switch A higher priority task may have become ready to run in the interim In “round robin” scheduling, tasks of equal priority get a fixed number of ticks’ CPU time than go to the back of the queue The clock interrupt has higher priority than all tasks (because it is an interrupt) but lower priority than other interrupts. CENG-336 Introduction to Embedded Systems Development

Kernel Services The kernel provides services to task software time delays for n ticks task is placed in list of delayed tasks where consumes little on no CPU time. This list can also contain timeouts from other services. semaphores a mechanism for enforcing synchronisation and mutual exclusion see below message mailboxes and queues event flags pipes memory management a real-time clock change of task priority deletion of a task etc CENG-336 Introduction to Embedded Systems Development

Semaphores Invented by Edsger Dijkstra A simple mechanism for mutual exclusion and condition synchronisation Simple synchronisaton protocols No need for busy-wait loops A semaphore is a nonnegative integer variable only modifiable (apart from initialisation) by two procedures wait and signal. Dijkstra called these P and V Let s denote the semaphore variable, wait(s) { if (s > 0) decrement s by 1; else { wait until s > 0 } signal(s) { increment s by 1; } CENG-336 Introduction to Embedded Systems Development

Semaphores for Sync. Using a semaphore to synchronise a tasks on a condition task1 needs condition = true to proceed; task 2 is signalling process (see below) Assume semaphore variable consyn initialised to 0 When task 1 executes wait on a 0 semaphore, it will be delayed until task 2 executes the signal. This sets consyn to 1 and the wait can succeed. Task 1 can continue and consyn will be decrmeneted to 0 If task 2 executes signal first, consyn will = 1 and the wait() will will not delay task1. Task 1 could be a task requiring an exclusive lock on a resource; task 2 could signal on releasing the resource. task1 { .... wait(consyn); } task2 { ... signal(consyn); .... } CENG-336 Introduction to Embedded Systems Development

Semaphores for Mutual Exclusion
Using a semaphore for mutual exclusion Assume semaphore variable mutex set initially to 1. If the two tasks arer in contention they may execute their wait() statements simultaneously; but wait is atomic. One task will complete wait() before the other begins; So one will execute wait with mutex = 1 and so proceed to its critical section and set mutex to 0. The other will wait(mutex) with mutex = 0 and have to wait for the other task to signal(mutex) which it will do on leaving its critical section. More generally initially setting mutex to n will allow n simultaneous accesses to critical section task1 { while (...) { wait(mutex); /*critical section*/ signal(mutex); /*non-critical sect*/ } task2 { while (...) { wait(mutex); /*critical section*/ signal(mutex); /*non-critical sect*/ } CENG-336 Introduction to Embedded Systems Development

Message Queues & Events
We would like tasks to be able to communicate asynchronously Tasks to send and receive messages ISRs to send messages Discipline normally FIFO Events Tasks can be synchronised with occurrence of multiple events Occurrence of an event will signal a list of tasks; the highest-priority task of these will me made ready to run. CENG-336 Introduction to Embedded Systems Development

References Alan Burns & Andy Wellings, Real Time Systems & Programming Languages: Addison-Wesley Has a good section of semaphores -- section 8.4 (p233 ff) J J Labrosse, MicroC/OS-II: The Real Time Kernel: CMP Books Much of this material is based on this book See also Labross’s papers Inside Real-Time Kernels Designing with Real-Time Kernels (Look with Google) CENG-336 Introduction to Embedded Systems Development

Fly-by-wire Avionics Hard real-time system with multirate behavior INU 1kHz GPS 20 Hz Air data 1 kHz Joystick 500 Hz Pitch control Lateral Control 250 Hz Throttle Control Aileron 1 Aileron 2 Elevator Rudder gyros, accel. Sensor Stick Aileron Sensors Signal Conditioning Control laws Actuating Actuators CENG-336 Introduction to Embedded Systems Development

Static Scheduling More Prevalent
RMA only guarantees feasibility at 69% utilization, EDF guarantees it at 100% EDF is complicated enough to have unacceptable overhead More complicated than RMA: harder to analyze Less predictable: can’t guarantee which process runs when CENG-336 Introduction to Embedded Systems Development

CENG-336 Introduction to Embedded Systems Development

Similar presentations

Presentation on theme: "CENG-336 Introduction to Embedded Systems Development"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

CENG-336 Introduction to Embedded Systems Development

Similar presentations

Presentation on theme: "CENG-336 Introduction to Embedded Systems Development"— Presentation transcript:

Similar presentations

About project

Feedback