Rtos Concepts

RTOS�CONCEPTSRTOS�CONCEPTSRTOS�CONCEPTSRTOS�CONCEPTS��

R.PRASATH Page 1

► The term “operating system” can be used to describe the collection of software that manages a

system’s hardware resources.

► This software might include a file system module, a GUI, and other components.

► Oftentimes, a kernel is understood to be a subset of such a collection

► Characteristics

• Resource management e.g. memory, processor, hard disk, cd-rom, printer

• Interface between application and hardware-Creation of an operating system-API for

hardware - leads to a simple handling of the hardware for the programmer (minor

knowledge of hardware)

• Library of functions for the application-The operating system has a big influence at

software reliability, productivity, maintenance and service, Allocation of resources (CPU,

memory, etc) for the application, Deletion of conflict situations.

► If a task must be completed within a given time, it is said to be a real-time task

► The correct result of a real time system depends on:

• a correct answer/reaction to a input

• a point of time, when the result will be delivered

• Type of real time systems

► hard real time

► soft real time

Explanation of the real time requirements with help of the cost function.

► Hard: Time requirement is strictly defined. If the time requirement is not fulfilled, an

unacceptable economic loss occurs (malfunction) e.g.: air control system

► Soft: Time requirement is important. If the time requirement is not fulfilled, the system still

works correct but performance is lost. e.g.: real time video transmission

► Deadline: The maximal time duration, where the real time system computes the result or

executes a reaction, is the deadline. If the deadline is exceed, the reaction of the real time

system depends on the real time requirement (hard or soft).

► Stimuli: Impulses/events from the environment at which the real time system reacts. e.g.:

sensor (humidity sensor and temperature sensor).

► A real-time operating system manages the time of a microprocessor or microcontroller.

R.PRASATH

FEATURES OF AN RTOS:

• Allows multi-tasking

• Scheduling of the tasks with priorities

execute tasks with higher priorities faster than low priority tasks

• Synchronization of the resource access

different tasks to avoid problems like deadlocks or priority inversion

• Inter-task communication

• Interrupt handling

► In a real time system several parts of a problem are handled, they are called tasks.

► Tasks may be processed simultaneously

► Tasks compete against each other for the processor and for the resources (memory, I/O port,

software function)

► Blocked (also known as suspended in some RTOS)

• Task management knows the task and the task not yet changed its

• Task was finished

► ready:

• After activation of the task through

• After occurrence of an event

► running:

• Task got the processor and all necessary resources

• Program instruction

The scheduler decides which task is processed by the processor.

► Behaviour of scheduling

• Non pre-emptive scheduling (cooperative)

• Pre-emptive scheduling

► Type of scheduling

• Static scheduling (time control)

• Dynamic scheduling (event control)


tasking

Scheduling of the tasks with priorities: Defines the priority of each task and is able to

execute tasks with higher priorities faster than low priority tasks

Synchronization of the resource access: Defines way to share resources within the

different tasks to avoid problems like deadlocks or priority inversion

task communication

Interrupt handling

In a real time system several parts of a problem are handled, they are called tasks.

simultaneously or sequentially.

