Real Time Embedded Systems (A7422)

Unit – II
Introduction to Real Time Operating Systems

T. Ramakrishnaiah
Associate Professor

Department of Electronics and Communication Engineering

VARDHAMAN COLLEGE OF ENGINEERING
Shamshabad, Hyderabad – 501218, India.
 Real Time Embedded Systems (A7422)

Contents
 Tasks and Task States
 Tasks and Data
 Semaphores and Shared Data
 Message Queues
 Mailboxes and Pipes
 Timer Functions
 Events
 Memory Management
 Interrupt Routines in an RTOS environment

2
 Real Time Embedded Systems (A7422)

Desktop vs Embedded systems

 On a desktop computer the operating system takes control of the
system as soon as it is turned on and then lets you start your
applications.
 You compile and link your applications separately from the
operating system
 In embedded system you usually link your application and the
RTOS.
 At the boot-up time, your application usually gets control first, and
then it starts the RTOS.
 Thus the application and RTOS are much more tightly tied to one
another than are an application and its desktop operating systems.

3
 Real Time Embedded Systems (A7422)

Introduction
 A real-time operating system (RTOS) is an operating
system (OS) intended to serve real-time application process
data as it comes in, typically without buffering delays.
 The Real Time Operating System consists time constraints to

complete particular task also called as Deadlines.

 Types of RTOS:

1. Hard Real Time RTOS

2. Soft Real Time RTOS

4
 Real Time Embedded Systems (A7422)

Introduction Cont..
 Hard Real Time RTOS is an RTOS that meets a deadline with in given time limit

and the amount of time it takes to complete task is deterministic.

 Soft Real Time RTOS is an RTOS that may or may not meet a deadline with in

given time limit and the amount of time it takes to complete task is not
deterministic.
 The most common RTOS designs are:

1. Event-driven which switches tasks only when an event of higher priority

needs servicing, called preemptive priority, or priority scheduling.
2. Time-sharing designs switch tasks on a regular clocked interrupt, and on
events, called round robin.
5
 Real Time Embedded Systems (A7422)

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.
 ES application makes calls to the RTOS functions to start tasks,

passing to the OS, start address, stack pointers, etc. of the

tasks.

6
 Real Time Embedded Systems (A7422)

Tasks and Task States Cont..

 Each task in an RTOS is always in one of three states

1. Running - This means that the microprocessor is executing the instructions of a task.

Unless yours is a multiprocessor system, there is only one microprocessor, and hence

only one task will be in the running state at any given time.

2. Ready - This 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.

3. Blocked -This 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. For example, a task that handles data coming in from a network

will have nothing to do when there is no data.

7
 Real Time Embedded Systems (A7422)

Tasks and Task States Cont..

The Scheduler
 A part of the RTOS called the scheduler keeps track of the
state of each task and decides which one task should go into
the running state.
 Very simple behavior: schedulers look at priorities you assign
to the tasks, and among the tasks that are not in the blocked
state, the one with the highest priority runs, and the rest of
them wait in the ready state.
 The lower-priority tasks just have to wait; the scheduler
assumes that you knew what you were doing when you set the
task priorities.
8
 Real Time Embedded Systems (A7422)

Tasks and Task States Cont..

9
 Real Time Embedded Systems (A7422)

Tasks and Task States Cont..

Issues
 How does the scheduler know when a task has become blocked or

unblocked?
 The RTOS provides a collection of functions

 What happens if all the tasks are blocked?

 The scheduler spin in some tight loop somewhere inside of the RTOS

 What if two tasks with the same priority are ready?

 If one task is running and another, higher priority task unblocks,

 does the task that is running get stopped and moved to the ready state

right away?
1
0
 Real Time Embedded Systems (A7422)

Tasks and Task States Cont..

Preemptive or Non preemptive RTOS
 A preemptive OS will block a lower priority process when a

higher priority process enters the ready state.

 A non-preemptive OS will continue executing the current

running process until it blocks regardless of the priorities of

the other ready processes.

1
1
 Real Time Embedded Systems (A7422)

Tasks and Task States Cont..

Example Under ground tank monitoring system:
 This pseudo-code is from underground tank monitoring system.

 Here we have two tasks vLevelsTask having low priority, vButtonTask

having high priority .The vLevelsTask task uses for computing how
much gasoline is in the tanks.
 If user pushes the button, then vButtonTask task unblocks, The RTOS

will stop low priority vLevelsTask task in its tracks, move it to the
ready state, and run the high priority vButtonTask task.
 When vButtonTask task is finished responding, it blocks and RTOS

gives the microprocessor back to the vLevelsTask task once again.

1
2
 Real Time Embedded Systems (A7422)

Tasks and Task States Cont..

1
3
 Real Time Embedded Systems (A7422)

Tasks and Task States Cont..

Example Code of underground tank monitoring system

1
4
 Real Time Embedded Systems (A7422)

Tasks and Task States Cont..

1
5
 Real Time Embedded Systems (A7422)

Tasks and Task States Cont..

