Introduction to Real-Time Operating System

8/22/2019 Introduction to Real-Time Operating System

1/28

Introduction to Real-Time Operating

System

The acronym RTOS(are toss) is used in Simon.Other use the terms kernel, real-time kernel (RTK).

Despite the similar name, most real-time operatingsystems are rather different from desktop operatingsystems such as Windows or Unix.

RTOS available today: VxWorks, VRTX, pSOS,Nucleus, C Executive, LynxOS, QNX, MultiTask!,

AMX and more.


2/28

Differences Compared to Desktop

Operating System

Desktopyour applications are compiled separatelyfrom the OS.

As you turn-on your desktop, only the OS starts.

Embedded system your application is compiled andlinked together with the RTOS .

At boot-up time, your application usually gets controlfirst, and it then starts the RTOS. Thus, the

application and the RTOS are much more tightly tiedto one another. Neither will run by itself.


3/28

RTOS do not protect themselves as carefully from

your application as do desktop operating systems.

Reason: For better performance. When an

Application is down, the RTOS alone cannot do

much.

To save memory, typically only part of the RTOS

(services/routines/functions) that you need to support

your embedded application system are compiled.

Most RTOSs allow you to configure them extensively

before you link them to the application, letting you leave

out any functions you dont need.


4/28


5/28

Tasks and Task States

The basic building block of software written under an RTOS is thetask. Tasks are very simple to write: under most RTOSs a task issimply a subroutine.

Each task in an RTOS is always in one of three states: Running,Ready, Blocked.

Running means that the microprocessor is executing the instructionsthat make up this task. Unless yours is a multiprocessor system, thereis only one microprocessor, and hence only one task that is in therunning state at any given time.

Ready means that some other task is in the running state but thatthis task has things that it could do if the microprocessor becomesavailable. Any number of tasks can be in this state.

Blockedmeans that this task hasnt got anything to do right now,even if the microprocessor becomes available. Tasks get into this statebecause they are waiting for some external event. Any number oftasks can be in this state as well.


6/28


7/28

The Scheduler

Scheduler part of the RTOS that decides which task

should go next into the running state.

Unlike the scheduler in Unix or Windows, the schedulers

in most RTOSs are entirely simpleminded about which

task should get the processor: highest priority one runs

first, and the rest wait in the ready state, regardless of

starvation.


8/28

A task will block itself when it decides for itself that it hasrun out of things to do. A task has to be running justbefore it is blocked.

While a task is blocked, it is inactive and the CPU cannotbe re-acquire by the task itself. Therefore, an interruptservice routine or some other task in the system must beable to detect the occurrence of whatever conditions orevents the task is waiting for. Otherwise, the task will be

blocked forever. The shuffling of tasks between the ready and running

states is entirely the work of the scheduler. Tasks canblock themselves.

Tasks and interrupt routines can move other tasks fromthe blocked state to the ready state, but the schedulerhas control over which task can switch to the runningstate.


9/28

Tasks and Data

Each task has its own private context, which includesthe register values, a program counter, and a stack.However, all other data global, static, initialized,uninitialized, and everything else is shared among all

tasks in the system. Typically, an RTOS has its own private data structures,

which are not available to any of the tasks.

With data variables shared among tasks, it is easy topass information from one task to another.


10/28

Reentrancy

A reentrant function can be interrupted at anytime and resumed at a later time without loss ofdata.

A reentrant function can be used by more thanone task without fear of data corruption. That is,more than one instance of it can be concurrentlyinvoked and executed.

One way to avoid the shared data problems is toallow access to shared data only amongreentrant functions.


11/28

3 rules to decide if a function is reentrant:

A reentrant function must not perform any non-atomic

access to shared unless they are stored on the stack ofthe task that called the function, or, they are the privatevariables of that task.

A reentrant function may not call any other functions thatare not themselves reentrant.

A reentrant function may not use any hardware in a non-atomic way.


12/28

Semaphores and Shared Data

By switching the CPU from task to task, an RTOSchanges the flow of execution. There, like interrupts, itcan also cause a new class of shared-data problems.

