Real Time Operating System

Prof. Anish Goel, Assistant Professor, RCOEM

Real-Time Operating System
 “Real-Time Operating System (RTOS) is a multitasking
operating system intended for real-time applications.” .
 RTOS is implemented in products all around us, ranging
from military, and consumer to scientific applications.
 RTOS comprises of two components, namely, “Real-
Time” and “Operating System”.

 Real-Time
 Real-Time indicates an expectant response or
reaction to an event on the instant of its evolution.
 The expectant response depicts the logical correctness of the
result produced.
 The instant of the events’ evolution depicts deadline for
producing the result.

2 RTOS Concepts By Prof. Anish Goel

Operating System
 Operating System (OS) is a system program that
provides an interface between hardware and application
programs.
 OS is commonly equipped with features like:
Multitasking, Synchronization, Interrupt and Event
Handling, Input/ Output, Inter-task Communication,
Timers and Clocks and Memory Management to fulfill its
primary role of managing the hardware resources to meet
the demands of application programs.
 RTOS is therefore an operating system
that supports real-time applications and
embedded systems by providing logically
correct result within the deadline required.
 Such capabilities define its deterministic
timing behavior and limited resource utilization nature.
3 RTOS Concepts By Prof. Anish Goel
Why RTOS for Real-Time Application
 RTOS is not a required component of all real-time application in
embedded systems.
 An embedded system in a simple electronic rice cooker does not
require RTOS.
 But as the complexity of applications expands beyond simple tasks,
benefits of having an RTOS far outweigh the associate costs.
 Embedded systems are becoming more complex hardware-wise with
every generation.
 And as more features are put into them in each iteration, application
programs running on the embedded system platforms will become
increasingly complex to be managed as they strive to meet the
system response requirements.
 An RTOS will be effective to allow
the real-time applications to be
designed and expanded more easily
whilst meeting the performances required.

4 RTOS Concepts By Prof. Anish Goel

Real-Time Embedded System with RTOS

5 RTOS Concepts By Prof. Anish Goel

Classification of RTOS
 RTOS’s are broadly classified into three types,
namely, Hard Real Time RTOS, Firm Real Time
RTOS and Soft Real Time RTOS as described
below:
 Hard real-time: degree of tolerance for missed deadlines
is extremely small or zero.
 A missed deadline has catastrophic results for the system
 Firm real-time: missing a deadline might result in an
unacceptable quality reduction
 Soft real-time: deadlines may be missed and can be
recovered from. Reduction in system quality is acceptable

6 RTOS Concepts By Prof. Anish Goel

Misconception of RTOS
 a) RTOS must be fast
 The responsiveness of an RTOS depends on its deterministic
behaviour and not on its processing speed.
 The ability of RTOS to response to events within a timeline
does not imply it is fast.
 b) RTOS introduce considerable amount of overhead on
CPU
 An RTOS typically only require between 1% to 4% of a CPU
time.
 c) All RTOS are the same
 RTOS are generally designed for 3 types of real-time systems
(i.e. hard, firm & soft).
 In addition, they are further classified according to the types of
hardware devices (e.g. 8-bit, 16-bit, 32-bit MPU) supported.
7 RTOS Concepts By Prof. Anish Goel
Features of RTOS
 The design of an RTOS is essentially a balance
between providing a reasonably rich feature set for
application development and deployment and, not
sacrificing predictability and timeliness.
 A basic RTOS will be equipped with the following
features:
 Multitasking and Preemptibility
 Task Priority
 Reliable and Sufficient Inter Task Communication
Mechanism
 Priority Inheritance
 Predefined Short Latencies
 Control of Memory Management
8 RTOS Concepts By Prof. Anish Goel
General Architecture of RTOS

9 RTOS Concepts By Prof. Anish Goel

Kernel
 An operating system generally consists of two parts:
kernel space (kernel mode) and user space (user mode).
 Kernel is the smallest and central component of an
operating system.
 Its services include managing memory and devices and
also to provide an interface for software applications to
use the resources.
 Additional services such as managing protection of
programs and multitasking may be included depending
on architecture of operating system.
 There are three broad categories of kernel models
available, namely:
 Monolithic kernel
 Microkernel
 Exokernel

10 RTOS Concepts By Prof. Anish Goel

Monolithic Kernel Based Operating
System

11 RTOS Concepts By Prof. Anish Goel

Microkernel Based Operating System

12 RTOS Concepts By Prof. Anish Goel

Exokernel Based Operating System

13 RTOS Concepts By Prof. Anish Goel

RTOS Kernel Services

14 RTOS Concepts By Prof. Anish Goel