1
6
 Real Time Embedded Systems (A7422)

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 of the tasks in the

system.
 The RTOS typically has its own private data structures, which

are not available to any of the tasks.

 Easy to move data from one task to another

1
7
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

1
8
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

Sharing data variables between different tasks
 Since you can share data variables among tasks, it is easy to

move data from one task to another

 The two tasks need only have access to the same variables.

 You can easily accomplish this by having the two tasks in the

same module in which the variables are declared or you can

make the variables public in one of the tasks and declare them
extern in the other.

1
9
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

2
0
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

2
1
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

Shared-Data Problems
 The RTOS might stop vCalculateTankLevels right in the middle

of setting data in the tank data array (which is not an atomic

operation) and vRespondToButton might then read that half-
changed data.

2
2
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

2
3
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

Shared-Data Problems
 In the above example both Task1 and Task2 call vCountErrors.

 This is a perfectly valid thing to do in an RTOS: any or all of the

tasks can share as many subroutines as is convenient.

 But the above example has a potential bug in it.

 The difficulty with the program is that both task1 and Task2

call vCountErrors, since vCountErrors uses the variable cErrors,

the variable cErrors is now shared by the two tasks.

2
4
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

Shared-Data Problems
 If Task1 calls vCountErrors and if the RTOS then stops Task1

and runs Task2, which then calls vCountErrors, the variable

cErrors may get corrupted in just the same way as it would if
Task2 were an interrupt routine that had interrupted Task1.

2
5
 Real Time Embedded Systems (A7422)

2
6
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

Shared-Data Problems
 Assume that at an instant when the value of variable operates

and during the operations on it, only a part of the operation is

completed and another part remains incomplete.
 At that moment, assume that there is an interrupt.

 Assume that there is another function. It also shares the same

variable. The value of the variable may differ from the one
expected if the earlier operation had been completed.

2
7
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

Reentrancy
 These are the functions that can be called by more than one task and that will

always work correctly, even if the RTOS switches from one task to another in the
middle of executing the function.
 Three rules to decide if a function is reentrant

1. A reentrant function may not use variables in a non-atomic way unless they are
stored on the stack of the task that called. The function or are otherwise 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 the hardware in a non atomic way.
2
8
 Real Time Embedded Systems (A7422)

2
9
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

 static_int - is in a fixed location in memory and is therefore

shared by any task that happens to call function.

 public_int - Ditto. The only difference between static_int and

public_int is that functions in other C files can access public_int,

but they cannot access static_int
 Initialized - The same. The initial value makes no difference to

where the variable is stored.

 String - The same.

 “Where does this string go?" - Also the same.

3
0
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

 vPointer - The pointer itself is in a fixed location in memory

and is therefore a shared variable. If function uses or changes

the data values pointed to by vPointer, then those data values
are also shared among any tasks that happen to call function.
 parm - is on the stack. If more than one task calls function,

parm will be in a different location for each, because each task

has its own stack. No matter how many tasks call function, the
variable parm will not be a problem.

3
1
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

 parm_ptr - is on the stack. Therefore, function can do anything to the

value of parm_ptr without causing trouble. However, if function uses or

changes the values of whatever is pointed to by parm_ptr, then we have
to ask where that data is stored before we know whether we have a
problem.
 static_local - is in a fixed location in memory. The only difference

between this and static_int is that static_int can be used by other

functions in the same C file, whereas static_local can only be used by
function.
 Local - is on the stack.

3
2
 Real Time Embedded Systems (A7422)

3
3
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

 The function is not reentrant for two reasons

Rule1 (Violates)
 The variable fError is in a fixed location in memory and is

therefore shared by any task that calls display.

 The use of fError is not atomic, because the RTOS might switch

tasks between the time that it is tested and the time that it is
set.
Rule2 (Violates)
 For this function to be reentrant, printf must also be reentrant.
3
4
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

Gray Areas of Reentrancy
 There are some gray areas between reentrant and non-reentrant

functions.
 The code here shows a very simple function in the gray area.

static int cErrors;

void vCountErrors (void)
{
++cErrors;
}
3
5
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

Gray Areas of Reentrancy
 This function obviously modifies a non-stack variable, but rule 1

says that a reentrant function may not use non-stack variables in a

non atomic way. The question is: is incrementing cErrors atomic?
 cErrors is atomic if you use 8086 instruction set to write program for

above piece of code as it takes only 2 lines code like below:

INC (cErrors)
RET

3
6
 Real Time Embedded Systems (A7422)

Tasks and Data Cont..

Gray Areas of Reentrancy
 cErrors is NOT atomic if we write an assembly language
program by using 8051 instructions for above piece of code as
it is going to take 9 lines. In that 9 lines, chance of occurrence
of interrupt is more.

3
7
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data

 The RTOS can cause a new class of shared-data problems by switching

the microprocessor from task to task and like interrupts, changing the
flow of execution.
 The RTOS also gives you new tools with which to deal with shared-

data problem. Semaphores are one such tool.

 In computer science, a semaphore is a variable or abstract data type