Semaphores is one of the tools used by the RTOS to

solve such problems. Semaphores are used to implement any of :

Control access to a shared resource.

Signal the occurrence of an event.

Allow two tasks to synchronize their activities.


13/28

A semaphore is a key that your code acquires in order to

continue execution.

If the semaphore is already in use, the requesting task is

suspended until the semaphore is released by its current

owner.

In other words, the requesting task says:Give me the

key. If someone else is using it, I am willing to wait for

it!.


14/28

Generally, only three operations can be performed on a

semaphore:

INITIALIZE (also called CREATE),

WAIT (also called PEND), and

SIGNAL (also called POST).

The initial value of the semaphore must be providedwhen the semaphore is initialized.

The waiting list of tasks is always initially empty.


15/28

Reentrancy and Semaphores


16/28

Multiple Semaphores

What is the advantages of having multiple semaphoresinstead of a single one that protects all ?

This avoids the case when higher priority taskswaiting for lower priority tasks even though they dontshare the same data.

By having multiple semaphores, different semaphorescan correspond to different shared resources.

How does the RTOS know which semaphore protectswhich data?

It doesnt. If you are using multiple semaphores, it isup to you to remember which semaphorecorresponds to which data.


17/28

Semaphores as a Signaling Device

Semaphores can also be used as a simple way of

communication between tasks, or between an interrupt

routine and its associated task.

vPrinterTask( ) prepares a line to be printed in

a_chPrint[].

vPrinterInterrupt( ) is an ISR that outputs the

character string in a_chPrint[] to the printer.

semPrinteris used by vPrinterTask( ) as a signal to

vPrinterInterrupt( ) that a new string is ready.


18/28


19/28


20/28

Semaphore Problems

Potential problems

Forgetting to take the semaphore

Forgetting to release the semaphore

Taking the wrong semaphore

Holding a semaphore for too long


21/28

Priority inversion

Some RTOSs resolve this problem with priorityinheritance, they temporarily boost the priority ofTask C to that of Task A whenever Task C holds thesemaphore and Task A is waiting for it.


22/28

Semaphore Variants

Counting semaphores semaphores that can be takenmultiple times.

Resource semaphores useful for the shared-dataproblem.

Mutex semaphore automatically deal with the priorityinversion problem.

If several tasks are waiting for a semaphore when it is

released, different RTOS may vary in the decision as towhich task gets to run.

Task that has been waiting longest.

Highest-priority task that is waiting for the semaphore


23/28

Deadlock

A deadlock, also called a deadly embrace, is a situation

in which two tasks are each unknowingly waiting for

resources held by the other.

Assume task T1 has exclusive access to resource R1

and task T2 has exclusive access to resource R2. If

T1 needs exclusive access to R2 and T2 needs

exclusive access to R1, neither task can continue.

They are deadlocked.


24/28


25/28

The simplest way to avoid a deadlock is for the tasks to

Acquire all resources before proceeding,

Acquire the resources in the same order, and Release the resources in the reverse order.

Most RTOS allow you to specify a timeout when

acquiring a semaphore. This features allows a deadlockto be broken.


26/28

Ways to Protect Shared Data

So far we have learnt two methods: disabling interrupts

and use semaphores.

The third way is disabling task switches.

Disabling task switches To avoid shared-data

corruptions caused by an inappropriate task switch, you

can disable task switches while you are reading or

writing the shared data.


27/28

Comparison of the 3 methods of protecting shared data:

1. Disabling interrupts.

Advantages.

Only method that works if your data is sharedbetween you task code and your interruptroutines and of all other tasks in the system.

It is fast.

Disadvantages. Affect the response times of all the interrupt

routines.


28/28

2. Taking semaphores.

Advantages.

It affects only those tasks that need to take the

same semaphore. Disadvantages.

Take up microprocessor time.

Will not work for interrupt routine.

3. Disabling task switches. Somewhere in between the two. It has no effect on

interrupt routines, but it stops response for all othertasks cold.

Introduction to Real-Time Operating System

Documents

Transcript of Introduction to Real-Time Operating System