Real Time Operating

System (RTOS)
Prof. P.B.Borole
 Embedded Software
 Written by designer. Not by user.
 Designer must be expert in software and
hardware designs.
 Two types – Non real time and real time.
 The real time system processes events in short
time.
 Event occurred on system input causes other
event to occur as system output. E.g. Pressing
a key, change in temperature are the events.
 Real time system
 Design goals – Minimize response time
 - Improve reliability.
 - Increase security
 - Increase correctness at function level and
timing level.
 There are two types – Single task system and
Multitasking system.
 In single task system, RTOS is not required.
 Single task system software can be developed
in assembly language program.
 Real time System
 It is very difficult to develop multitasking software
without RTOS.
 Real time system software has many foreground and
background routines.
 Real time system handles two or more activities –
some activities are independent while some activities
are dependent. Some activities are synchronous while
some activities are asynchronous.
 Synchronous activity occurs at particular instant,
hence the CPU will not keep watch on this activity
continuously. RTOS may not be required.
 Asynchronous activity occurs at any time, hence CPU
has to keep watch on this activity continuously.
RTOS is required.
 Real Time System
 In real time system, the CPU has to handle
some activities in parallel.
 Some activities are periodic with short period
while some are with very large period.
 Activities have different priority of processing.
 Some activities must be processed in short
period while others can take more time.
 Some activities are event driven.
 Some activities are based on elapsed time.
 Real Time System
 The ordinary microcontroller programs are
sequential. These programs do all activities
sequentially. If any activity is blocked due
absence of external event, then the next
activities are stalled.
 In real time system, some activities should be
done in parallel.
 Each activity can be treated as a task.
 Multitasking -1
Sequential without interrupts:

Start

Initialize system
All tasks are synchronized.

The time taken by one task

affects on next task.
Task switching is not done
Hence this time is saved. Task 1
Task switching memory
Space is also saved Task 2
Each task uses only polled
IO.
Task N
All the tasks are invoked one
By one.
 All tasks are not
Multitasking - 2 synchronized.

Sequential with interrupts The time taken by one low

task affects on next low
Low priority tasks use polled Start
task.
IO while high priority task use Task switching is done
Interrupt IO Task1 to and task switching memory
Task N are low priority Initialize system is required.
Tasks. Interrupting tasks have
Interrupt latency
high priority.
is introduced.

Interrupts form Task 1 Low

Other tasks
High
Task 2 Low

Task N Low
All low priority tasks are
invoked one
By one. Used in small embedded system
 Multitasking - 3
Start

Initialize system

Interrupts form
all tasks
Wait for interrupts

In this case, all tasks are interrupt driven.

Many interrupts are required

Task switching is done Interrupt latency

and task switching memory is introduced.
is required.
 Multitasking - 4
Start In this case, all tasks are interrupt driven.
Timed
Interrupts Many interrupts are required
Initialize system

Task 1
Wait for interrupts

Task 2
The entire system is driven by a timed Task switching is done
Interrupts. and task switching memory
Task N
is required.

Return Interrupt latency

is introduced.
 Problems with Multitasking
 As number of tasks increases the complexity of the
system increases. Hence the system will fail.
 Some tasks require a very long or unpredictable
amount of time to complete, hence the system will
fail.
 Critical tasks cannot be executed without error. The
system will not work if some tasks are critical.
 It is very difficult to synchronize asynchronous tasks.
 If any change is made a task, the entire timing of the
system will fail. We have to recalculate program
timings.
 The calculation of program timing is difficult for
complex system.
 The system will not work for asynchronous inputs.
 Priorities of tasks cannot be changed dynamically.
 RTOS
 All the problems of multitasking are solved by RTOS (
Real Time Operating System).
 Two types – Soft real and Hard real
 Soft Real time system computes the response as fast as
possible but does not know dead line.
 Hard real time system imposes dead line on each task.
 The processor executes tasks on time sharing basis.
 Task is a job to be done. Each task has two or more
threads. Thread is a sequence of instructions.
 Threads run concurrently and independently.
 Threads simplify software development and maintenance.
 RTOS provides systematic way of allocating resources.
 It simplifies multitasking software development and
