0% found this document useful (0 votes)
39 views61 pages

RTOS

This document discusses real-time operating systems (RTOS). It covers key topics such as the differences between general purpose and real-time operating systems, common RTOS features like multitasking and priority scheduling, common misconceptions about RTOS, and RTOS architecture and kernel services including task management, synchronization, communication and memory management.

Uploaded by

kalekarmohith02
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
39 views61 pages

RTOS

This document discusses real-time operating systems (RTOS). It covers key topics such as the differences between general purpose and real-time operating systems, common RTOS features like multitasking and priority scheduling, common misconceptions about RTOS, and RTOS architecture and kernel services including task management, synchronization, communication and memory management.

Uploaded by

kalekarmohith02
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 61

REAL TIME

OPERATING
SYSTEMS (RTOS)
MODULE-2

Real Time Operating


Systems

Tradeoffs for
RTOS

POSIX
EMBEDDED SYSTEMS (ES)

 Embedded system = Hardware + Software

 Software as well as hardware plays an equal


role in embedded system

 For specific application or specific part of a


larger system
OPERATING SYSTEM (OS)
 An operating system (OS) is a software used to
provide an interface between the hardware and
user for managing & sharing the resources of the
system

 OS perform basic tasks, such as:


 Recognizing input from keyboard
 Sending output to the display screen
 Keeping track of files
 Managing communication with other peripheral

 Every general-purpose computer must have an


operating system to run other programs
GPOS vs RTOS
 Determinism: RTOS predict the output of the
system for a given input
 Hardware architecture: RTOS are light weight
OS which are used in small architecture
 Kernel: RTOS will use pre-emptive kernel
 Scheduling: RTOS scheduling algorithm is based
on priority
 Interrupt latency: Interrupt latency of the RTOS
is always zero
RTOS - FEATURES
 Multitasking and Preemptibility:
 An RTOS must be multi-tasked and pre-emptible to
support multiple tasks in real-time applications.

 Task Priority:
 In RTOS, preemption capability is achieved by
assigning individual task with the appropriate priority
level.

 Inter Task Communication Mechanism:


 For multiple tasks to communicate in a timely manner
and to ensure data integrity among each other, reliable
and sufficient inter-task communication and
synchronization mechanisms are required.
RTOS - FEATURES
 Priority Inheritance:
 To allow applications with stringent priority
requirements to be implemented, RTOS must have a
sufficient number of priority levels when using priority
scheduling.

 Control of Memory Management:


 To ensure predictable response to an interrupt, an
RTOS should provide way for task to lock its code and
data into real memory.
RTOS - FEATURES
 Predefined Short Latencies:
 Task switching latency: The time needed to save the
context of a currently executing task and switching to
another task is desirable to be short.

 Interrupt latency: The time elapsed between execution


of the last instruction of the interrupted task and the
first instruction in the interrupt handler.

 Interrupt dispatch latency. The time from the last


instruction in the interrupt handler to the next task
scheduled to run.
RTOS
MISCONCEPTIONS
RTOS - MISCONCEPTIONS
 RTOS should be fast: Not true. An RTOS should have
a deterministic behavior in terms of deadlines but its not
true that the processing speed of an RTOS is fast.

 RTOS written in Assembly coding: Real-time


programming is not written completely using assembly
coding

 All RTOS are same: No, it differs based on meeting a


deadline Hard, firm and soft.

 RTOS cause CPU overhead: Again this is not true.


Only 1%-4% of CPU time is required by an RTOS.
RTOS
ARCHITECTURE
RTOS - ARCHITECTURE
 The architecture of an RTOS is dependent on the
complexity of its deployment.
 Good RTOSs are scalable to meet different sets of
requirements for different applications.
 For simple applications, an RTOS usually
comprises only a kernel.
 For more complex embedded systems, an RTOS
can be a combination of various modules,
including the kernel, networking protocol stacks,
and other components.
RTOS - ARCHITECTURE

BASIC BUILDING COMPONENTS OF RTOS


RTOS - ARCHITECTURE

Applications

RTOS
BSP

Hardware

Structure of RTOS
RTOS - ARCHITECTURE

RTOS - Architecture
RTOS - ARCHITECTURE
 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 categories of kernel models