that is used for controlling access, by multiple processes, to a common

resource in a concurrent system such as a multiprogramming
operating system.
3
8
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

3
9
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

 When the first train enters the pictured section of track, the semaphore

behind it automatically lowers.

 When a second train arrives, the engineer notes the lowered

semaphore and he stops his train and waits for the semaphore to rise.
 When the first train leaves that section of track, the semaphore rises,

and the engineer on the second train knows that it is safe to proceed
on.
 The general idea of a semaphore in an RTOS is similar to the idea of a

railroad semaphore.

4
0
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

 No RTOS use the terms raise and lower; they use get and give, take

and release, pend and post, p and v, wait and signal.

Binary Semaphore
 A typical RTOS binary semaphore work like this: tasks can call two RTOS

functions, TakeSemaphore and ReleaseSemaphore.

 If one task has called TakeSemaphore to take the semaphore and has

not called ReleaseSemaphore to release it, then any other task that
calls TakeSemaphore will block until first task calls ReleaseSemaphore.
 Only one task can have the semaphore at a time.

4
1
 Real Time Embedded Systems (A7422)

4
2
 Real Time Embedded Systems (A7422)

4
3
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

 Before the “levels task” (vCalculateTankLevels) updates the data in the

structure, it calls Take Semaphore to take (lower) the semaphore.

 If the user presses a button while the levels task is still modifying the

data and still has the semaphore, then the following sequence of
events occurs:
1. The RTOS will switch to the button task, just as before moving the
levels task to ready state.
2. When the button task tries to get semaphore by calling
TakeSemaphore, it will block because the levels task already has the
semaphore.
4
4
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

3. The RTOS will then look around for another task to run and will notice
that levels task is still ready. With the button task blocked, the levels
task will get to run until it releases the semaphore.
4. When the levels task release the semaphore by calling
ReleaseSemaphore, the button task no longer be blocked and the
RTOS will switch back to it.

4
5
 Real Time Embedded Systems (A7422)

4
6
 Real Time Embedded Systems (A7422)

4
7
 Real Time Embedded Systems (A7422)

4
8
 Real Time Embedded Systems (A7422)

4
9
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

Initializing Semaphore
 The functions and data structures whose names begin with OS are

those used in µC/OS.

 The OSSempost and OSSempend functions raise and lower the

semaphore.
 The OSSemCreate function initializes the semaphore and it must be

called before either of the other two.

 The OS_EVENT structure stores the data that represents the

semaphore, and it is entirely maintained by the RTOS.

5
0
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

 The WAIT_FOREVER parameter to the OSSemPend function indicates

that the task making the call is willing to wait forever for the
semaphore.
 The OSTimeDly function causes vReadTemperatureTask to block

approximately a quarter of a second; the event that unblocks it is

simply the expiration of that amount of time.
 Therefore this task wakes up, reads in the two temperatures, and

places them in the array once every quarter of a second.

 In the mean time, vControlTask checks continuously that the two

temperatures are equal.

5
1
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

 The bug arises with the call to OSSemCreate, which must happen

before vReadTemperatureTask calls OSSemPend to use the semaphore.

 Put the semaphore initialization call to OSSemCreate in some start-up

code that’s guaranteed to run first.

 Call OSSemInit() before OSInit() would be a good place.

5
2
 Real Time Embedded Systems (A7422)

5
3
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

Reentrancy and Semaphores
 The shared function vCountErrors which in pervious example was not reentrant.

 In above figure the code that modifies the static variable cErrors is surrounded by

calls to semaphore routines.

 Whichever task calls vCountErrors second will be blocked when it tries to take the

semaphore.
 In the language of reentrancy we have made the use of cErrors atomic and

therefore have made function vCountErrors reentrant.

 The functions and data structures whose names begin with NU are those used in an

RTOS called Nucleus.

5
4
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

Semaphores as a Signaling Device
 Another common use of semaphore is as a simple way to communicate

from one task to another or from an interrupt routine to task.

5
5
 Real Time Embedded Systems (A7422)

5
6
 Real Time Embedded Systems (A7422)

5
7
 Real Time Embedded Systems (A7422)

5
8
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

Semaphore Problems
 Forgetting to take the semaphore: Semaphores only work if every task

that accesses the shared data, for read or for write, uses the
semaphore. If anybody forgets, then the RTOS may switch away from
the code that forgot to take the semaphore and cause an ugly shared-
data bug.
 Forgetting to release the semaphore: If any task fails to release the

semaphore, then every other task that ever uses the semaphore will
sooner or later block waiting to take that semaphore and will be
blocked forever.
5
9
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

Semaphore Problems
 Taking the wrong semaphore: If you are using multiple semaphores,

then taking the wrong one is as bad as forgetting to take one.

 Holding a semaphore for too long: Whenever one task takes a

semaphore, every other task that subsequently wants that semaphore

has to wait until the semaphore is released. If one task takes the
semaphore and then holds it for too long, other tasks may miss rea1 -
time deadlines.

6
0
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

