Embedded Systems

Course code:16CS402

Real-Time Operating Systems

By
G. S. R. Satyanarayana
Department of ECE
VFSTR Deemed to be University
Introduction to RTOS
In RTOS the OS deliver its functions on
timely basis.

How to pronounce?
“Are toss”

Others use the terms kernel, real-time

kernel or RTK.
RTOS vs Desktop OS.
Desktop OS/GPOS RTOS
Takes control of machine as In boot up time the
soon as it turned ON. Then it application usually gets the
lets you start the application. control. And it then starts the
RTOS.

You compile, link applications In ES, you usually link your

separately from the OS. application and the RTOS.

Thus APPLICATION and RTOS are much tightly tied

to one another. Which is not true in GPOS.
RTOS vs Desktop OS Cont.
Desktop OS/GPOS RTOS
Protect themselves from Do not protect
the applications. themselves from the
applications.

Any pointer passed into the system function is checked in

case of GPOS. For better performance this step is avoided in
RTOS.
RTOS vs Desktop OS Cont.
Desktop OS/GPOS RTOS
Typically includes all Only includes the
services. services required for
embedded systems.

• Most RTOSs allow you to configure them

extensively before you link them to
application.
• Saves lots of memory.
Example RTOSs
 VxWorks, VRTX, pSOS, RTAI, QNX, uC/OS, AMX,
FreeRTOS, ChibiOS/RT.
 One can design their own RTOS.
 Commercial RTOSs offers good speed, code size,
robustness.
 They are tested extensively.
 Collection of features and tools are more.
Tasks and Task States
 Basic building block of software written in RTOS is
task.
 It is simply a subroutine.
 A function call to RTOS starts the execution of task.

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

1. Running- microprocessor executing the instructions
that make up this task
2. Ready- some other task is in running state
3. Blocked- has not got anything to do right now, even if
the microprocessor is available.
Tasks and Task States Cont.

 The other task states include:

• Suspended
• Pended
• Waiting
• Dormant
• Delayed
Tasks and Task States Cont.
The Scheduler:
• Keeps track of the state of each task.
• Looks at priority of tasks in ready state,
the one with highest priority runs.
• RTOS does not alter the assigned
priorities, even though a task is waiting
too long for the microprocessor has to
wait.
Tasks and Task States Cont.
Whatever the
task needs,
happens
Blocked READY

This is the Another

highest priority ready task is
ready task higher
This needs priority
something to
happen before it
can continue
RUNNING

Fig: Task states

Tasks and Task States Cont.
 How does the scheduler know when a task has become blocked
or unblocked?

 What happens if all tasks are blocked?

 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?
A Simple example
Tasks and Task States Cont.
vLevelsTask is busy User presses button; vButtonTask vButtonTask
calculating RTOS switches Does everything it Finishes its work and
While vButtonTask microprocessor to needs to do to blocks again; RTOS
is blocked vButtonTask; respond to the switches
vLevelsTask is ready. button. microprocessor back
to vLevlsTask.

vButtonTask

vLevelsTask

Time

Fig: Microprocessor Responds to a button under an RTOS

Tasks and Task States Cont.

Fig: RTOS Initialization Code.

Task and Data
 Each task will have its own context.
 Which includes register values, program counter.
 The other data such as static, global, initialized and
uninitialized data are shared among tasks.
 The RTOS typically has its own private data, which are
not available to other tasks.
Tasks and Data

Fig: Data in an RTOS-Based Real-Time Systems.

Shared-Data
Fig: Tasks share code.
Tasks and data cont.
 Reentrancy:
Reentrant functions are functions that can be
called by more than one task and that will
always work correctly.
Tasks and data cont.
 Rules to decide a function is reentrant:
1. A reentrant function may not use variable in a
nonatomic 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 nonatomic way.
Semaphores and Shared Data
To counter shared data problem RTOS provides a tool
called Semaphore.

