RTOS based Embedded System Design

Prepared by
Jay Pathak

1
 Real Time Operating System
Operating System Basics

The Operating System acts as a bridge
between the user applications/tasks and
the underlying system resources through
a set of system functionalities and
services.

OS manages the system resources and
makes them available to the user
applications/tasks on a need basis.
2
 Operating System Basics
The primary functions of an
Operating system is
➢ Make the system
convenient to use
➢ Organize and manage
the system resources
efficiently and correctly.
A normal computing system
is a collection of different
I/O subsytems, working
and storage memory

3
 Operating System Basics
USER Application
Application Programming
Interface (API)

Kernel Services
MEMORY Management
PROCESS Management
TIME Management
FILE SYSTEM Management
I/O SYSTEM Management
Device Driver
Interface
Underlying Hardware
4
 Kernel
The kernel is the core of the operating system
• It is responsible for managing the system
resources and the communication among the
hardware and other system services
• Kernel acts as the abstraction layer between
system resources and user applications
• Kernel contains a set of system libraries and
services.

5
 Kernel
For a general purpose OS, the kernel contains different services like
➢ Process Management
➢ Primary Memory Management
➢ File System management
➢ I/O System (Device) Management
➢ Secondary Storage Management
➢ Protection
➢ Time management
➢ Interrupt Handling

6
 Process Management
 Process Management deals with managing the
processes/tasks.
 Process management includes setting up the memory
space for the process, loading the process’s code into
the memory space, allocating system resources,
scheduling and managing the execution of the process,
setting up and managing the Process control block
(PCB), Inter Process Communication and
Synchronisation process termination/deletion etc.
Do Refer books for examples (See list of books at last)

7
 Primary Memory Managment
The term primary memory refers to the volatile memory
(RAM) where processes are loaded and variables and
shared data associated with each process are stored.
The memory mangement unit(MMU) of the kernel is
responsible for:
Keeping the track of which part of the memory area is
currently used by which process
Allocating and de-allocating memory space on a need
basis (Dynamic memory allocation)
Do Refer books for examples (See list of books at
last)
8
 File System Management
The file system management service kernel is
responsible for
The creation, deletion and alteration of files
Creation, deletion and alteration of directories
Saving of files in secondary storage memory (eg Hard
disk storage)
Providing automatic allocation of file space based on the
amount of free space available
Providing a flexible naming convention for the files
Do Refer books for examples (See list of books at
last) 9
I/O System Device Management
Kernels is responsible for routing the I/O requests coming from different
user applications to the appropriate I/O devices of the system.
In a well structured OS the direct accessing of I/O devices are not allowed
and the acess to them are provided through a set of Application
Programming Interfaces (API) exposed by kernel.
The service Device Manager of kernel is responsible for handling all I/O
device related operations.
The kernel talks to the I/O device through set of low level system calls,
which are implemented in a service, called device drivers.
The device drivers are specific to a device or a class of device. The device
manager is responsible for:

Loading and unloading of device drivers

Exchanging information and the system specific control signals to and
from the device.
Do Refer books for examples (See list of books at last) 10
Secondary Storage Management
The secondary storage management service
of kernel deals with

Disk storage allocation

Disk schedulling

Free disk space management
Do Refer book for examples (See list of
books at last)

11
 Protection Systems
Protection deals with implementing the security policies to
restrict the access to both user and systems resources by
different applications or processes or users.
In multiuser supported operating systems, one user may
not be allowed to view or modify the whole portion of
another user’s data or profile details.
In addition, some application may not be granted with
permission to make use of some of the system resources.
This kind of protection is provided by the protection services
running within the kernel.

12
 Interrupt Handler
Kernel provicdes handler mechanism for all external/internal interrupts
generated by the system.
These are some of the important services offered by the kernel of an
operating system.
Depending on the type of the operating system, a kernel may contain less
number of components/service or more number of components/service.
Kernel exposses the interface to various kernel applications/services,
hosted by kernel, to the user applications through a set of standard
Application Programming Interfaces (API).
User applications can avail thers API calls to access the vatious kernel
application/services
Do Refer book for examples (See list of books at last)

13
 Kernel Space and User Space

The program code corresponding to the kernel
applications/services are kept in a contiguous area
(OS dependent) of primary (working) memory and is
protected from the un-authorized access by user
programs/applications
• The memory space at which the kernel code is located
is known as ‘Kernel Space’