saves development time.
 RTOS
 Each thread is treated as an infinite loop.
 Code thread 1
{

}
Code thread 2
{

}
 RTOS
 In RTOS, interrupts instruct task code to do work. On conventional
OS, the OS takes help from the interrupt.
 The necessary signaling between the ISR and the task code is
handled by the RTOS. Shared variable should not be used.
 User code does not decide what needs to be done next. RTOS
decides which of the task code function should run.
 RTOS knows about the various task code subroutine and will run
most urgent routine at any given time.
 The RTOS can suspend one task code subroutine in the middle.
 The RTOS can control task code response and ISR response.
 RTOS arranges priorities of ISRs and priorities of task code ( 256
levels).
 The system response will not change even if we change the task
code.
 Most complicated OS.
 RTOS can be background program.
 RTOS
 RTOS identifies time critical tasks.
 RTOS schedules the tasks in such a way that all the tasks are
completed and meets the dead line of time critical task.
 RTOS decides when to send interrupt to the processor.
 RTOS identifies the shared resources and solves shared resources
problems.
 RTOS manages inter task communication.
 RTOS keeps track of the time.
 Manages memory.
 We can compile and link application program separately from the
OS.
 Application programs and RTOS are tightly coupled.
 RTOS does not protect itself from application program. Hence the
bad application program crash whole system.
 Interrupt latency is low.
 Deterministic OS i.e. worst case response time can be predicted.
 RTOS
 We can configure RTOS.
 We can write our own RTOS.
 Follows POSIX standard developed by IEEE. I.e. API commands are
POSIX standard. Hence application developed for one RTOS is
portable with other RTOS.
 Provides TCP/IP support for network related services.
 Provides device drivers.
 Kernel requires few kilobytes.
 Supports many processors.
 It can be hardware based OS.
 It may not be royalty free OS because the designer is going to
download Application program and RTOS kernel into ROM of the
embedded system.
 Priority of Tasks can be changed dynamically.
 Divided into three categories – Embedded OS, RTOS and Mobile OS.
 RTOS
 Concept of RTOS:
 What is Task?

 Task is basic building block of software. Each task

compete for the CPU time independently. Each task
will have its own stack area.
 Task can be subroutine.

 Each task is implemented as an infinite loop

 for ( ; ; ) while (1)

{ {
statements or statements
} }
 RTOS
 Each task has priority
 Each task is divided into threads. Each thread runs
independently but multiple threads in a task can share
variables.
 Task has its own name, a unique ID, a priority, a stack,
memory block or register set and a task control block
(TCB) or processor control block.
 A task can generate signals, semaphores or mutex.
 Embedded software consists of OS task and application
task.
 A task cannot call another task but it calls the functions
to implement certain action.
Embedded software architecture
Application software

Application programming interface

Communication software

File system
Kernel OS
Libraries Device manager
 RTOS
 Kernel is the heart of the OS.
 Manages tasks through scheduling to achieve
desired performance.
 Provides inter task communication.
 Kernel consists of objects such as tasks, mutexes,
ISRs, events, message box, mail boxes, pipes and
timers.
 Kernel provides memory management services,
interrupt handling services and device management
services.
 Device manager manages the IO devices through
interrupts and device drivers.
 RTOS
 Communication software consists of
communication interfaces such as Ethernets, USB
protocols, TCP/IP stack etc. This is optional.
Required in networked embedded system.
 Libraries may have some C/C++ library files in
object code which can be used through API calls.
 File system divides flash memory into small files
and manages these files.
 API is used to develop application software on
RTOS.
 Kernel Architecture
Message queues

Signals
Event registers

Mail boxes

Scheduler
ISRs
Pipes

Timer
System tasks

Mutexes
Semaphores
 Kernel
 Kernel has its own system tasks with priorities.
 The kernel tasks are start up task, exception
handling tasks, Log In task and Idle task.
 Idle task – If no task is running, then idle task is
executed so that the CPU is always engaged. Low
priority.
 All tasks have to share the CPU time in discipline
manner.
 Task states – At a time only one task is being
executed by the CPU whereas other tasks are
waiting for external events or waiting for CPU
time.
 RTOS state diagram