Tasks compete against each other for the processor and for the resources (memory, I/O port,

Blocked (also known as suspended in some RTOS)

Task management knows the task and the task not yet changed its state.

After activation of the task through another task, an interrupt or the OS

After occurrence of an event

Task got the processor and all necessary resources

Program instruction is execute through the processor

The scheduler decides which task is processed by the processor.

emptive scheduling (cooperative)

emptive scheduling

Static scheduling (time control)

Dynamic scheduling (event control)

Page 2

Defines the priority of each task and is able to

o share resources within the

In a real time system several parts of a problem are handled, they are called tasks.

Tasks compete against each other for the processor and for the resources (memory, I/O port,

state.

task, an interrupt or the OS


R.PRASATH Page 3

► Method of scheduling

• Priority control

• Time slice (Round robin)

• FIFO

► Scheduling

• The processor assignment of the tasks is called scheduling. All tasks which have the state ready

may assign the processor (if tasks were activated or an event occurred).

Non pre-emptive scheduling (cooperative)

• Tasks cannot be pre-empted by other tasks during their execution.

• With the pre-emptive scheduling tasks with high priority delay tasks with lower priority.

Pre-emptive scheduling

• Tasks may pre-empted by other tasks during runtime.

• A low priority task does not cause a delay for a higher priority task if pre-emptive scheduling is

used. ⇒ fast reaction time of the more important/critical tasks

Static scheduling

• The processor assignment of the tasks with static scheduling has a predefined sequence. The

sequence of the task execution is determined at compile time.

Dynamic Scheduling

• The decision which task is executed is determined at run time. The scheduler adapts to the

current task situation.

Context Switch (or Task Switch)

• When a multitasking kernel decides to run a different task, it simply saves the current task's

context (CPU registers) in its stack.

R.PRASATH

• Once this operation is performed, the new task‘s cont

then resumes execution of the new task's code.

• This process is called a context switch or a task switch.

• Context switching adds overhead to the application. The more registers a CPU has, the

the overhead. The time required to perform a context switch is determined by how many

registers and data have to be saved and restored by the CPU. MQX saves the program counter,

registers, and stack.

Competence Condition

► What happen if two tasks access to the same resourc

• We call this “competence condition”. When two or more tasks read or write on share

resource at certain moment.

► Why the “competence condition “can

• Memory corruption

• Wrong results

• Unstable application

• Device conflicts


Once this operation is performed, the new task‘s context is restored from its storage area and

then resumes execution of the new task's code.

context switch or a task switch.

adds overhead to the application. The more registers a CPU has, the

e time required to perform a context switch is determined by how many


What happen if two tasks access to the same resource at the same time?

We call this “competence condition”. When two or more tasks read or write on share

resource at certain moment.

condition “can be a problem?

Memory corruption

Unstable application

Priority Inversion problem

Page 4

ext is restored from its storage area and

adds overhead to the application. The more registers a CPU has, the higher

e time required to perform a context switch is determined by how many


We call this “competence condition”. When two or more tasks read or write on share


R.PRASATH Page 5

In the case a high priority task (task3) preempts a low priority task (task1), which occupied a

resource; the higher priority task (task3) will get the CPU and run. If the high priority task3 tries to

access the same resource, it gets blocked and will wait because the resource was locked by task1. If

now a task (task2) with a priority between the two tasks is ready to run, it will get the CPU and

execute because the higher priority task is waiting and the lower priority task is preempted. Now, a

task with a lower priority blocks a task with a higher priority. This blocking can be unbounded and

then the system can crash.

Semaphores

► A semaphore is a protocol mechanism offered by most multitasking kernels. Semaphores are

used to:

• control access to a shared resource (mutual exclusion)

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

► When the task creates the semaphore, it also specifies:

• Initial count

• Priority queuing

► NOTE: If priority queuing is not specified, the queue is in FIFO order, and MQX puts the

semaphore to the longest-waiting task.

• Priority inheritance

• Strictness

► Semaphores are an optional component. They are counting semaphores. You can use

semaphores to synchronize tasks. You can use a semaphore to guard access to a shared

resource, or to implement a producer/consumer-signaling mechanism. Semaphores can be strict

or non-strict.

► -Initial count — the initial value for the semaphore count represents the number of locks that

the semaphore has. (A task can get multiple locks).

► -Priority queuing — if priority queuing is specified, the queue of tasks waiting for the semaphore

is in priority order, and MQX puts the semaphore to the highest-priority waiting task.

R.PRASATH

► -If priority queuing is not specified, the queue is in FIFO order, and MQX puts the

the longest-waiting task.

► -Priority inheritance — if priority inheritance is specified and a higher

the semaphore, MQX raises the priority of the tasks that have the semaphore to the priority of

the waiting task. To use priority inheritance, the semaphore must be strict.

► -Strictness — if strictness is specified, a task must wait for the semaphore, before it can post the

semaphore. If a semaphore is strict, the initial count is the maximum value of the semaphore

count. If the semaphore is non


If priority queuing is not specified, the queue is in FIFO order, and MQX puts the

if priority inheritance is specified and a higher-priority task is waiting for


To use priority inheritance, the semaphore must be strict.

if strictness is specified, a task must wait for the semaphore, before it can post the


nt. If the semaphore is non-strict, the count is unbounded.

Page 6

If priority queuing is not specified, the queue is in FIFO order, and MQX puts the semaphore to

priority task is waiting for


if strictness is specified, a task must wait for the semaphore, before it can post the


R.PRASATH

► Tasks can communicate with each other by exchanging messages.

► Tasks send messages to message queues, and receive messages from message queues.

► Messages can be assigned

► Messages are an optional component in MQX. Tasks can communicate with each other by

sending messages to message queues that are opened by other tasks. Each task opens its

own input-message que

MQX assigns when the queue is created. Only the task that opens a message queue can

receive messages from the queue. Any task can send to any previously opened message

queue, if it knows the queue ID of the opened queue.

► Tasks allocate messages from message pools. There are system

message pools. Any task can allocate a message (system message) from system

pools. Any task with the pool ID can allocate a messa

message pool.

► The messages need a queue where the messages will be put for sending and receiving.

► The messages are taken from a message pool. Memory used to fill the source task, destination

task, message data and othe

► The tasks open the message queue. It is like opening a channel to the queue.

► A task creates messages from the pool and is

queue receives the messages and forwards to the task destination.


Messages passing

Tasks can communicate with each other by exchanging messages.

Tasks send messages to message queues, and receive messages from message queues.

Messages can be assigned a priority or marked urgent. Tasks can send broadcast messages

Messages are an optional component in MQX. Tasks can communicate with each other by


message queues. A message queue is uniquely identified by its queue ID, which



e queue ID of the opened queue.

Tasks allocate messages from message pools. There are system-message pools and private

message pools. Any task can allocate a message (system message) from system

pools. Any task with the pool ID can allocate a message (private message) from a private

The messages need a queue where the messages will be put for sending and receiving.

The messages are taken from a message pool. Memory used to fill the source task, destination

task, message data and other information

The tasks open the message queue. It is like opening a channel to the queue.

A task creates messages from the pool and is sent to the message queue. Finally, the message

queue receives the messages and forwards to the task destination.

Page 7

Tasks send messages to message queues, and receive messages from message queues.

a priority or marked urgent. Tasks can send broadcast messages

Messages are an optional component in MQX. Tasks can communicate with each other by


ues. A message queue is uniquely identified by its queue ID, which



message pools and private-

message pools. Any task can allocate a message (system message) from system-message

ge (private message) from a private-

The messages need a queue where the messages will be put for sending and receiving.

The messages are taken from a message pool. Memory used to fill the source task, destination

sent to the message queue. Finally, the message


R.PRASATH Page 8

Mutex

► Mutexes are used for mutual exclusion, so that only one task at a time uses a shared resource

such as data or a device. To access the shared resource, a task locks the mutex associated with

the resource. The task owns the mutex, until it unlocks the mutex.

► Mutexes are an optional component in MQX. A mutex provides mutual exclusion among tasks,

when they access a shared resource. Mutexes are strict; that is, a task cannot unlock a mutex,

unless it had first locked the mutex.

Waiting Protocols

► Queuing (default)

► Priority queuing

► Spin only

► Limited spin

Scheduling Protocols

► Priority inheritance

► Priority protection

Explanation

► Queuing (default) - Blocks, until another task unlocks the mutex. When the mutex is unlocked,

the first task (regardless of priority) that requested the lock, locks the mutex.

► Priority queuing - Blocks, until another task unlocks the mutex. When the mutex is unlocked, the

highest-priority task that requested the lock, locks the mutex.

► Spin only - Spins (is timesliced) indefinitely, until another task unlocks the mutex. This means

that MQX saves the requesting task’s context, and dispatches the next task in the same-priority

ready queue. When all the tasks in this ready queue have run, the requesting task becomes

active again. If the mutex is still locked, the spin repeats.

► Limited spin - Spins for a specified number of times, or fewer, if another task unlocks the mutex

first.

R.PRASATH

► Priority inheritance - If the priority of the task that has locked the mutex (task_A) is not as high

as the highest-priority task that is waiting to lock the mutex (task_B), MQX raises the priority of

task_A to be the same as the priority of task_B, while task_A has the mutex.

► Priority protection - A mutex can have a priority. If the priority of a task that r

mutex (task_A) is not at least as high as the mutex priority, MQX raises the priority of task_A to

the mutex priority for as long as task_A has the mutex locked.

► There are 3 tasks. Task 2 locks the Mutex.

► The task 1 tries to lock the Mutex but it is already locked so task 1 waits in the Mutex’s queue.

► The task 3 then tries to lock the Mutex but it is already locked so task 3 waits in the Mutex’s

queue.

► The task 3 unlocks the Mutex and the task 1 locks it.

► The task 2 unlocks the Mutex

► A Mutex is a binary semaphore, usually including extra features like ownership or priority

inversion protection. The differences between mutexes and semaphores are operating system

dependent. Mutexes are meant to be used for mutual

meant to be used for event notification and mutual exclusion.

Priority Inversion solution


If the priority of the task that has locked the mutex (task_A) is not as high

priority task that is waiting to lock the mutex (task_B), MQX raises the priority of

task_A to be the same as the priority of task_B, while task_A has the mutex.

A mutex can have a priority. If the priority of a task that requests to lock the


the mutex priority for as long as task_A has the mutex locked.

There are 3 tasks. Task 2 locks the Mutex.

Mutex but it is already locked so task 1 waits in the Mutex’s queue.

The task 3 then tries to lock the Mutex but it is already locked so task 3 waits in the Mutex’s

The task 3 unlocks the Mutex and the task 1 locks it.

The task 2 unlocks the Mutex and the task 3 locks it.

A Mutex is a binary semaphore, usually including extra features like ownership or priority


dependent. Mutexes are meant to be used for mutual exclusion only and binary semaphores are

meant to be used for event notification and mutual exclusion.

Page 9

If the priority of the task that has locked the mutex (task_A) is not as high

priority task that is waiting to lock the mutex (task_B), MQX raises the priority of

equests to lock the


Mutex but it is already locked so task 1 waits in the Mutex’s queue.

The task 3 then tries to lock the Mutex but it is already locked so task 3 waits in the Mutex’s

A Mutex is a binary semaphore, usually including extra features like ownership or priority


exclusion only and binary semaphores are

R.PRASATH

Event Flags

► Event flags are used when a task needs to synchronize with the occurrence of multiple events.

The task can be synchronized when any of the events have occurred. This is called disjunctive

synchronization (logical OR).

► A task can also be synchronized when

synchronization (logical AND).

► Kernels supporting event flags offer services to SET event flags, CLEAR event flags, and WAIT for

event flags (conjunctively or disjunctively).

► Depending on the kernel, a group consists of 8, 16 or 32 flag

events, though).

► Tasks and ISRs can set or clear any event in a group.

► A task is resumed when all the events it requires are satisfied. The evaluation of which ta

be resumed is performed when a new set of events occurs


Event flags are used when a task needs to synchronize with the occurrence of multiple events.


synchronization (logical OR).

A task can also be synchronized when all events have occurred. This is called conjunctive

synchronization (logical AND).

Kernels supporting event flags offer services to SET event flags, CLEAR event flags, and WAIT for

event flags (conjunctively or disjunctively).

Depending on the kernel, a group consists of 8, 16 or 32 flag-events (mostly 32

Tasks and ISRs can set or clear any event in a group.

A task is resumed when all the events it requires are satisfied. The evaluation of which ta

be resumed is performed when a new set of events occurs

Page 10

Event flags are used when a task needs to synchronize with the occurrence of multiple events.


all events have occurred. This is called conjunctive

Kernels supporting event flags offer services to SET event flags, CLEAR event flags, and WAIT for

events (mostly 32-bits for 32

A task is resumed when all the events it requires are satisfied. The evaluation of which task will

Rtos Concepts

Documents

preemptive scheduling

run time

point of time

compile time

given time

task switch

tasks access

real time requirements