All user applications are loaded to a specific area of
primary memory and this memory area is referred as
‘User Space’

14
 Kernel Space and User Space

The partitioning of memory into kernel and user
space is purely Operating System dependent
• An operating system with virtual memory support,
loads the user applications into its corresponding
virtual memory space with demand paging
technique
• Most of the operating systems keep the kernel
application code in main memory and it is not
swapped out into the secondary memory

15
 Monolithic Kernel
All kernel services run in the kernel space
• All kernel modules run within the same
memory space under a single kernel thread
• The tight internal integration of kernel
modules in monolithic kernel architecture
allows the effective utilization of the low-
level features of the underlying system

16
 Monolithic Kernel

The major drawback of monolithic kernel is
that any error or failure in any one of the
kernel modules leads to the crashing of the
entire kernel application.

Monolithic kernel with all operating system
services running in kernel space
• LINUX, SOLARIS, MS-DOS kernels are
examples of monolithic kernel

17
Monolithic Kernel

Applications

Monolithic kernel with all

operating system services
running in kernel space
18
 Microkernel

The microkernel design incorporates only
the essential set of Operating System
services into the kernel

Rest of the Operating System services are
implemented in programs known as
‘Servers’ which runs in user space.

The kernel design is highly modular
provides OS-neutral abstraction.

19
 Microkernel

Memory management, process management, timer
systems and interrupt handlers are examples of
essential services, which forms the part of the
microkernel

QNX, Minix 3 kernels are examples for microkernel.

Benefits of Microkernel:

Robustness: If a problem is encountered in any
services in server can reconfigured and re-started
without the need for re-starting the entire OS.

Configurability: Any services , which run as ‘server’
application can be changed without need to restart the
whole system. 20
 Microkernel
Servers (kernel
services running Applications
in user space)

Microkernel with essential

services like memory
management, process
management, timer system etc...
21
 Types of Operating Systems
Depending on the type of kernel and kernel
services, purpose and type of computing
systems where the OS is deployed and the
responsiveness to applications, Operating
Systems are classified into

General Purpose Operating System (GPOS)

Real Time Purpose Operating System
(RTOS)

22
 General Purpose Operating
System (GPOS)
Operating Systems, which are deployed in general computing
systems
• The kernel is more generalized and contains all the required
services to execute generic applications
• Need not be deterministic in execution behavior
• May inject random delays into application software and thus
cause slow responsiveness of an application at unexpected times
• Usually deployed in computing systems where deterministic
behavior is not an important criterion

Personal Computer/Desktop system is a typical example for a
system where GPOSs are deployed.
• Windows XP/MS-DOS etc are examples of General Purpose
Operating System
23
 Real Time Purpose Operating
System (RTOS)
Operating Systems, which are deployed in embedded
systems demanding real-time response
•Deterministic in execution behavior. Consumes only known
amount of time for kernel applications
•Implements scheduling policies for executing the highest
priority task/application always
•Implements policies and rules concerning time-critical
allocation of a system’s resources
•Windows CE, QNX, VxWorks , MicroC/OS-II etc are
examples of Real Time Operating Systems (RTOS)

24
 The Real Time Kernel
The kernel of a Real Time Operating System is referred as Real Time
kernel.
In complement to the conventional OS kernel, the Real Time kernel is
highly specialized and it contains only the minimal set of services
required for running the user applications/tasks.
The basic functions of a Real Time kernel are
a) Task/Process management
b) Task/Process scheduling
c) Task/Process synchronization
d) Error/Exception handling
e) Memory Management
f) Interrupt handling
g) Time management 25
 Real Time Kernel Task/Process
Management
Deals with setting up the memory space for the tasks, loading the task’s
code into the memory space, allocating system resources, setting up a
Task Control Block (TCB) for the task and task/process
termination/deletion.
A Task Control Block (TCB) is used for holding the information
corresponding to a task.
TCB usually contains the following set of information
❖ Task ID: Task Identification Number
❖ Task State: The current state of the task. (E.g. State= ‘Ready’ for a task
which is ready to execute)
❖ Task Type: Task type. Indicates what is the type for this task. The task
can be a hard real time or soft real time or background task.
❖ Task Priority: Task priority (E.g. Task priority =1 for task with priority = 1)
❖ Task Context Pointer: Context pointer. Pointer for context saving
26
❖ Task Memory Pointers: Pointers to the code memory,
data memory and stack memory for the task
❖ Task System Resource Pointers: Pointers to system
resources (semaphores,mutex etc) used by the task
❖ Task Pointers: Pointers to other TCBs (TCBs for
preceding, next and waiting tasks)
❖ Other Parameters: Other relevant task parameters
The parameters and implementation of the TCB is
kernel dependent.
The TCB parameters vary across different kernels,
based on the task management implementation