Ready to run

Running

Interrupt Interrupt exit

Waiting

ISR
 State diagram
 Running: Only one task will be in this state at
a time in single processor system. In
multiprocessor system, this state is assigned to
two or more tasks.
 Waiting or blocked: In this state CPU was
available, but task wants to wait for external
event. Any number of tasks can be in this state.
 Ready to run: Task is ready but waiting for
CPU time. Any number of tasks can be in this
state.
 kernel
 Task scheduling – Only one CPU has to handle multiple
tasks. All tasks have to share the CPU time in discipline
manner.
 Task should not take long time.
 Critical task should have higher priority.
 Task scheduler decides which task will get CPU time next.
 All the time dead line should not be violated.
 In deterministic OS, the time required to execute the task
can be estimated.
 Scheduler keeps the track of the state of each task.
 Task has full control on scheduler in RTOS. In ordinary
OS this is not possible.
 The scheduler of RTOS is simple minded. In desk top OS,
the scheduler is strict minded.
 Kernel
 Tasks have to share the system resources such as CPU
registers, external memory and IO devices.
 In RTOS, two tasks can be written independently of one
another and system will still respond well.
 RTOS has its own private data structure which is not
available to any of task.
 Task scheduling Algorithm –
 1 FIFO. Executes tasks on first come first served basis.
 2 Round robin. Executes tasks in round robin fashion.
 3 Round robin. Executes tasks in round robin with priority
except that the high priority task can interrupt low priority
task.
 kernel
 4 Shortest Job first. Highest priority is assigned to short job
and lowest priority is assigned to long job.
 Algorithm 1 to 4 are used in soft real kernel.
 5 Non preemptive. Called cooperative. The high priority
task can its CPU time to low priority task for completion.
 The priority of current task is respected by the other task.
But high priority task has to wait for long time. This is not
suitable for real time embedded system.
 6 Preemptive. The high priority task suspends execution
of low priority task if CPU time is allocated to it.
 The preemptive kernel is deterministic. It is used in real
time system.
 RTOS
 Mutual exclusion : When two or more tasks access
shared resources without corrupting data is called
Mutual exclusion.
 Semaphores: used for shared resources and task
synchronization.
 Resource synchronization -
Display

Task 1 Display
Task 2 Display humidity
temperature

There should be proper discipline to share display for task 1 and task 2
 RTOS
 Task Synchronization:

ADC Task to write data Task to read the data DAC

Memory

Semaphore is a kernel object. It is like a key. The task takes

Semaphore to access shared resource. The task releases semaphore
After accessing resources
The allocation of semaphore is done on the basis of priority or first
come first served basis.
Semaphore is just an integer.
 RTOS
 Two types:-
 1 Counting semaphore
 2 Binary semaphore
 Counting semaphore will have integer value greater
than one. Whenever task acquires semaphore the
value is decremented by one. When task releases
semaphore the value is incremented by one.
 Binary semaphore will take the value of either 0 or
1.
 0 = not available ; 1 = available
 Counting semaphore is equivalent to having
multiple keys to enter a house.
 RTOS
 Multiple Semaphores –
 Draw backs of single semaphore – Single
semaphore is common for all shared resources. The
single semaphore blocks other shared resources. If
the semaphore is with low priority then high
priority task is blocked.
 Some RTOSes provide multiple independent
semaphores.
 In multiple semaphores, each shared resource has
its own semaphore.
 The semaphore assigned to each shared resource is
unknown to RTOS.
 RTOS
 Mutex is a special binary semaphores
 Mutes has owner. Mutex is not released by another task
while binary semaphore is released by any other task.
 The owner can lock mutex n times, but it has to release it
n times.
 Mutex is powerful than semaphore.
 A task owning mutex cannot be deleted.
 A time limit can be set for mutex and semaphore to avoid
dead lock
 The dead lock occurs when two or more tasks wait for
resource being held by another task.
 RTOS
 Some additional services available on commercial RTOSes are inter
task communication, timer services, memory management, event
management and the interaction between ISR and RTOS.
 Inter task communication – Message queues, mailboxes and pipes.
 The RTOS queue is used to report errors to the control station. The