Fig: Semaphore.
Semaphores and Shared Data Cont.
RTOS Semaphores:
• No RTOS uses the terms raise and lower;
they use give, take and release, pend and
post, p and v, wait and any other
combinations.
• We use take for lower and release for raise.
• Most commonly used semaphore is binary
semaphore, which is most similar to the
railroad semaphore.
Semaphores and Shared Data Cont.
• RTOS function call TakeSemaphore is used
to take semaphore.
• RTOS function call ReleaseSemaphore is
used to release semaphore.
• Any other task that calls TakeSemaphore
will block until the first task calls
ReleaseSemaphore.
• Only one task can have the semaphore at a
time.
Fig: Semaphore Protect Data.
Semaphore Problems
Task A gets a message Task A tries to take
Task C takes a
In its queue and the semaphore that
semaphore that it
unblockes; RTOS Task C already has
shares with Task A
switches to Task A taken

Task B gets a message Task B goes on running and

In its queue and running and running never
unblockes; RTOS gives Task C a chance to release
switches to Task B the semaphore. Task A is
Task A blocked

Task B

Task C

Time

This problem is called Priority inversion problem

Solution?
• Priority Inheritance: Temporarily boost the
priority of Task C to that of Task A whenever Task
C holds the semaphore and Task A waiting for it.
• Some RTOSs offer one kind of semaphore called
mutex semaphore, which automatically deal
with this problem.
Deadly Embrace
Semaphore variants
 Counting semaphore:
• Some systems offer semaphores that can be
taken multiple times.
• Taking them decrement the integer and
releasing them increments integer.
• When the integer is equal to zero then the task
tries to take it will be blocked.
 mutex semaphore
 Binary semaphore
Message Queues
 Tasks must communicate with one another to
coordinate their activities or to share data.
 Suppose two tasks Task1 and Task2 each of which has a
number of high-priority, urgent things to do.
 Suppose time to time they need to send encountered
error conditions on a network, which is a time
consuming process.
 In order not to delay Task1 and Task2 it makes sense to
create a third task which reports the error to network.
Message Queues
 Initializing queue is required before using them.
• memory allocation for queues is performed by user.
• Initialization is required before any task tries to use it.
 Additional parameter for queue identification
• Many queues can be created and used
• Using this one can identify a queue from which one
can read or wright.
 Code tries write when queue is full
• Either return error or block the task
Message Queues
 Reading an empty Queue
• Return error code
• Block the task
 The amount data one want to write to the queue and
size of the queue.
• One common characteristic is to allow you to write onto a
queue in one call the number of bytes taken up by a void
pointer.
Mailboxes
 Much like queues.
 Typical RTOS functions:
• Create
• Write to
• Read from
• Check message
Mailboxes
 While creating some RTOSs allow to chose capacity of
mail boxes.
 Most use single message per mailbox.
 Once full no other message can be written.
 In some RTOSs number of messages in each mailbox is
unlimited.
 In some RTOSs one can prioritize mailbox messages.
Mailboxes
 Example:
Pipes
 Much like queues
 Typical RTOS functions
• Create
• Write
• read
Pipes
 Some RTOSs allow you to write messages of varying
lengths
 Pipes in some RTOSs are entirely byte-oriented

 Some RTOSs use the standard C library functions fread

and fwrite to read from and write to pipes.
Thank you
Timer Functions
 Most embedded systems must keep track of the
passage of time.
Example:
• Switch off the bar coder reader after certain time.
• System with network connection must wait for
ack.
• Wait for robot arms to move.
Timer functions cont.
 Most RTOSs offers a function that delays a task for a
period of time; that is, blocks it until the period of time
expires.
Example:
“taskDelay” function offered by VxWorks.

 Most of the RTOSs takes system ticks as delay function

parameter.
 The RTOS works by setting up a single hardware timer
periodically.
Timer Functions cont.
 The accuracy of taskDelay function is nearest to
system tick.

