LAB MANUAL

AIM: Understanding RTOS architecture

Theory:
Introduction:
A Real-Time Operating System (RTOS) comprises of two components, viz., Real-Time and
Operating System.Real-time systems are those systems in which the correctness of the system
depends not only on the logical result of computation, but also on the time at which the results are
produced.
RTOS is therefore an operating system that supports real-time applications by providing logically
correct result within the deadline required. Basic Structure is similar to regular OS but, in addition, it
provides mechanisms to allow real time scheduling of tasks.
Though real-time operating systems may or may not increase the speed of execution, they can
provide much more precise and predictable timing characteristics than general-purpose OS.
RTOS can be classified into three types :
1. Hard RTOS : These type of RTOS strictly adhere to the deadline associated with the tasks.
Missing on a deadline can have catastrophic affects.
2. Firm RTOS : These type of RTOS are also required to adhere to the deadlines because missing
a deadline may not cause a catastrophic affect but could cause undesired affects, like a huge
reduction in quality of a product which is highly undesired.
3. Soft RTOS : In these type of RTOS, missing a deadline is acceptable. For example On-line
Databases.
RTOS architecture
For simpler applications, RTOS is usually a kernel but as complexity increases, various modules like
networking protocol stacks debugging facilities, device I/Os are includes in addition to the kernel.
The general architecture of RTOS is shown in the fig.

RTOS kernel acts as an abstraction layer between the hardware and the applications. An RTOS
generally avoids implementing the kernel as a large monolithic program. The kernel is developed
instead as a micro-kernel with added configurable functionalities. This implementation gives
resulting benefit in increase system configurability, as each embedded application requires a specific
set of system services with respect to its characteristics. The kernel of an RTOS provides an
abstraction layer between the application software and hardware. This abstraction layer comprises
of six main types of common services provided by the kernel to the application software.
Following figure shows the six common services of an RTOS kernel -

a. Task Management
In RTOS, The application is decomposed into small, schedulable, and sequential program units
known as Task, a 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)
Task Routine (Program code residing in ROM)

Each task may exist in following states

Dormant : Task doesnt require computer time
Ready: Task is ready to go active state, waiting processor time
Active: Task is running
Suspended: Task put on hold temporarily
Pending: Task waiting for resource.

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.
Dispatcher
The dispatcher gives control of the CPU to the task selected by the scheduler by performing
context switching and changes the flow of execution. At any time an RTOS is running, the flow
of execution passes through one of three areas: through the task program code, through an
interrupt service routine, or through the kernel.

b. Memory Management
An embedded RTOS usually strive to achieve small footprint by including only the functionality
needed for the users 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.
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).

c.

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

d.

Task synchronization is achieved using two types of mechanisms:

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. Event object can exist
either in triggered or non-triggered state. Triggered state indicates resumption of the task.
Semaphores.
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.

Intertask communication involves sharing of data among tasks through sharing of memory space,
transmission of data, etc. Intertask communications is executed using following mechanisms
Message queues - A message queue is an object used for intertask communication through
which task send or receive messages placed in a shared memory. 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.

Pipes - A pipe is an object that provide simple communication channel used for unstructured data
exchange among tasks. A pipe does not store multiple messages but stream of bytes. Also, data flow
from a pipe cannot be prioritized.
Remote procedure call (RPC) - It permits distributed computing where task can invoke the
execution of another task on a remote computer.
e. 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
and help to ensure:
Data integrity by restricting interrupts from occurring when modifying a data structure
Minimum interrupt latencies due to disabling of interrupts when RTOS is performing critical
operations
Fastest possible interrupt responses that marked the preemptive performance of an RTOS
Shortest possible interrupt completion time with minimum overheads
f. Device I/O Management
An RTOS kernel is often equipped with a device I/O management service to provide a uniform
framework (application programmers 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.

RTOS Features
1. Multithreading and preemptability - The scheduler should be able to preempt any task in the
system and allocate the resource to the thread that needs it most even at peak load.
2. Thread Priority - All tasks are assigned priority level to facilitate pre-emption.The highest
priority task that is ready to run will be the task that will be running.
3. Inter Task Communication & Synchronization - Multiple tasks pass information among each
other in a timely fashion and ensuring data integrity
4. Priority Inheritance - RTOS should have large number of priority levels & should prevent
priority inversion using priority inheritance.
5. Short Latencies - The latencies are short and predefined.
6. Task switching latency: The time needed to save the context of a currently executing task
and switching to another task.
7. Interrupt latency: The time elapsed between execution of the last instruction of the
interrupted task and the first instruction in the interrupt handler.
8. Interrupt dispatch latency: The time from the last instruction in the interrupt handler to the
next task scheduled to run.

Conclusion:
We studied

What a RTOS is and its types

Architecture of RTOS
Common services of an RTOS kernel
Key features of RTOS