queue is initialized by RTOS.
 Some RTOSes provide many queues.
 Queues are used to transfer data from one task to another task.
 Mail boxes – Task can have mail box into which other task or ISR
can post a mail.
 Some RTOSes allow a certain number of messages in each mail box.
 In RTOSes we can prioritize mailbox messages.
 Message queue – It can be considered as an array of mail boxes.
 At the time of creating a queue, the queue is given a name or ID,
queue length, sending task , waiting task and receiving task.
 RTOS
 Event registers:- A task can have an event register
in which the bits corresponding to different events.
1 0 1 1 0 0 1 0 0 1 1 1 1 0 0 1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Task 1 Task 3 Task 4 Task 7
16 bits are divided into four portions corresponding to the events of the
tasks and ISR.
Each bit is also called event flag.
The meaning of each bit is defined a task.
 RTOS
 System clock:- It is also called a clock tick which
interrupts RTOS regularly.
 It generates a time out for a task at regular
intervals.
 It different from CPU clock.
 It decides CPU time to be allocated to a task.
 RTOS
 Pipes:- Pipe is a special case of queue
 A pipe can be unlimited.
 Used to transfer data from one task to another task.
 Used to transfer data from ISR to task.
 Writing a pipe is equivalent to C command fwrite
file name.
 Reading a pipe is equivalent to C command fread
file name.
 In UNIX or Linux we can use pipes as shell
commands
 RTOS
 Signals:-
 It can be passed to indicate event.
 It is a way of messaging.
 But it provides shortest message.
 Takes shortest CPU time.
 The signals are the flags that are used for the IPC (inter
processor communication) functions of synchronization.
 The signal is a flag that activates interrupt.
 The signal flag is shared by the ISR.
 A signal raised by one process forces another process to
interrupt.
 Many RTOSes do not support signals.
 RTOS requires additional memory. The task switching
time increased.
 RTOS API commands
 Task management and function Calls –
 Create task, delete task, suspend task, resume task,
change priority of task, query a task.
 Mutex management function calls-
 Create mutex, delete mutex, acquire mutex, release
a mutex, query a mutex, wait on mutex.
 Mail box function calls:-
 Create a mail box, delete a mail box, query a mail
box, post a message in a mail box, read a message
from a mail box.
 RTOS API commands
 Message queue management function calls:-
 Create a queue, delete a queue, flush a queue, post a
message in queue, post a message in front of queue, read
message from queue, broadcast message, show queue
information, show queue waiting list.
 Event register management function calls:-
 Create an event register, delete an event register, query an
event register, set an event flag, clear an event flag.
 Functions call for Pipe:-
 Create a pipe, open a pipe, clear a pipe, read from the
pipe, write to the pipe.
 RTOS
 TCB-
 It saves state signal mask, priority number, context (stack
pointer and return address)

Task ID
Task Name
Task state ‘Reset ‘ for disabling task run.
‘Set’ for enabling run.
Event awaited
Signal mask
Timer setting
Stack pointer
Return address
 RTX51
 RTX51 is a multitasking real-time operating system for
the 8051 family of processors.
 RTX51 simplifies software design of complex, time-
critical projects.
 There are two distinct versions of RTX51 available:
 RTX51 Full : Performs both round-robin and
preemptive task switching using up to four task
priorities.
 RTX51 works in parallel with interrupt functions.
 Signals and messages may be passed between tasks
using
 a mailbox system.
 You can allocate and free memory from a memory pool.
 You can force a task to wait for an interrupt, timeout, or
signal or message from another task or interrupt
 RTX51
 RTX51 Tiny: Is a subset of RTX51 that will
easily run on single-chip 8051 systems without
any external data memory.
 RTX51 Tiny supports many of the features
found in RTX51 with the following
exceptions:
 RTX51 Tiny only supports round-robin and
the use of signals for task switching.
 Preemptive task switching is not supported.
 No message routines are included. No memory
pool allocation routines are available.
 RTX51
 Many microcontroller applications require simultaneous
execution of multiple jobs or tasks.
 For such applications, a real-time operating system