Priority Inversion
 Because of low priority task , if any high priority task go to the blocked

state and miss its real-time deadline, this situation is called a priority
inversion problem.
 In priority inversion a high priority task waits because a low priority task

has a semaphore, but the lower priority task is not given CPU time to
finish its work.
 A typical solution is to have the task that owns a semaphore run at, or

'inherit‘, the priority of the highest waiting task.

6
1
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

6
2
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

Semaphore Variants
 Counting semaphores: Some systems offer semaphores that can be

taken multiple times. Essentially, such semaphores are integers; taking

them decrements the integer and releasing them increments the
integer. If a task tries to take the semaphore when the integer is equal
to zero, then the task will block. These semaphores are called counting
semaphores, and they were the original type of semaphore.

6
3
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

Semaphore Variants
 Resource semaphores: Some systems offer semaphores that can be

released only by the task that took them. These semaphores are useful
for the shared - data problem, but they cannot be used to
communicate between two tasks. Such semaphores are sometimes
called resource semaphores or resources.

6
4
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

Semaphore Variants
 Mutex semaphore: Some RTOSs offer one kind of semaphore that will

automatically deal with the priority inversion problem and another that
will not. The former kind of semaphore commonly called a mutex
semaphore or mutex. (Other RTOSs offer semaphores that they call
mutexes but that do not deal with priority inversion.)

6
5
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

Ways to Protect Shared Data
 Disabling interrupts: it is the most drastic in that it will affect the
response times of all the interrupt routines and of all other tasks in the
system
 On the other hand, disabling interrupts has two advantages.
1. It is the only method that works if your data is shared between your
task code and your interrupt routines. Interrupt routines are not
allowed to take semaphores, and disabling task switches does not
prevent interrupts.
2. It is fast. Most processors can disable or enable interrupts with a
single instruction;

6
6
 Real Time Embedded Systems (A7422)

Semaphores and Shared Data Cont..

Ways to Protect Shared Data
 Taking semaphores is the most targeted way to protect data, because it
affects only those tasks that need to take the same semaphore
 Disabling task switches is somewhere in between the two. It has no
effect on interrupt routines, but it stops response for all other tasks .

6
7
 Real Time Embedded Systems (A7422)

More Operating System Services

 Tasks must be able to communicate with one another to coordinate
their activities or to share data.
 In pervious we discussed using shared data and semaphore to allow
tasks to communicate with one another.
 Several other methods that most RTOSs offer
1. Queues
2. Mailboxes
3. Pipes

6
8
 Real Time Embedded Systems (A7422)

Message Queues
Simple Example
 Suppose that we have two tasks, Task1 and Task2, each of which has a
number of high-priority, urgent things to do. Suppose also that from
time to time these two tasks discover error conditions that must be
reported on a network, a time consuming process.
 In order not to delay Task1 and Task2, it makes sense to have a separate
task, ErrorsTask that is responsible for reporting the error conditions on
the network.
 Whenever Task1 or Task2 discovers an error, it reports that error to
ErrorsTask and then goes on about its own business.
 The error reporting process undertaken by ErrorsTask does not delay
the other tasks.
 An RTOS queue is the way to implement this design.

6
9
 Real Time Embedded Systems (A7422)

7
0
 Real Time Embedded Systems (A7422)

7
1
 Real Time Embedded Systems (A7422)

Message Queues Cont..

 The ReadFromQueue function reads the value at the head of the queue
and returns it to the caller.
 If the queue is empty, ReadFromQueue blocks the calling task.
 The RTOS guarantees that both of these functions are reentrant.
 If the RTOS switches from Task1 to Task2 when Task1 is in middle of
AddToQueue, and if Task2 subsequently calls AddToQueue, the RTOS
ensures that things still work.
 Each time ErrorsTask calls ReadFromQueue, it gets the next error from
the queue, even if the RTOS switches from ErrorsTask to Task1 to Task2
and back again in the middle.

7
2
 Real Time Embedded Systems (A7422)

Message Queues Cont..

Some Ugly Details:
Queues are not quite simple. Here are some of the complications that
you will have to deal with in most RTOSs:
 Most RTOSs require that you initialize your queues before you use
them, by calling a function provided for this purpose. On some systems,
it is also up to you to allocate the memory that the RTOS will manage as
a queue. As with semaphores, it makes most sense to initialize queues
in some code that is guaranteed to run before any task tries to use
them.
 Since most RTOSs allow you to have as many queues as you want, you
pass an additional parameter to every queue function: the identity of
the queue to which you want to write or from which you want to read.

7
3
 Real Time Embedded Systems (A7422)

Message Queues Cont..

7
4
 Real Time Embedded Systems (A7422)

Message Queues Cont..

7
5
 Real Time Embedded Systems (A7422)

Message Queues Cont..

7
6
 Real Time Embedded Systems (A7422)

Message Queues Cont..

7
7
 Real Time Embedded Systems (A7422)

Message Queues Cont..

7
8
 Real Time Embedded Systems (A7422)

Message Queues Cont..