27
 Task/Process Scheduling
Deals with sharing the CPU among varioustasks/processes.
A kernel application called ‘Scheduler’ handles the task
scheduling. Scheduler is nothing but an algorithm
implementation, which performs the efficient and optimal
scheduling of tasks to provide a deterministic behavior.

Task/Process Synchronization
Deals with synchronizing the concurrent
access of a resource, which is shared
across multiple tasks and the
communication between various tasks. 28
 Error/Exception handling
Deals with registering and handling the errors
occurred/exceptions raised during the execution of tasks.
Insufficient memory, timeouts, deadlocks, deadline missing,
bus error, divide by zero, unknown instruction execution etc,
are examples of errors/exceptions.
Errors/Exceptions can happen at the kernel level services or at
task level.
Deadlock is an example for kernel level exception, whereas
timeout is an example for a task level exception.
The OS kernel gives the information about the error in the form
of a system call (API).

29
 Memory Management
❖ The memory management function of an RTOS kernel is
slightly different compared to the General Purpose Operating
Systems
❖ The memory allocation time increases depending on the
size of the block of memory needs to be allocated and the
state of the allocated memory block (initialized memory block
consumes more allocation time than uninitialized memory
block)
❖ Since predictable timing and deterministic behavior are the
primary focus for an RTOS, RTOS achieves this by
compromising the effectiveness of memory allocation.
❖ RTOS generally uses ‘block’ based memory allocation
technique, instead of the usual dynamic memory allocation
30
techniques used by the GPOS.
 Memory Management (2/3)
❖ RTOS kernel uses blocks of fixed size of dynamic memory and the
block is allocated for a task on a need basis. The blocks are stored in a
‘Free buffer Queue’.
❖ Most of the RTOS kernels allow tasks to access any of the memory
blocks without any memory protection to achieve predictable timing and
avoid the timing overheads
❖ RTOS kernels assume that the whole design is proven correct and
protection is unnecessary. Some commercial RTOS kernels allow
memory protection as optional and the kernel enters a fail-safe mode
when an illegal memory access occurs
❖ The memory management function of an RTOS kernel is slightly
different compared to the General Purpose Operating Systems
❖ A few RTOS kernels implement Virtual Memory concept for memory
allocation if the system supports secondary memory storage (like HDD
and FLASH memory).
31
 Memory Management (3/3)
❖ In the ‘block’ based memory allocation, a
block of fixed memory is always allocated for
tasks on need basis and it is taken as a unit.
Hence, there will not be any memory
fragmentation issues.
❖ The memory allocation can be implemented
as constant functions and thereby it
consumes fixed amount of time for memory
allocation. This leaves the deterministic
behavior of the RTOS kernel untouched.
32
 Interrupt Handling
❖ Interrupts inform the processor that an external device or an
associated task requires immediate attention of the CPU.
❖ Interrupts can be either Synchronous or Asynchronous.
❖ Interrupts which occurs in sync with the currently executing
task is known as Synchronous interrupts. Usually the software
interrupts fall under the Synchronous Interrupt category.
Divide by zero, memory segmentation error etc are examples
of Synchronous interrupts.
❖ For synchronous interrupts, the interrupt handler runs in the
same context of the interrupting task.
❖ Asynchronous interrupts are interrupts, which occurs at any
point of execution of any task, and are not in sync with the
currently executing task. 33
 Interrupt Handling (2/2)
❖ The interrupts generated by external devices (by asserting the
Interrupt line of the processor/controller to which the interrupt line
of the device is connected) connected to the processor/controller,
timer overflow interrupts, serial data reception/ transmission
interrupts etc are examples for asynchronous interrupts.
❖ For asynchronous interrupts, the interrupt handler is usually
written as separate task (Depends on OS Kernel implementation)
and it runs in a different context. Hence, a context switch happens
while handling the asynchronous interrupts.
❖ Priority levels can be assigned to the interrupts and each
interrupts can be enabled or disabled individually.
❖ Most of the RTOS kernel implements ‘Nested Interrupts’
architecture. Interrupt nesting allows the pre-emption (interruption)
of an Interrupt Service Routine (ISR), servicing an interrupt, by a
higher priority interrupt. 34
 Time Management