(RTOS) allows flexible scheduling of system resources
(CPU, memory, etc.) to several tasks.
 RTX51 implements a powerful RTOS which is easy to use.
 RTX51 works with all 8051 derivatives.
 You write and compile RTX51 programs using standard C
constructs and compiling them with C51.
 Only a few deviations from standard C are required in
order to specify the task ID and priority.
 RTX51 programs also require that you include the real-
time executive header file and link using the BL5
Linker/Locator and the appropriate RTX51 library file.
 RTX 51
 The system clock for RTX 51 full is set between
1000 and 40000 cycles per second.
 RTX 51 Tiny is set between 1000 and 65535 cycles
per second.
RTX51 Tiny uses the standard 8051 Timer 0 (mode 1) to generate a
periodic interrupt.
This interrupt is the RTX51 Tiny Timer Tick. Timeout and interval
values specified for the RTX51 Tiny library routines are measured
using the RTX51 Tiny Timer Tick.
RTX51 tiny supports a maximum of 16 tasks.
Tasks are simply C functions that have void return type and
void argument.
 RTX 51
 Task syntax
 void func (void) _task_ task_id
 func - name of the task function.
 task_id is id number of task
 void job0 (void) _task_ 0
 { while (1)
 { counter0++; /* increment counter */ }
 }
 All tasks should be implemented as endless loops. A task
should never return.
 There is no main function.
 RTX 51
 Signal is used to synchronize all tasks to run the software.
 In RTX 51, the task can be in ready, deleted, running, time
out and waiting states.
 The number of semaphores in RTX 51 full is maximum 8
(binary semaphores). Semaphores are not available in
RTX51 tiny.
 RTX51full has a maximum 8 mail boxes. The message can
be a maximum length of 8 integers.
 Message boxes are not available in tiny version.
 RTX 51 uses standard C constructs.
 RTX 51 is compiled by C51.
 #include <rtx51tny.h> or #include < rtx51full.h> should be
included in C program.
 RTX 51
 RTX 51 tiny has 900 bytes of code. It requires on chip 7
bytes of RAM and 3 bytes per task indirectly addressable
data RAM.
 Programming rules:
 1Be sure to include the RTX51TNY.H header file.
 2Do not create a main C function. RTX51 Tiny has its own
main function. The main C function is included in the
RTX51 Tiny Library to start the operating system and task
0.
 3You program must contain at least one task function.
 4Your program must call at least one RTX51 Tiny library
routine (like os_wait). Otherwise, the linker will not
include the RTX51 Tiny Library.
 RTX 51
 5Task 0 is the first function in your program that
executes. You must call the os_create_task function
from task 0 to run other tasks.
 6Task functions must never exit or return.
 7The task must repeat using a while(1) or similar
construct.
 8Use the os_delete_task function to halt a running
task.
 9You must specify RTX51 Tiny in µVision2 or on
the linker command line.
 RTX 51
 µVision2 IDE
 To create RTX51 Tiny programs with
µVision2...
 Open the Options for Target dialog (select
Options for Target from the Project menu).
 Select the Target tab.
 Select RTX-51 Tiny from the Operating
System option list.
 For debugging select RTX51 Tiny Task list
from the Peripherals menu to display the
dialog. The example of RTX51
RTX 51 example
 The os_wait Function

 The os_wait function provides a more efficient

way to allocate the available processor time to
several tasks.
 os_wait interrupts the execution of the current
task and waits for the specified event.
 During the time in which a task waits for an event,
other tasks can be executed.
Os_wait function
 Os_wait
 Wait for Signal
 Another event for os_wait is a signal. Signals
are used for task coordination:
 If a task waits with os_wait until another task
issues a signal.
 If a signal was previously sent, the task is
immediately continued.
Os_wait
 RTX51 Tiny2
 RTX51 Tiny Version 2 includes many new features that
make real-time software development easier.
 Code Banking Support
RTX51 Tiny now supports code banking. This option must
be enabled in the CONF_TNY.A51 configuration file.
 Explicit Task Switching
A new function (os_switch_task) allows a task to
immediately perform a task switch to another task that is in
the READY state.
 Task Ready Flag
New RTX51 Tiny library routines, isr_set_ready and
os_set_ready, allow you to set the READY flag for a task.
 RTX51 Tiny2
 CPU Idle Mode Support
