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.

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.

 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.

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. Each task in an RTOS is always in one of three states: Running, Ready, Blocked. 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. 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. Blocked means that this task hasnt 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.

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.

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

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.

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.

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 of the task that called the function, or, they are the private variables of that task. A reentrant function may not call any other functions that are not themselves reentrant. A reentrant function may not use any hardware in a nonatomic way.

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.

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

 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.

Reentrancy and Semaphores

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 dont share the same data. By having multiple semaphores, different semaphores can correspond to different shared resources. How does the RTOS know which semaphore protects which data? It doesnt. If you are using multiple semaphores, it is up to you to remember which semaphore corresponds to which data.

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. semPrinter is used by vPrinterTask( ) as a signal to vPrinterInterrupt( ) that a new string is ready.

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

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.

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

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.

 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.

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.

 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.

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.