7
9
 Real Time Embedded Systems (A7422)

Message Queues Cont..

Pointers and Queues
 The obvious idea behind this style of RTOS interface is that one task can
pass any amount of data to another task by putting the data into a
buffer and then writing a pointer to the buffer onto the queue.

8
0
 Real Time Embedded Systems (A7422)

8
1
 Real Time Embedded Systems (A7422)

Message Queues Cont..

8
2
 Real Time Embedded Systems (A7422)

Mailboxes
 In general, mailboxes are much like queues.
 The typical RTOS has functions to create, to write to, and to read from
mailboxes, and perhaps functions to check whether the mailbox
contains any messages and to destroy the mailbox if it is no longer
needed.
 The details of mailboxes are different in different RTOSs.
Here are some of the variations that you might see:
 Although some RTOSs allow a certain number of messages in each
mailbox, a number that you can usually choose when you create the
mailbox, others allow only one message in a mailbox at a time. Once
one message is written to a mailbox under these systems, the mailbox
is full; no other message can be written to the mailbox until the first
one is read.

8
3
 Real Time Embedded Systems (A7422)

Mailboxes Cont..
 In some RTOSs, the number of messages in each mailbox is unlimited.
There is a limit to the total number of messages that can be in all of the
mailboxes in the system, but these messages will be distributed into the
individual mailboxes as they are needed.
 In some RTOSs, you can prioritize mailbox messages. Higher-priority
messages will be read before lower-priority messages, regardless of the
order in which they are written into the mailbox.
 For example, in multitask system each message is a void pointer. you
must create all of the mailboxes you need when you configure the
system, after which you can use these three functions
Int sndmsg(unsigned int uMbId, void *p_vmsg, unsigned int
uPriority);
Void *rcvmsg(unsigned int uMbId, unsigned uTimeout);
Void *chkmsg(unsigned int uMbId)
8
4
 Real Time Embedded Systems (A7422)

Mailboxes Cont..
 In the above all three functions uMbId parameter identifies the mailbox
on which to operate.
 The sndmsg function adds p_vmsg into the queue of messages held by
the uMbId mailbox with the priority indicated by uPriority .it returns an
error if uMbId is invalid or if too many messages are already pending in
mailboxes.
 The rcmsg function returns the highest-priority message from the
specified mailbox. It blocks the task that called it if the mailbox is
empty. The task use uTimeout parameter to limit how long it will wait if
there are no messages.
 The chkmsg function returns the first message in the mailbox. It returns
a NULL immediately if the mailbox is empty.

8
5
 Real Time Embedded Systems (A7422)

Pipes
 Pipes are also much like queues. The RTOS can create them, write to
them, read from them, and so on. The details of pipes, however, like
the details of mailboxes and queues, vary from RTOS to RTOS.
Some variations you might see include the following:
 Some RTOSs allow you to write messages of varying lengths onto pipes
(unlike mailboxes and queues, in which the message length is typically
fixed).
 Pipes in some RTOSs are entirely byte-oriented: if Task A writes 11 bytes
to the pipe and then Task B writes 19 bytes to the pipe, then if Task C
reads 14 bytes from the pipe, it will get the 11 that Task A wrote plus
the first 3 that Task B wrote. The other 16 that task B wrote remain in
the pipe for whatever task reads from it next.
 Some RTOSs use the standard C library functions fread and fwrite to
read from and write to pipes.
8
6
 Real Time Embedded Systems (A7422)

Pitfalls
 Most RTOSs do not restrict which tasks can read from or write to any
given queue, mailbox, or pipe. Therefore, you must ensure that tasks
use the correct one each time. If some task writes temperature data
onto a queue read by a task expecting error codes, your system will not
work very well. This is obvious, but it is easy to mess up.
 The RTOS cannot ensure that data written onto a queue, mailbox, or
pipe will be properly interpreted by the task that reads it. If one task
writes an integer onto the queue and another task reads it and then
treats it as a pointer, your product will not ship until the problem is
found and fixed.

8
7
 Real Time Embedded Systems (A7422)

Pitfalls Cont..
 Running out of space in queues, mailboxes, or pipes is usually a disaster
for embedded software. When one task needs to pass data to another,
it is usually not optional. For example, if the RTOS fail to report errors if
its queue filled, the data will be stored in garbage location which
cannot be identified, Good solutions to this problem is to make your
queues, mailboxes, and pipes large enough in the first place.
 Passing pointers from one task to another through a queue, mailbox, or
pipe is one of several ways to create shared data is not necessary in all
cases.

8
8
 Real Time Embedded Systems (A7422)

Timers
Timers are used to measure the elapsed time of events. For
instance, the kernel has to keep track of different times.
A particular task may need to be executed periodically, say,
every 10 msec. A timer is used to keep track of this periodicity.
A task may be waiting in a queue for an event to occur. If the
event does occur for a specified time, it has to take an
appropriate action.
A task may be waiting in a queue for a shared resource. If the
resource is not available for a specified time, it has to take an
appropriate action.