Task Management
 Task management allows programmers to design their software as a number
of separate “chunks” of codes with each handling a distinct goal and
deadline.
 This service encompasses mechanism such as scheduler and dispatcher
that creates and maintain task objects.

Task Object
 To achieve concurrency in real-time application program, the application is
decompose into small, schedulable, and sequential program units known as
“Task”. In real-time context, task is the basic unit of execution and is
governed by three time-critical properties; release time, deadline and
execution time. Release time refers to the point in time from which the task
can be executed. Deadline is the point in time by which the task must
complete.
 Execution time denotes the time the task takes to execute.
 A task object is defined by the following set of components:
 Task Control block (Task data structures residing in RAM and only accessible by
RTOS)
 Task Stack (Data defined in program residing in RAM and accessible by stack
pointer)
15 Task Routine (Program codeRTOS Concepts
residing By Prof. Anish Goel
in ROM)
Task Object

Typical Task Control Block Possible States Transition of Tasks

16 RTOS Concepts By Prof. Anish Goel

Scheduler
 The scheduler keeps record of the state of each task
and selects from among them that are ready to
execute and allocates the CPU to one of them.
 A scheduler helps to maximize CPU utilization
among different tasks in a multi-tasking program and
to minimize waiting time.
 There are generally two types of schedulers: non-
preemptive and priority-based preemptive.

17 RTOS Concepts By Prof. Anish Goel

Non-preemptive Scheduling

•Non-preemptive scheduling or cooperative multitasking requires the tasks

to cooperate with each other to explicitly give up control of the processor.
•When a task releases the control of the processor, the next most important
task that is ready to run will be executed.
•A task that is newly assigned with a higher priority will only gain control of
the processor when the current executing task voluntarily gives up the
control.

18 RTOS Concepts By Prof. Anish Goel

Preemptive Scheduling

•Priority-based preemptive scheduling requires control of the

processor be given to the task of the highest priority at all
•time.
•In the event that makes a higher priority task ready to run,
the current task is immediately suspended and the control of
the processor is given to the higher priority task.

19 RTOS Concepts By Prof. Anish Goel

Task Synchronization & Intertask
Communication
 Task synchronization and intertask communications
serves to enable information to be transmitted safely from
one task to another.
 The service also makes it possible for tasks to coordinate
and cooperate with one another.
 Task Synchronization
 Synchronization is essential for tasks to
share mutually exclusive resources (devices, buffers, etc)
and/or allow multiple concurrent tasks to be executed
(e.g. Task A needs a result from task B, so task A can
only run till task B produces it).
 Task synchronization is achieved using two types of
mechanisms; 1) Event Objects and 2) Semaphores.

20 RTOS Concepts By Prof. Anish Goel

Working Principle of Event Objects
Event objects are used when task synchronization is required without resource
sharing.
They allow one or more tasks to keep waiting for a specified event to occur.
An event object can exist in either of two states: triggered and non-triggered.
An event object in a triggered state indicates that a waiting task may resume.
In contrast, if the event object is in a nontriggered state, a waiting task will need
to stay suspended.

21 RTOS Concepts By Prof. Anish Goel

Semaphore
 Sharing of resource among tasks can be a problem
when the coordination is not well done.
 For instance, if task A begins reading a set of data
currently being updated by task B, task A might
received corrupted data – mixture of new and
existing data.
 To resolve this problem, RTOS kernels provide a
semaphore object and associated semaphore
services to ensure the integrity of data.

22 RTOS Concepts By Prof. Anish Goel

Semaphore
 A semaphore has an associated resource count and a wait queue.
 The resource count indicates availability of resource.
 The wait queue manages the tasks waiting for resources from the
semaphore.
 A semaphore functions like a key that define whether a task has the access
to the resource.
 A task gets an access to the resource when it acquires the semaphore.
 The resource count of a semaphore determines the number of times the
semaphore can be acquired.
 When a task acquires the semaphore, its count decrement by one.
 Likewise, its count increment by one when a task releases the semaphore.
 Generally. There are three types of semaphore:
 Binary Semaphores (semaphore value of either 0 or 1 to indicate unavailability and
availability respectively)
 Counting Semaphores (semaphore value of 0 or greater indicating it can be
acquired/released multiple times)
 Mutually Exclusion Semaphores (semaphore value of 0 or 1 but lock count can be
0 or greater for recursive locking)

23 RTOS Concepts By Prof. Anish Goel

First Type

24 RTOS Concepts By Prof. Anish Goel

Second Type

25 RTOS Concepts By Prof. Anish Goel

Third Type

26 RTOS Concepts By Prof. Anish Goel

