RTOS

Dr Jimmy To, EIE, POLYU

1

EIE 322

Interface and Embedded Systems

Lecture 7 : Introduction to Real-time operating system

Chapter 6 of D. Simon E. An Embedded Software Primer QA76.6.S57261999


2

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 operating systems are rather different from desktop operating systems such as Windows or Unix.

RTOS available today: VxWorks, VRTX, pSOS, Nucleus, C Executive, LynxOS, QNX, MultiTask!, AMX and more.


3

Differences Compared to Desktop Operating System

Desktop –your applications are compiled separately from the OS. – As you turn-on your desktop, only the OS starts.

Embedded system – your application is compiled and linked together with the RTOS .– At boot-up time, your application usually gets

control first, and it then starts the RTOS. Thus, the application and the RTOS are much more tightly tied to one another. Neither will run by itself.


4

Differences Compare to Desktop Operating System

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 don’t need.


5

Tasks and Task States

The basic building block of software written under an RTOS is the task. Tasks are very simple to write: under most RTOSs a task is simply a subroutine. (Figure 6.4)

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


6

Task States


7

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

The Scheduler (cont)

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

While a task is blocked, it is inactive and the CPU cannot be re-acquire by the task itself. Therefore, an interrupt service routine or some other task in the system must be able to detect the occurrence of whatever conditions or events the task is waiting for. Otherwise, the task will be blocked forever.


9

The Scheduler (cont)

The shuffling of tasks between the ready and running states is entirely the work of the scheduler. Tasks can block themselves.

Tasks and interrupt routines can move other tasks from the blocked state to the ready state, but the scheduler has control over which task can switch to the running state.


10

Common Questions

How does the scheduler know when a task has become blocked or unblocked?– The RTOS provides a collection of functions that

tasks can call to tell the scheduler what events they want to wait for and to signal that events have happened.

What happens if all the tasks are blocked?– If all the tasks are blocked, then the scheduler

will stay in some tight loop somewhere inside the RTOS, waiting for something to happen. If something happens, an interrupt routine will calls some RTOS function that will unblock a task.


11

Common Questions (cont)

What if two tasks with the same priority are ready?– It depends on which RTOS was used. Possible

solutions: making it illegal to have two tasks with the same priority or, time-slice between two such tasks.

If one task is running and another higher-priority task unblocks, will the running task get stopped and moved to the ready state right away?– A preemptive RTOS will stop a lower-priority task as

soon as the higher-priority task unblocks. A non-preemptive RTOS will only take the microprocessor away from the lower-priority task when it blocks itself.


12

Tasks and Data

Each task has its own private context, which includes the 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 to pass information from one task to another.


13

Shared-Data Problems

Recall in lecture 5 all the potential problems which are cause by sharing data.

Theses problems will also arise in RTOS when data are shared among tasks.

Figure 6.7 and Figure 6.8 show an example of how subtle these problems can be.


14

Reentrancy

A reentrant function can be interrupted at any time and resumed at a later time without loss of data.

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

One way to avoid the shared data problems is to allow access to shared data only among reentrant functions.


15

Reentrancy (cont)

3 rules to decide if a function is reentrant:1. A reentrant function must not perform any

non-atomic access to shared unless they are stored on the stack of the task that called the function, or, they are the private variables of that task.

2. A reentrant function may not call any other functions that are not themselves reentrant.

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


16

Examples from the text

A Review of C Variable Storage– p.150 Figure 6.9

Applying the Reentrancy Rules – Figure 6.10– Violate rule 1,2 How?

Atomic?– Yes and – No


17

Semaphores and Shared

Data

By switching the CPU from task to task, an RTOS changes the flow of execution. There, like interrupts, it can 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.


18

Semaphores and Shared Data

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!”.


19

Semaphores and Shared Data

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 provided when the semaphore is initialized.

The waiting list of tasks is always initially empty. Figure 6.14 is an example showing how

semaphores can be used.


20

Reentrancy and Semaphores

Figure 6.15 from the text.


21

Multiple Semaphores

What is the advantages of having multiple semaphores instead of a single one that protects all ?– This avoids the case when higher priority tasks

waiting for lower priority tasks even though they don’t share the same data.

– By having multiple semaphores, different semaphores can correspond to different shared resources.


22

Multiple Semaphores (cont)

How does the RTOS know which semaphore protects which data?– It doesn’t. If you are using multiple

semaphores, it is up to you to remember which semaphore corresponds to which data.


23

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.

Figure 6.16 provide a good example of how it can be apply. – 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. – semPrinter is used by vPrinterTask( ) as a

signal to vPrinterInterrupt( ) that a new string is ready.


24

Semaphore Problems

Potential problems– Forgetting to take the semaphore– Forgetting to release the semaphore– Taking the wrong semaphore– Holding a semaphore for too long

Priority inversion Figure 6.17– Some RTOSs resolve this problem with

priority inheritance, they temporarily boost the priority of Task C to that of Task A whenever Task C holds the semaphore and Task A is waiting for it.


25

Semaphore Variants

Counting semaphores – semaphores that can be taken multiple times.

Resource semaphores – useful for the shared-data problem.

Mutex semaphore – automatically deal with the priority inversion problem.

If several tasks are waiting for a semaphore when it is released, different RTOS may vary in the decision as to which task gets to run.

– Task that has been waiting longest.– Highest-priority task that is waiting for the semaphore


26

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.


27

Deadlock (cont)

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 deadlock to be broken.


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.


29


Comparison of the 3 methods of protecting shared data:

1. Disabling interrupts.– Advantages.

» Only method that works if your data is shared between you task code and your interrupt routines and of all other tasks in the system.

» It is fast.

– Disadvantages.» Affect the response times of all the interrupt

routines.


30


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 other tasks cold.


31

Running

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


32

Ready

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


33

Blocked

Blocked – means that this task hasn’t got anything to do right now, even if the microprocessor becomes available. Tasks get into this state because they are waiting for some external event. Any number of tasks can be in this state as well.


34


35


36


37

shared

on stack

on stacknot shared

Shared in this source file only


38

test

set

reset


39


40


41


42

Atomic?


43

8051 code -- No

read copyincrement copywrite copy back to memory


44

80x86 code -- Yes

Documents

RTOS