8
9
 Real Time Embedded Systems (A7422)

Timer Functions
 Most embedded systems must keep track of the passage of time.

 To extend its battery life, the cordless bar-code scanner must turn itself
off after a certain number of seconds.
 Systems with network connections must wait for acknowledgements to
data that they have sent and retransmit the data if an
acknowledgement doesn’t show up on time.
 One simple service that most RTOSs offer is a function that delays a
task for a period of time; that is, blocks it until the period of time
expires.

9
0
 Real Time Embedded Systems (A7422)

Timer Functions Cont..

9
1
 Real Time Embedded Systems (A7422)

Timer Functions Cont..

9
2
 Real Time Embedded Systems (A7422)

Timer Functions
Questions
 How do I know that the taskDelay function takes a number of
milliseconds as its parameter?
 You don’t. In fact, it doesn’t. The taskDelay function in VxWorks, like
the equivalent delay function in most RTOSs, takes the number of
system ticks as its parameter. The length of time represented by each
system tick is something you can usually control when you set up the
system.

9
3
 Real Time Embedded Systems (A7422)

Timer Functions
Questions
 How accurate are the delays produced by taskDelay function?
 They are accurate to the nearest system tick. The RTOS works by setting
up a single hardware timer to interrupt periodically, say, every
millisecond, and bases all timings on that interrupt. This timer is often
called the heartbeat timer. For example, if one of your tasks passes 3 to
taskDelay, that task will block until the heartbeat timer interrupts three
times. The first timer interrupt may come almost immediately after the
call to taskDelay or it may come after just under one tick time or after
any amount of time between those two extremes.(Note that the task
will unblock when the delay time expires; when it will run depends as
always upon what other, higher-priority tasks are competing for the
microprocessor at that time.).

9
4
 Real Time Embedded Systems (A7422)

Timer Functions

9
5
 Real Time Embedded Systems (A7422)

Timer Functions
 How does the RTOS know how to set up the timer hardware on my
particular hardware?
 It is common for microprocessors used in embedded systems to have
timers in them. Since RTOSs, like other operating systems, are
microprocessor-dependent, the engineers writing the RTOS know what
kind of microprocessor the RTOS will run on and can therefore program
the timer on it. If you are using nonstandard timer hardware, then you
may have to write your own timer setup software and timer interrupt
routine. The RTOS will have an entry point for your interrupt routine to
call every time the timer expires. Many RTOS vendors provide board
support packages or BSPs, which contain driver software for common
hardware components – such as timers - and instructions and model
code to help you write driver software for any special hardware you are
using.

9
6
 Real Time Embedded Systems (A7422)

Timer Functions
 What is a “normal" length for the system tick?
 There really isn’t one. The advantage of a short system tick is that you
get accurate timings. The disadvantage is that the microprocessor must
execute the timer interrupt routine frequently. a short system tick can
decrease system throughput quite considerably by increasing the
amount of microprocessor time spent in the timer interrupt routine.
Real - time system designers must make this trade-off.

9
7
 Real Time Embedded Systems (A7422)

Timer Functions
 What if my system needs extremely accurate timing?
 You have two choices. One is to make the system tick short enough that
RTOS timings fit your definition of “extremely accurate”. The second is
to use a separate hardware timer for those timings that must be
extremely accurate. The advantage of the RTOS timing functions is that
one hardware timer times any number of operations simultaneously.

9
8
 Real Time Embedded Systems (A7422)

Timer Functions
Other Timing Services
 Most RTOSs offer an array of other timing services, all of them based on
the system tick.
 For example, most allow you to limit how long a task will wait for a
message from a queue or a mailbox, how long a task will wait for a
semaphore, and so on. Although these services are occasionally useful .
 For example, if you set a time limit when your high - priority task
attempts to get a semaphore and if that time limit expires, then your
task does not have the semaphore and cannot access the shared data.
Then you’ll have to write code to allow your task to recover. Before
writing this code which is likely to be difficult, since your task needs to
use the data but can’t - it may make sense to ask whether there might
not be a better design.

9
9
 Real Time Embedded Systems (A7422)

Timer Functions
Other Timing Services
 If your high-priority task is in such a hurry that it cannot wait for the
semaphore, perhaps it would make more sense to send instructions
about using the shared data through a mailbox to a lower-priority task
and let the higher-priority task get on with its other work.
 A rather more useful service offered by many RTOSs is to call the
function of your choice after a given number of system ticks. Depending
upon the RTOS, your function may be called directly from the timer
interrupt service routine, or it may be called from a special, high-
priority task within the RTOS.

1
0
 Real Time Embedded Systems (A7422)

Events
 Another service many RTOSs offer is the management of events within the system.

 An event is essentially a Boolean flag that tasks can set or reset and that other

tasks can wait for.

 For example, when the user pulls the trigger on the cordless bar-code scanner, the

task that turns on the laser scanning mechanism and tries to recognize the bar-
code must start.
Some standard features of events are listed below:
 More than one task can block waiting for the same event, and the RTOS will