available: Monolithic, Micro and Hybrid kernel
RTOS - ARCHITECTURE
 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.
RTOS - ARCHITECTURE
 Microkernel architecture majorly caters to the
problem of ever growing size of kernel code which
we could not control in the monolithic approach.

 This architecture allows some basic services like


device driver management, protocol stack, file
system etc to run in user space.

 This reduces the kernel code size and also increases


the security and stability of OS as we have the bare
minimum code running in kernel.
RTOS - ARCHITECTURE
 So, if suppose a basic service like network
service crashes due to buffer overflow, then only
the networking service's memory would be
corrupted, leaving the rest of the system still
functional.

 In this architecture, all the basic OS services


which are made part of user space are made to
run as servers which are used by other
programs in the system through inter process
communication (IPC).
RTOS - ARCHITECTURE

 So, what the bare minimum that microkernel


architecture recommends in kernel space?
 Managing memory protection
 Process scheduling
 Inter Process communication (IPC)

 Apart from the above, all other basic services can


be made part of user space and can be run in the
form of servers.

QNX, Nucleus, VxWorks follows the Microkernel approach


RTOS - ARCHITECTURE
 Some suppliers also provide a root file
system, a toolchain for building programs to
run on the embedded system, and utilities to
configure the device (while running) along
with the BSP.

 Many RTOS providers provide template


BSP's, developer assistance, and test suites to
aid BSP developers in bringing up the RTOS
on a new hardware platform.
RTOS
KERNEL SERVICES
RTOS – KERNEL SERVICES
Task Management
 During the execution of an application program,
individual tasks are continuously changing from one
state to another.
 However, only one task is in the running mode (i.e.
given CPU control) at any point of the execution.
 In the process where CPU control is change from one
task to another, context of the to-be-suspended task
will be saved while context of the to-be-executed task
will be retrieved. This process is called context
switching.
RTOS – KERNEL SERVICES
Task Management
 In RTOS each task may exist in any one of the
following states,
 Dormant : Task doesn’t 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


RTOS – KERNEL SERVICES
Task Management

Task States in RTOS TCB in RTOS


RTOS – KERNEL SERVICES
Task Management
 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
through the kernel.
RTOS – KERNEL SERVICES
Task Synchronization
 Task Synchronization & inter task communication
serves to enable information to be transmitted safely
from one task to another.
 Synchronization is essential for tasks to share
mutually exclusive resources (devices, buffers, etc)
and/or allow multiple concurrent tasks to be executed.
 Task synchronization is achieved by two mechanisms:
 Event objects are used when task synchronization is required
without resource sharing.
 Semaphores is associated with resource count and a wait queue.
RTOS – KERNEL SERVICES
Inter Task Communication
 Inter task communication involves sharing of data
among tasks through common memory space,
transmission of data, etc.
 Inter task communications is executed using following
mechanisms
 Message queue is an object through which task send or
receive messages placed in a shared memory.

 Pipes is an object that provide simple communication


channel used for unstructured data exchange among
tasks.
RTOS – KERNEL SERVICES
Memory Management
 An embedded RTOS usually strive to achieve small
footprint by including only the functionality needed
for the user’s applications.
 Two types of memory managements are provided in
RTOS – Stack and Heap.
 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.
RTOS – KERNEL SERVICES
Memory Management

 This allocation of memory is done using task-control


block model and 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.
RTOS – KERNEL SERVICES
Memory Management
 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.
RTOS – KERNEL SERVICES
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. This is taken care by Timer Management
unit.

 Most RTOSs today offer both “relative timers” that


work in units of ticks, and “absolute timers” that work
with calendar date and time.
RTOS – KERNEL SERVICES
Interrupt and Event Handling
 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
RTOS – KERNEL SERVICES
Interrupt and Event Handling
 The interrupt and event handling mechanism of an
RTOS helps 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
RTOS – KERNEL SERVICES
Device I/O Management
 An RTOS kernel is often equipped with a device I/O
