0% found this document useful (0 votes)
93 views

Introduction To Real-Time Operating Systems

This document provides an overview of real-time operating systems (RTOS), including: 1) It discusses the history of operating systems from early machine code to modern RTOS and GPOS like UNIX and Windows. 2) It defines an RTOS as a software platform that schedules applications in a timely manner to manage resources consistently. 3) The scheduler is the most important part of an RTOS kernel, determining which tasks run and when through entities, multitasking, context switching, and dispatching.

Uploaded by

Saman Fatima
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
93 views

Introduction To Real-Time Operating Systems

This document provides an overview of real-time operating systems (RTOS), including: 1) It discusses the history of operating systems from early machine code to modern RTOS and GPOS like UNIX and Windows. 2) It defines an RTOS as a software platform that schedules applications in a timely manner to manage resources consistently. 3) The scheduler is the most important part of an RTOS kernel, determining which tasks run and when through entities, multitasking, context switching, and dispatching.

Uploaded by

Saman Fatima
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

Chapter 4

Introduction to Real-Time Operating Systems


OVERVIEW
• 4.1 – Introduction
• 4.2 – A Brief History of Operating System
• 4.3 – Defining an RTOS
• 4.4 – The Scheduler
• 4.4.1 – Schedulable Entities
• 4.4.2 – Multitasking
• 4.4.3 – Context Switching
• 4.4.4 – Dispatcher
• Real time concepts for embedded systems 4th edition by Qing Li
Introduction
• Key factor of many embedded systems is their ability to handle real time
incidents
• This is done using a software platform on which we build applications
• Real time operating system RTOS is that software platform
• Although not all embedded applications are designed with an RTOS

• Upcoming lectures including discussion of:


• Brief history of operating systems
• Definition of RTOS
• Description of scheduler
• Discussion of objects
• Discussion of RTOS services
• Key characteristics of an RTOS
Brief History of Operating systems
• Early days of system development includes low level machine code to
interact with hardware
• Results in non portable applications
• Small change in hardware result in rewriting much of application again

• With the progression of software industry, OS provided basic software


foundation for computing systems by abstracting underneath hardware
• Evolution of OS helped shift the design to modular and interconnected applications

• Over the years, many OS evolved ranging from GPOS such as UNIX,
WINDOWS to smaller and more compact RTOS such as VXWorks
• In 60s, 70s when mainframe computing was in its prime, UNIX was
facilitating multi-users to access expensive and limited available computing
systems

• In 80s Microsoft provides Windows emphasizing personal computer


environments
• Targeted for residential and business users interacting through a graphical user
interface

• Later in the decade, momentum started building for next generation


computing, the post-PC/Embedded-computing era
• Commercial RTOS started meeting their needs
• Although there are some functional similarities between GPOS and RTOS
Similarities between GPOS and RTOS
• Some core functional similarities between general purpose operating
systems and real time operation systems include:

1. Some level of multitasking


2. Software and hardware resource management
3. Provision of underlying OS services to applications
4. Abstracting the hardware from the software application
Differences between GPOS and RTOS
• Some key functional differences that set RTOS apart from GPOS include:

• Better reliability in embedded application context


• Ability to scale up or down to meet application needs
• Faster performance
• Reduced memory requirement
• Scheduling policies tailored for real-time embedded systems
• Support for diskless embedded systems by allowing executables to boot
and run from RAM or ROM
Defining an RTOS
• ‘’A real-time operating system (RTOS) is a program that schedules in a
timely manner, manage system resources, and provides a consistent
foundation for developing application code.’’

• Key component of an RTOS is its kernel. Kernel is a supervisory software


that provides minimal logic, scheduling, and resource management
algorithms.

• On the other hand, an RTOS can be combination of kernel, file system,


networking protocol stacks and other components required for specific
embedded application.
High level view of an
RTOS, its kernel and
other component
found in embedded
systems
Common
components in RTOS
kernel that includes
objects, the
scheduler and some
services
The Scheduler
• Most important part of every kernel
• Provides algorithms needed to determine which task executes when

• Scheduler is concerned with:


• Schedule Entities
• Multitasking
• Context Switching
• Dispatcher
• Scheduling Algorithms
Schedulable Entities
• A kernel object that can compete for execution time on a system
• Tasks and Processes are all examples of schedulable entities

• Task is an independent thread of execution


• Contains sequence of indecently schedulable instructions

• Processes are similar to tasks in a way that they can also independently
compete for execution time, with better memory protection feature at the
expense of performance and memory overhead

• Message queues and semaphores are not schedulable entities


Multitasking
• How exactly does a scheduler handle multiple schedulable entities that
need to run simultaneously?
• Multitasking is the ability of OS to handle multiple activates within set deadlines

• In this scenario, the kernel multitasks


• appear to be running concurrently
• however, the kernel is interleaving execution
• executions sequentially, based on a preset scheduling algorithm

• Tasks follow kernel’s scheduling algorithms, while ISRs are triggered to run
because of hardware interrupts
Context Switch
• Each task has its own context
• State of CPU registers required each time it is schedule to run

• Context switch occur when the scheduler switches from one task to
another

• Every time a new task is created, kernel also creates and maintains its
task control block (TCB)
• TCB contains everything a kernel needs to know about a particular task
• When task is running its context is highly dynamic, and maintained in TCB
• When task is not running, context is frozen inside its TCB
• When the kernel’s schedular determines that it needs to stop running
task1 and start running task2, it takes the following steps

1. The kernel saves task 1’s context information in its TCB


2. It loads task 2’s context information from its TCB,
which becomes the current thread of execution
3. The context of task 1 is frozen while task 2 executes,
but if the scheduler needs to run task 1 again, task 1
continues from where it left off just before the context switch
• Time required to switch from one task to another is known as context
switch time
• Relatively insignificant compared to time required for actual task

• If an application requires frequent context switching


• Application can incur unnecessary performance overhead

• Every time an application makes a system call


• Schedular has an opportunity to determine if it needs to switch context
• It is done with the help of dispatcher
Dispatcher
• Part of schedular that performs context switching and changes the flow of execution

• At any time RTOS is running, flow of control is passing through these three areas
• Through an application task
• Through ISR
• Through Kernel

• When a task or ISR makes a system call, flow of control passes to kernel to execute one of the system routine
provided by the kernel

• When it is time to leave the kernel, dispatcher is responsible for passing control to one of the task in user’s
application

• When a task makes a system call, dispatcher is used to exit the kernel after system calls complete
• When an ISR makes system call, dispatcher is bypassed until the ISR fully completes its execution

You might also like