unblock all of them (and run them in priority order) when the event occurs.
 For example, if the radio task needs to start warming up the radio when the user

pulls the trigger, then that task can also wait on the trigger-pull event.
1
0
 Real Time Embedded Systems (A7422)

Events Cont..
 RTOSs typically form groups of events, and tasks can wait for any subset

of events within the group.

 Different RTOSs deal in different ways with the issue of resetting an

event after it has occurred and tasks that were waiting for it have been
unblocked.
 Some RTOSs reset events automatically; others require that your task

software do this.
 It is important to reset events: if the trigger-pull event is not reset, for

example, then tasks that need to wait for that event to be set will never
again wait.
1
0
 Real Time Embedded Systems (A7422)

A Brief Comparison of the Methods for Inter task Communication

 Methods to provide the communication between two tasks or

between an interrupt routine and a task are queues, pipes,
mailboxes, semaphores, and events.
 Semaphores are usually the fastest and simplest methods.
However, not much information can pass through a
semaphore, which passes just a 1-bit message saying that it
has been released.
 Events are a little more complicated than semaphores and
take up just a hair more microprocessor time than
semaphores.

1
0
 Real Time Embedded Systems (A7422)

A Brief Comparison of the Methods for Inter task Communication

 The advantage of events over semaphores is that a task can

wait for any one of several events at the same time, whereas
it can only wait for one semaphore. (Another advantage is that
some RTOSs make it convenient to use events and make it
inconvenient to use semaphores for this purpose.)
 Queues allow you to send a lot of information from one task
to another. Even though the task can wait on only one queue
(or mailbox or pipe) at a time, the fact that you can send data
through a queue make it even more flexible than events.

1
0
 Real Time Embedded Systems (A7422)

Memory Management
 Most RTOSs have some kind of memory management
subsystem.
 some offer the equivalent of the C library functions malloc and
free, real-time systems engineers often avoid these two
functions because they are typically slow and because their
execution times are unpredictable.
 They favor instead functions that allocate and free fixed-size
buffers, and most RTOSs offer fast and predictable functions
for that purpose.

1
0
 Real Time Embedded Systems (A7422)

Memory Management Cont..

 The MultiTask system is a fairly typical RTOS

 Memory is divided into Pools

 Each pool is divided into memory buffers

 All of the buffers are the same size

 The reqbuf and getbuf functions allocate memory buffer from a pool

 void *getbuf (unsigned int uPoolId, unsigned int uTimeout);

 void *reqbuf (unsigned int uPoolId);

 void relbuf (unsigned int uPoolId, void *p_vBuffer);

1
0
 Real Time Embedded Systems (A7422)

Memory Management Cont..

 In each of these functions, the uPoolId parameter indicates the pool

from which the memory buffer is to be allocated.

 The uTimeout parameter in getbuf indicates the length of time that

the task is willing to wait for a buffer if none are free.

 The size of the buffer that is returned is determined by the pool from

which the buffer is allocated, since all the buffers in anyone pool are
the same size. The tasks that call, these functions must know the sizes
of the buffers in each pool.
 The relbuf function frees a memory buffer.
1
0
 Real Time Embedded Systems (A7422)

Memory Management Cont..

 Initialization of memory is done by the below function in RTOS:

 int init_mem_pool (unsigned int uPoolId, void *p_vMemory, unsigned int uBufSize,

unsigned int uBufCount, unsigned int uPoolType);

1
0
 Real Time Embedded Systems (A7422)

Interrupt Routines in an RTOS Environment

 Interrupt routines in most RTOS environments must follow two rules that do not

apply to task code.

Rule-1:
 An interrupt routine must not call any RTOS function that might block the caller.

 Therefore, interrupt routines must not get semaphores, read from queues or

mailboxes that might be empty, wait for events, and so on.

 If an interrupt routine calls an RTOS function and gets blocked, then, in addition

to the interrupt routine, the task that was running when the interrupt occurred
will be blocked, even if that task is the highest- priority task.
 Also, most interrupt routines must run to completion to reset the hardware to be

ready for the next interrupt.

1
0
 Real Time Embedded Systems (A7422)

Interrupt Routines in an RTOS Environment Cont..

Rule-2:
 An interrupt routine may not call any RTOS function that might cause the

RTOS to switch tasks unless the RTOS knows that an interrupt routine, and
not a task, is executing.
 This means that interrupt routines may not write to mailboxes or queues on

which tasks may be waiting, set events, release semaphores, and so on - unless
the RTOS knows it is an interrupt routine that is doing these things.
 If an interrupt routine breaks this rule, the RTOS might switch control away

from the interrupt routine (which the RTOS think is a task) to run another task,
and the interrupt routine may not complete for a long time, blocking at least all
lower-priority interrupts and possibly all interrupts.
1
1
 Real Time Embedded Systems (A7422)

1
1
 Real Time Embedded Systems (A7422)

Interrupt Routines in an RTOS Environment Cont..

Rule-1: No Blocking
 we examine the software for the control of the nuclear reactor.

 This time, the task code and the interrupt routine share the temperature data with a