vTaskDelay (3) Task delay ends at vTaskDelay (3) Task delay ends at
Starts task delay. Timer interrupt. Starts task delay. Timer interrupt.

2.93 ticks 2.16 ticks

1 System tick
Timer interrupts
Timer functions cont.
 What is the normal length of system tick?
• Short length gives accurate timings, but microprocessor has to
execute the instructions frequently.
• Designer has to consider this trade-off

 What if system needs extremely accurate timing?

• One way is to make system tick short enough to fulfil the
accuracy requirement.
• Use a dedicated timer for accurate timing applications.
Events
 An event is a Boolean flag that tasks can set or reset
and other tasks can wait for.
 Features:
• More than one task can block waiting for the same event.
• RTOSs typically forms groups of events, and tasks can wait
for any subset of events within the group.
• Some RTOSs reset events automatically; others require
that your task software do this.
Memory Management
 Even though some of the RTOSs offer the equivalent C
library functions malloc and free for management of
memory. Engineers wont use them for their
unpredictable response time.
 Instead they use functions that allocate and free fixed-
size buffers, which are fast and predictable.
 Example:
• In Multi Task! OS memory is organized as pools, each pool
consists of number of buffers.
• In a given pool, all the buffers are the same size.
Memory Management
 Request buffer example:

void *getbuf (unsigned int uPoolId, unsingned int

uTimeout);

void *reqbuf (unsigned int uPoolId);

• The size of the buffer depends on the pool which we have

selected.
Memory Management
 The relbuf frees a memory buffer.
void relbuf (unsigned int uPoolId, void *p_vBuffer);

 The user has to pass information about the memory, so that

RTOS manage pool of memory buffers.

 Init_mem_pool function allows to do this

Int init_mem_pool{
unsigned int uPoolId,
void *p_vMemory,
unsigned int uBuffSize,
unsigned int uBufCount,
unsigned int uPoolType
};
Memory management
Interrupt routines in an RTOS
environment
 The interrupt routines in most RTOS environments
must follow two rules:

 Rule1: Interrupt routine must not call any RTOS

function that might block caller.

 Rule2: 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.
Interrupt routines in an RTOS
environment
 Rule 1: No blocking

Take semaphoreA
SemaphoreA is
shared with a
with TaskH and
TaskHigh.
not released.

ISR

RTOS

Task

Time
Interrupt routines in an RTOS
environment
 Rule 2: No RTOS calls without fair warning

ISR

RTOS

Send Message
TaskHigh
to mailbox.

TaskLow

Time
Fig: How interrupt routines should work
 Rule 2: No RTOS calls without fair warning

ISR

RTOS
Send
TaskHigh Message to
mailbox.
TaskLo
w

Time

Fig: What would really happen

 Solution 1: RTOS intercepts all the interrupts and then
calls your interrupt routine.
 Here, you will need to call some function within RTOS
that tells the RTOS where your interrupt routines are,
and which hardware interrupts corresponds to which
interrupt routines.
ISR
Call Return
RTOS

TaskHigh Send
Message to
TaskLo mailbox.
w

Time
Fig: How interrupt routines do work
 Solution 2: RTOS provides a function that the interrupt
routines call to let the RTOS know that an interrupt
routine is running.
 This procedure disables scheduler for entire duration of
the interrupt routine.

ISR
Jump or call
RTOS
Enter Send
TaskHigh
Interrupt Message to
routine mailbox.
TaskLow

Time
Fig: How interrupt routines do work
 Solution 3: Some RTOSs provides separate set of
funcitons especially for interrupt service routines.
 Example: In addition to OSSemPost, there might be
OSISRSemPost.
 Rule 2 and Nested Interrupts

RTOS schedular goes to TaskHigh

Instead of finishing low-priority ISR.
High-priority
ISR

Low-priority
ISR
RTOS
High Priority Send Message
TaskHigh
Interrupt to mailbox.
Occurs.
TaskLow

Time
Thank you