Intertask Communication
 Intertask communication involves sharing of data
among tasks through sharing of memory space,
transmission of data and etc.
 Few of mechanisms available for executing intertask
communications includes:
 Message queues
 Pipes
 Remote procedural calls (RPC)

27 RTOS Concepts By Prof. Anish Goel

Intertask Communication
 A message queue is an object used for intertask
communication through which task send or receive messages
placed in a shared memory.
 Tasks and ISRs send and receive messages to the queue
through services provided by the kernel.
 A task seeking for a message from an empty queue is blocked
either for a duration or until a message is received.
 The sending and receiving of messages to and from the queue
may follow 1) First In First Out (FIFO), 2) Last in First Out
(LIFO) or 3) Priority (PRI) sequence.
 Usually, a message queue comprises of an associated queue
control block (QCB), name, unique ID, memory buffers, queue
length, maximum message length and one or more task
waiting lists.
 A message queue with a length of 1 is commonly known as a
mailbox.

28 RTOS Concepts By Prof. Anish Goel

Intertask Communication
 A pipe is an object that provide simple communication channel
used for unstructured data exchange among tasks.
 A pipe can be opened, closed, written to and read from.
 Traditionally, a pipe is a unidirectional data exchange facility.
 There are two descriptors respectively at each end of the pipe
for reading and writing.
 Data is written into the pipe as an unstructured byte stream via
one descriptor and read from the pipe in the FIFO order from
the other.
 Unlike message queue, a pipe does not store multiple
messages but stream of bytes.
 In addition, data flow from a pipe cannot be prioritized.
 Remote procedure call (RPC) component permits distributed
computing where task can invoke the execution of a another
task on a remote computer, as if the task ran on the same
29computer. RTOS Concepts By Prof. Anish Goel
Memory Management
 An embedded RTOS usually strive to achieve small footprint by including only the
functionality needed for the user’s applications.
 There are two types of memory management in RTOSs. They are Stack and Heap
managements.
 In a multi-tasking RTOS, each task needs to be allocated with an amount of memory
for storing their contexts (i.e. volatile information such as registers contents, program
counter, etc) for context switching.
 This allocation of memory is done using task-control block model . This set of memory
is commonly known as kernel stack and the management process termed Stack
Management.
 Upon the completion of a program initialization, physical memory of the MCU or MPU
will usually be occupied with program code, program data and system stack.
 The remaining physical memory is called heap. This heap memory is typically used by
the kernel for dynamic memory allocation of data space for tasks. The memory is
divided into fixed size memory blocks, which can be requested by tasks.
 When a task finishes using a memory block it
must return it to the pool.
 This process of managing the heap memory
is known as Heap management.

30 RTOS Concepts By Prof. Anish Goel

Timer Management
 In embedded systems, system and user tasks are often
scheduled to perform after a specified duration. To
provide such scheduling, there is a need for a periodical
interrupt to keep track of time delays and timeout.
 Most RTOSs today offer both “relative timers” that work in
units of ticks, and “absolute timers” that work with
calendar date and time.
 For each kind of timer, RTOSs provide a “task delay”
service, and also a “task alert” service based on the
signaling mechanism (e.g. event flags).
 Another timer service provided is in meeting task
deadline by cooperating with task schedulers to
determine whether tasks have met or missed their real-
time deadlines.
31 RTOS Concepts By Prof. Anish Goel
Interrupt and Event Handling
 An interrupt is a hardware mechanism used to inform
the CPU that an asynchronous event has occurred.
 A fundamental challenge in RTOS design is
supporting interrupts and thereby allowing
asynchronous access to internal RTOS data
structures.
 The interrupt and event handling mechanism of an
RTOS provides the following functions:
 Defining interrupt handler
 Creation and deletion of ISR
 Referencing the state of an ISR
 Enabling and disabling of an interrupt
 Changing and referencing of an interrupt mask
32 RTOS Concepts By Prof. Anish Goel
Device I/O Management
 An RTOS kernel is often equipped with a device I/O
management service to provide a uniform framework
(application programmer’s interface-“API”) and
supervision facility for an embedded system to
organize and access large numbers of diverse
hardware device drivers.
 However, most device driver APIs and supervisors
are “standard” only within a specific RTOS.

33 RTOS Concepts By Prof. Anish Goel

Selection of RTOS
 Technical Considerations
 Scalability
 Portability
 Run-time facilities
 Run-time performance
 Development tools
 Commercial Considerations
 Costs
 License
 Supplier stability/ longevity

34 RTOS Concepts By Prof. Anish Goel

OS used in Embedded Systems

35 RTOS Concepts By Prof. Anish Goel