semaphore. This code will not work. It is in violation of rule 1.

 If the interrupt routine happened to interrupt vTaskTestTemperatures while it had the

semaphore, then when the interrupt routine called GetSemaphore, the RTOS would
notice that the semaphore was already taken and block.
 This will stop both the interrupt routine and vTaskTestTemperatures (the task that was

interrupted), after which the system would grind to a halt in a sort of one-armed
deadly embrace.
 With both the interrupt routine and vTaskTestTemperatures blocked, no code will ever

release the semaphore.

1
1
 Real Time Embedded Systems (A7422)

Interrupt Routines in an RTOS Environment Cont..

Rule-2: No RTOS Calls Without Fair Warning
 The interrupt routine interrupts the lower-priority task, and,

among other things, calls the RTOS to write a message to a

mailbox (legal under rule l, assuming that function can’t block).
 When the interrupt routine exits, the RTOS arranges for the

microprocessor to execute either the original task, or, if a

higher-priority task was waiting on the mailbox, that higher
priority task.

1
1
 Real Time Embedded Systems (A7422)

Interrupt Routines in an RTOS Environment Cont..

How Interrupt Routine Should Work

1
1
 Real Time Embedded Systems (A7422)

Interrupt Routines in an RTOS Environment Cont..

What Would Really Happen

1
1
 Real Time Embedded Systems (A7422)

Interrupt Routines in an RTOS Environment Cont..

 If the higher-priority task is blocked on the mailbox, then as soon as the

interrupt routine writes to the mailbox, the RTOS unblocks the higher-
priority task.
 Then the RTOS (knowing nothing about the interrupt routine) notices

that the task that it thinks is running is no highest-priority task that is

ready to run.
 Therefore, instead of returning to the interrupt routine (which the RTOS

thinks is part of the lower priority task), the RTOS switches to the
higher-priority task. The interrupt routine doesn’t get to finish until
later.
1
1
 Real Time Embedded Systems (A7422)

Interrupt Routines in an RTOS Environment Cont..

How Interrupt Routines Do Work

1
1
 Real Time Embedded Systems (A7422)

Interrupt Routines in an RTOS Environment Cont..

 In it, the RTOS intercepts all the interrupts and then calls your interrupt routine.

 By doing this, the RTOS finds out when an interrupt routine has started.

 When the interrupt routine later writes to mailbox, the RTOS knows to return to

the interrupt routine and not to switch tasks, no matter what task is unblocked by
the write to the mailbox.
 When the interrupt routine is over, it returns, and the RTOS gets control again.

 The RTOS scheduler then figures out what task should now get the microprocessor.

 If your RTOS uses this method, then you will need to call some function within the

RTOS that tells the RTOS where your interrupt routines are and which hardware
interrupts correspond to which interrupt routines.

1
1
 Real Time Embedded Systems (A7422)

Interrupt Routines in an RTOS Environment Cont..

How Interrupt Routines Do Work: Plan B

1
1
 Real Time Embedded Systems (A7422)

Interrupt Routines in an RTOS Environment Cont..

 Figure shows an alternative scheme, in which the RTOS provides a function that

the interrupt routines call to let the RTOS know that an interrupt routine is
running.
 After the call to that function, the RTOS knows that an interrupt routine is in

progress, and when the interrupt routine writes to the mailbox the RTOS always
returns to the interrupt routine, no matter what task is ready, as in the figure.
 When the interrupt routine is over, it jumps to or calls some other function in

RTOS, which calls the scheduler to figure out what task should now get the
microprocessor. Essentially, this procedure disables the scheduler for the
duration of the interrupt routine.
1
2
 Real Time Embedded Systems (A7422)

Interrupt Routines in an RTOS Environment Cont..

 Some RTOSs use a third mechanism: they provide a separate set of

functions especially for interrupt routines.

 So for example, in addition to OSSemPost, there might be

0SISRSemPost, which is to be called from interrupt routines.

 OSISRSemPost is the same as 0SSemPost, except that it always

returns to the interrupt routine that calls it, never to some other
task.
 In this method, the RTOS also has a function the interrupt routine

calls when it is over, and that function calls the scheduler.

1
2
 Real Time Embedded Systems (A7422)

Interrupt Routines in an RTOS Environment Cont..

Rule 2 and Nested Interrupts
 If your system allows interrupt routines to nest, that is, if a higher-priority interrupt

can interrupt a lower-priority interrupt routine, then another consideration comes into
play.
 If the higher-priority interrupt routine makes any calls to RTOS functions, then the

lower-priority interrupt routine must let the RTOS know when the lower-priority
interrupt occurs.
 Otherwise, when the higher-priority interrupt routine ends, the RTOS scheduler may

run some other task rather than let the lower-priority interrupt routine complete.
 Obviously, the RTOS scheduler should not run until all interrupt routines are complete.

1
2
 Real Time Embedded Systems (A7422)

Interrupt Routines in an RTOS Environment Cont..

Nested Interrupts and the RTOS

1
2