management service to provide a uniform framework
(“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.
SELECTION OF
RTOS
SELECTION OF RTOS
 An RTOS is usually chosen based on its performance
or one’s comfort and familiarity with the product.
However, such a selection criteria is insufficient.

 There is a wide variety of RTOS ranging from


commercial RTOS, open-source RTOS to internally
developed RTOS to choose from. Therefore, it is a role
of the programmers to exercise extra caution in the
selection process.

 The selection criteria of RTOS can be broadly


classified into two main areas; technical features of
RTOS and commercial aspect of the implementation.
SELECTION OF RTOS
Technical Considerations
 Scalability:
 Size or memory footprint is an important
consideration.
 Most RTOS are scalable in which only the code
required is included in the final memory footprint.
 Portability:
 Often, a current application may outgrow the hardware
it was originally designed for as the requirements of the
product increases.
 An RTOS with such a capability can therefore be
ported between processor architectures and between
specific target systems.
SELECTION OF RTOS
Technical Considerations
 Run-time facilities:
 Run-time facilities refer to the services of the
kernel (i.e. inter task communication, task
synchronization, interrupts and events handling,
etc).

 Different application systems have different sets of


requirements.

 Comparison of RTOSs is frequently between the


kernel-level facilities they provided.
SELECTION OF RTOS
Technical Considerations
 Run-time performance:

 Run-time performance of an RTOS is generally


governed by the interrupt latency, context
switching time and few other metric of kernel
performance.

 This consideration is useful if the performance


assessment of the application on a given RTOS
is to prototype its performance-critical aspects
on standard hardware.
SELECTION OF RTOS
Technical Considerations
 Development tools:
 A sufficient set of development tools including
debugger; compiler and performance profiler
might help in shortening the development and
debugging time, and improve the reliability of the
coding.

 Commercial RTOSs usually have a complete set of


tools for analyzing and optimizing the RTOSs’
behavior whereas Open-Source RTOSs will not
have.
SELECTION OF RTOS
Commercial Considerations
 Costs:

 Costs are a major consideration in selection of


RTOS.

 Some of the RTOS packages are complete


operating systems including not only the real-
time kernel but also an input/output manager,
windowing systems, a file system, networking,
language interface libraries, debuggers, and
cross platform compilers.
SELECTION OF RTOS
Commercial Considerations
 License:

 RTOS vendor usually has a few license models for


customers to choose from.

 A perpetual license enables customers to purchase the


development set and pay an annual maintenance fee,
which entitles he/her to upgrades and bug fixes.

 An alternative model known as subscription model


allow customers to “rent” the development set whilst
paying an annual fee to renew the access.
SELECTION OF RTOS
Commercial Considerations
 Supplier stability/ longevity:

 Development with RTOS is not a problem free


process.

 Reliable and consistent support from supplier is


a critical factor in ensuring the prompt
completion of a project.

 Supplier longevity thus helps to determine the


availability of support.
RTOS - TRADEOFFS
RTOS – TRADEOFFS
 It all starts with a product and its requirements.
What sort of device is your company building?
 As you know, embedded devices run on very
simple to the very complex, from mass market
consumer applications like cell phones to single-
shot devices like Mars landers. List of common
RTOS tradeoffs are,
 “Better” RTOS vs “better” hardware
 Resources vs Cost
 Commercial RTOS vs in-house RTOS
 Royalty Free vs. Per Device Royalty
RTOS – TRADEOFFS
“Better” RTOS vs “better” hardware
 Using a more code-efficient RTOS and application
software may reduce the required hardware or
allow the same functionality to be achieved on less
expensive Microprocessors.

 Or, using more expensive hardware (i.e., 32-bit


microprocessor vs. 8-bit) may allow a less
expensive RTOS like Linux. That is, the
better/more expensive the RTOS the
worse/cheaper the hardware can be and, to some
extent, vice-versa.
RTOS – TRADEOFFS
Resources vs Cost
 To run application such-and-such, how much
memory would you need? How much memory will
you have available?

 What are the power requirements? What response


time is required?

 Is it a “hard” real-time device, such as a military


computer system or a medical device? Or is it a
consumer device that can tolerate less true real-
time performance?
RTOS – TRADEOFFS
Resources vs Cost

ITEM DESCRIPTION
Power Is this a low power device? Will it run on batteries? How
long does it need to run before a re-charge?

Processor What sort of processor will the device have? 8-, 16-, 32-
bit? Which particular architecture? If the processor has
already been chosen, this pre-limits the selection of
available RTOSes.

Memory/Footprint How much and what type(s) of memory is available for


the RTOS? How much additional is needed for
applications? What are the trade-offs between the two?
RTOS – TRADEOFFS
Resources vs Cost
ITEM DESCRIPTION
Hard vs. Software Real-time To what extent, must the device have hard real-
time capabilities?
Durability/User Interaction To what extent will this device be “on its own”
– away from humans who can reset it? Is it a
military or industrial device that will operate in
a harsh temperature or vibration environment?

Networking and/or Will the device be communicating, either over


Communications wires or wirelessly? If so, are there particular
Constraints standards such as Zigbee, 802.11, or ethernet
that will be required?
RTOS – TRADEOFFS
Resources vs Cost
REAL-TIME
POSIX
REAL-TIME POSIX
POSIX.4b: Timeouts

 In time-critical systems it is important to limit the


maximum amount of time that a process can stay
waiting for one of these services to complete.
 POSIX.4b defines new versions of some of the
blocking services with built-in timeouts.
 These timeouts specify the maximum amount of time
that the process may be suspended while waiting for
the service to complete.
REAL-TIME POSIX
POSIX.4b: Timeouts

 The services chosen are those that are most likely


going to be used in time-critical code, and did not
already have timeout capability:

 Wait for a semaphore to become unlocked


 Wait for the arrival of a message to a message
queue
 Send a message to a queue
 Wait for a mutex to become unlocked.
REAL-TIME POSIX
POSIX.4b: Execution time clocks

 An optional CPU-time clock is defined for each


process and each thread.

 The POSIX.4 clocks & timers interface is used to


manage execution-time clocks.

 Execution time clocks allow to detect when an


execution time overrun occurs, and to activate the
appropriate error handling actions
REAL-TIME POSIX
POSIX.4b: Sporadic Server

 A new scheduling policy is defined


(SCHED_SPORADIC) that implements the sporadic
server scheduling algorithm.

 This policy can be used to process aperiodic events at


the desired priority level, allowing to guarantee the
timing requirements of lower priority tasks.

 The sporadic server gives fast response times and


makes systems with aperiodic events predictable.
REAL-TIME POSIX
POSIX.4b: Interrupt Control
 Many real-time systems need the ability to capture
interrupts generated by special devices, and handle them at
the application program.

 The interfaces defined will not achieve complete portability


of the application programs due to the many differences in
interrupt handling for the different architectures.

 However, application portability is enhanced by this


interface, because a reference model is established and
because non portable code is confined to specified modules,
thus reducing the number of changes necessary to port the
application.
REAL-TIME POSIX
POSIX.4b: I/O Device Control
 In real-time systems it is common to interact with the
environment through special devices such as digital or
analog input/output devices, counters, etc.
 Typically, drivers for these special devices are written
by the application developer, and a standardized
operation for interfacing with these drivers allows the
application operations calling that driver to be well
defined.
 POSIX.4b defines a function that allows an
application program to transfer control information to
and from a device driver
REAL-TIME POSIX
POSIX.13: REAL-TIME APPLICATION
ENVIRONMENT PROFILES
 The real-time application environment profiles (AEPs)
defined in POSIX.13 provide the adequate subsets of
features of the base standards that are required for a
particular application environment.
 Four real-time AEPs are being defined in POSIX.13:

1) Minimum System: Corresponds to a small embedded


system with no need for a memory management unit
(MMU), no file system (no disk), and no I/O terminal. Only
one process is allowed, but multiple threads can run
concurrently.
REAL-TIME POSIX
POSIX.13: REAL-TIME APPLICATION
ENVIRONMENT PROFILES
2) Real-time Controller: Corresponds to a special purpose
controller system. It is like the minimum real-time profile,
but adding a file system and I/O terminal. Only one process
but multiple threads are allowed.

3) Dedicated System: Corresponds to a large embedded


system with no file system. It has multiple processes and
threads.

4) Multi-purpose System: Corresponds to a large real-time


system with all the features supported.
REAL-TIME POSIX
POSIX.13: REAL-TIME APPLICATION
ENVIRONMENT PROFILES

Characteristics of the Real-Time Profiles

You might also like