RTX51 Tiny now allows you to enter Idle Mode (available
on many devices) inside the Idle Task.
 User Code Support in Timer Interrupt
You may now add your own code to the RTX51 Tiny Timer
Tick Interrupt. You may use the same fixed clock rate as
RTX51 Tiny for your own routines. This option must be
enabled in the CONF_TNY.A51 configuration file.
 Interval Adjustment Support
The os_reset_interval function allows you to adjust the
timeout value for an interval when mixing intervals and
signals in calls to the os_wait routine.
 .
 RTX51 Tiny2
 RTX51 Tiny has been completely restructured to
gain flexibility, accelerate performance, and reduce
code and data space requirements.
 RTX51 Tiny Version 2 is scalable and shows
significant code size reductions when the following
conditions are met.
 Round-Robin Task Switching is disabled.
 Few RTX51 Tiny system functions are used.
 Stack Checking is disabled.
 Disabling Round-Robin Task Switching also
reduces data space requirements
 RTX51 Tiny2
 Interrupts
 RTX51 Tiny works in parallel with your interrupt
functions. Interrupt service routines may
communicate with RTX51 Tiny tasks by sending
signals (using the isr_send_signal function) or by
setting a task's Ready flag (using the isr_set_ready
function).
 Interrupt routines must be implemented and enabled
in your RTX51 Tiny application as they would be in
a standard, non-RTX51 Tiny application. There is
no interrupt service routine management in RTX51
 RTX51 Tiny2
 RTX51 Tiny uses Timer 0, the Timer 0 interrupt,
and register bank 1. If your program uses Timer 0
the RTX51 Tiny kernel will not function correctly.
You may append your own Timer 0 ISR code to the
end of the RTX51 Tiny Timer 0 ISR.
 RTX51 Tiny assumes that global interrupts are
always enabled (EA=1).
 RTX51 Tiny library routines change the state of the
interrupt system (the EA bit) as needed to ensure
that RTX51 Tiny internal structures are not
corrupted by interrupts.
 RTX51 Tiny2
 When enabling and disabling global interrupts,
RTX51 Tiny simply changes the state of EA.
 It does not save and restore EA.
 EA is simply set or cleared.
 Therefore, if your program disables interrupts prior
to calling an RTX51 routine, RTX51 may fail to
respond.
 Disabling interrupts for brief periods of time may be
required for critical sections in your program.
However, you may not invoke any RTX51 Tiny
routines with interrupts disabled.
 RTX51 Tiny2
 Reentrant Functions
 RTX51 Tiny does not contain any management for
the C51 reentrant stack. So, if you use reentrant
functions in your application, you must ensure that
these functions do not call any RTX51 Tiny system
functions and that reentrant functions are not
interrupted by round-robin task switching.
 Non-reentrant C functions may not be called from
more than one task or interrupt procedure.
 You may invoke non-reentrant functions from
multiple tasks if you ensure that they are not called
recursively (simultaneously).
 RTX51 Tiny2
 You should disable Round-Robin Task Switching if
you wish to invoke reentrant or non-reentrant
function from more than one task or interrupt.
 Multiple Data Pointers:
 You should disable Round-Robin Task Switching if
you wish to use multiple data pointers.
 Arithmetic Units:
 You should disable Round-Robin Task Switching if
you wish to use an arithmetic unit.
 RTX51 Tiny2
 Register Banks:
 RTX51 Tiny assigns all tasks to register bank 0. For
this reason, all task functions must be compiled with
the default C51 setting, REGISTERBANK (0).
 Interrupt functions may use the remaining register
banks. However, RTX51 Tiny requires 6 permanent
bytes in the register bank area. The register bank
used by RTX51 Tiny for these bytes may be
specified in the configuration file.
 The duration of a time slice may be defined by the
RTX51 Tiny Configuration.
 RTX51 Tiny2
 Stack Management
 RTX51 Tiny maintains a stack for each task using
only the internal memory (IDATA) of the 8051.
When a task is running, it is given the maximum
amount of stack space possible. When a task switch
occurs, the previous task stack is shrunk and
relocated and the stack for the current task is
expanded and relocated.