❖ Interrupts inform the processor that an external device or an
associated task requires immediate attention of the CPU.
❖ Accurate time management is essential for providing precise
time reference for all applications
❖ The time reference to kernel is provided by a high-resolution
Real Time Clock (RTC) hardware chip (hardware timer)
❖ The hardware timer is programmed to interrupt the
processor/controller at a fixed rate. This timer interrupt is
referred as ‘Timer tick’
❖ The ‘Timer tick’ is taken as the timing reference by the kernel.
The ‘Timer tick’ interval may vary depending on the hardware
timer. Usually the ‘Timer tick’ varies in the microseconds range
35
 Time Management (2/4)
❖ The time parameters for tasks are expressed as the multiples of
the ‘Timer tick’
❖ The System time is updated based on the ‘Timer tick’
❖ If the System time register is 32 bits wide and the ‘Timer tick’
interval is 1microsecond, the System time register will reset in
232 / (24 * 60 * 60) = 49700 Days*10-6 =~ 0.0497 Days = 1.19 Hours
If the ‘Timer tick’ interval is 1 millisecond, the System time register
will reset in
232 / (24 * 60 * 60) = 49700 Days* 10-3 = 49.7 Days =~ 50 Days
The ‘Timer tick’ interrupt is handled by the ‘Timer Interrupt’ handler of
kernel.
The ‘Timer tick’ interrupt can be utilized for implementing the
following actions. 36
 Time Management (3/4)
The ‘Timer tick’ interrupt is handled by the ‘Timer Interrupt’ handler
of kernel.
The ‘Timer tick’ interrupt can be utilized for implementing the
following actions.
• Save the current context (Context of the currently executing task)
• Increment the System time register by one. Generate timing error
and reset the System time register if the timer tick count is
greater than the maximum range available for System time
register
• Update the timers implemented in kernel (Increment or
decrement the timer registers for each timer depending on the
count direction setting for each register. Increment registers with
count direction setting = ‘count up’ and decrement registers with
count direction setting = ‘count down’) 37
 Time Management (4/4)
• Activate the periodic tasks, which are in the idle
state
• Invoke the scheduler and schedule the tasks again
based on the scheduling algorithm
• Delete all the terminated tasks and their
associated data structures (TCBs)
• Load the context for the first task in the ready
queue. Due to the rescheduling, the ready task
might be changed to a new one from the task,
which was pre-empted by the ‘Timer Interrupt’ task
38
 Hard Real-time System
❖ A Real Time Operating Systems which strictly adheres to the timing constraints
for a task
❖ A Hard Real Time system must meet the deadlines for a task without any
slippage
❖ Missing any deadline may produce catastrophic results for Hard Real Time
Systems, including permanent data lose and irrecoverable damages to the
system/users
❖ Emphasize on the principle ‘A late answer is a wrong answer’
❖ Air bag control systems and Anti-lock Brake Systems (ABS) of vehicles are
typical examples of Hard Real Time Systems
❖ As a rule of thumb, Hard Real Time Systems does not implement the virtual
memory model for handling the memory. This eliminates the delay in swapping
in and out the code corresponding to the task to and from the primary memory
❖ The presence of Human in the loop (HITL) for tasks introduces unexpected
delays in the task execution. Most of the Hard Real Time Systems are
automatic and does not contain a ‘human in the loop’
39
 Soft Real-time System
❖ Real Time Operating Systems that does not guarantee meeting
deadlines, but, offer the best effort to meet the deadline
❖ Missing deadlines for tasks are acceptable if the frequency of
deadline missing is within the compliance limit of the Quality of Service
(QoS)
❖ A Soft Real Time system emphasizes on the principle ‘A late answer
is an acceptable answer, but it could have done bit faster’
❖ Soft Real Time systems most often have a ‘human in the loop (HITL)’
❖ Automatic Teller Machine (ATM) is a typical example of Soft Real
Time System. If the ATM takes a few seconds more than the ideal
operation time, nothing fatal happens.
❖ An audio video play back system is another example of Soft Real
Time system. No potential damage arises if a sample comes late by
fraction of a second, for play back.
40
 Note
Refer:
Embedded System by Rajkamal Chapter 8
Introduction To Embedded System by Shibu
Chapter 10
Do refer books

41