









 General Purpose Operating System


Background: What’s a “Real Time” System?


What makes an OS Real-Time?

 Predictable (possibly deterministic

behavior), that’s all

 By product: mediocre throughputs

How do they work?

 Tasks are scheduled by OS according to

fixed priority (typically)

 Tasks can’t directly interact; they use

messages or shared memory & semaphores
to communicate
Real Time System

 A system is said to be Real Time if it is

required to complete it’s work & deliver it’s
services on time.
 Example – Flight Control System
 All tasks in that system must execute on time.
 Non Example – PC system
 Non-Real-Time systems





Fire alarm system: an example

Central server

TCP/IP over radio

Controllers: ARM based

Low bandwidth radio links

Sensors: microcontroller based

Fire Alarm System
 Problem
 Hundreds of sensors, each fitted with Low Range Wireless
 Sensor information to be logged in a server & appropriate action
initiated
 Possible Solution
 Collaborative Action
 Routing
 Dynamic – Sensors/controllers may go down
 Auto Configurable – No/easy human intervention.
 Less Collision/Link Clogging
 Less no of intermediate nodes
 Fast Response Time
 Secure
 What is a RTOS ??





Designing an RTOS: End Goal

 Have known switching & scheduling

overhead
 Avoid common problems like priority
inversion and deadlock
Designing an RTOS:
Common Problems

 Priority inversion
 High-level task stalled due to low-level using
shared resources, then a medium-level task
holding up the low-level one
 Solution: Priority inheritance – give low-level
task high-level priority
 Designing an RTOS: Common Problems
(con’t)

 Deadlock
 Two semaphores locked out of order by two tasks
and circularly block each other
 Solution: “Instant Inheritance” implementation of
Priority Ceiling Protocol – semaphores possibly
needed by higher processes become priority tokens
Designing with an RTOS: What do you
need?

 Task information
 Priorities for each task
 Worst-case runtime
 Best-case period
Solving Problems

 Logs
 Time Machines
 Memory Conservation
 Types of RTOS

Soft Real-Time system

Hard Real-Time system
 Soft Real-Time system


 Hard Real-Time system



 Hard and Soft Real Time Systems
(Operational Definition)
 Hard Real Time System
 Validation by provably correct procedures or extensive
simulation that the system always meets the timings
constraints
 Soft Real Time System
 Demonstration of jobs meeting some statistical
constraints suffices.
 Example – Multimedia System
 25 frames per second on an average
Role of an OS in Real Time Systems
 Standalone Applications
 Often no OS involved
 Micro controller based Embedded Systems
 Some Real Time Applications are huge &
complex
 Multiple threads
 Complicated Synchronization Requirements
 Filesystem / Network / Windowing support
 OS primitives reduce the software design time
Basic functions of RTOS kernel










 Task Management




 Task States


Interrupt handling
 Interrupt handling





 Memory management


 Exception handling


 Exception handling






 Task Synchronization





 Task Synchronization





 Task scheduling



 Task scheduling




 Task scheduling





 Task scheduling




 Task scheduling





Example of Task scheduling (RR
 Time management

 Time interrupt : A high resolution hardware timer is

programmed to interrupt the processor at fixed rate

 Each time interrupt is called a system tick

 The tick may be chosen according to the given task

parameters
Resource Allocation in RTOS
 Resource Allocation
 The issues with scheduling applicable here.
 Resources can be allocated in
 Round Robin
 Priority Based
 Some resources are non preemptible
 Example : semaphores
 Priority Inversion if priority scheduling is used
Priority Inversion
Solutions to Priority Inversion
 Non Blocking Critical Section
 Higher priority Thread may get blocked by unrelated
low priority thread
 Priority Ceiling
 Each resource has an assigned priority
 Priority of thread is the highest of all priorities of the
resources it’s holding
 Priority Inheritance
 The thread holding a resource inherits the priority of the
thread blocked on that resource
Other RTOS issues
 Interrupt Latency should be very small
 Kernel has to respond to real time events
 Interrupts should be disabled for minimum possible
time
 For embedded applications Kernel Size should be
small
 Should fit in ROM
 Sophisticated features can be removed
 No Virtual Memory
 No Protection
 Existing RTOS categories


 RT Linux: an example
 RT-Linux is an operating system, in which a
small real-time kernel co-exists with standard
Linux kernel
RT Linux Kernel
Why Linux

 Coexistence of Real Time Applications with

non Real Time Ones
 Example http server
 Device Driver Base
 Stability
RTLinux
 Real Time Kernel at the lowest level
 Linux Kernel is a low priority thread
 Executed only when no real time tasks
 Interrupts trapped by the Real Time Kernel
and passed onto Linux Kernel
 Software emulation to hardware interrupts
 Interrupts are queued by RTLinux
 Software emulation to disable_interrupt()
RTLinux (contd)
 Real Time Tasks
 Statically allocate memory
 No address space protection
 Non Real Time Tasks are developed in
Linux
 Communication
 Queues
 Shared memory
RTLinux Framework
rtker – Our RTOS
 Motivation
 Our own OS
 Full grasp over source code – Easily modifiable, portable
 Features
 Modular Design
 Isolation of Architecture/CPU dependent and independent code
– Easy to Port
 Pluggable Scheduler
 Two level Interrupt Handling
 Small footprint
 Oskit’s Device Driver Framework
Pluggable Scheduler

 Scheduler - part of the Application

 Kernel interacts with the scheduler through
an API
 Application developer needs to implement
the scheduler API
 Can optimize on Data Structures & Algorithms
for implementing the scheduler
rtker – Block Diagram
Two Level Interrupt Handling
 Two level Interrupt Handling
 Top Half Interrupt Handler
 Called Immediately – Kernel never disables interrupts
 Cannot invoke thread library functions - Race Conditions
 Bottom Half Interrupt Handler
 Invoked when kernel not in Critical Section
 Can invoke thread library functions
 Very Low Response time (as compared to Linux)
Two Level Interrupt Handling
Other Features

 Footprint
 Small footprint (~50kb)
 Oskit’s Device Driver Framework
 Allows direct porting of existing drivers from
Linux.
 Example – Ethernet Driver of Linux
Other RTOS’s
 LynxOS
 Microkernel Architecture
 Kernel provides scheduling/interrupt handling
 Additional features through Kernel Plug Ins(KPIs)
 TCP/IP stack , Filesystem
 KPI’s are multithreaded
 Memory Protection/ Demand Paging Optional
 Development and Deployment on the same host
 OS support for compilers/debuggers
Other RTOS’s (contd)

 VxWorks
 Monolithic Architecture
 Real Time Posix compliant
 Cross development System
 pSOS
 Object Oriented OS
Peripheral devices and protocols
• Interfacing
Serial/parallel ports, USB, I2C, PCMCIA, IDE
• Communication
Serial, Ethernet, Low bandwidth radio, IrDA,
802.11b based devices
• User Interface
LCD, Keyboard, Touch sensors, Sound, Digital
pads, Webcams
• Sensors
A variety of sensors using fire, temperature,
pressure, water level, seismic, sound, vision
 Conclusion


Scheduling in RTOS
 More information about the tasks are known
 No of tasks
 Resource Requirements
 Release Time
 Execution time
 Deadlines
 Being a more deterministic system better
scheduling algorithms can be devised.
Scheduling Algorithms in RTOS

 Clock Driven Scheduling

 Weighted Round Robin Scheduling

 Priority Scheduling
(Greedy / List / Event Driven)
Scheduling Algorithms in RTOS (contd)

 Clock Driven
 All parameters about jobs (release time/
execution time/deadline) known in advance.
 Schedule can be computed offline or at some
regular time instances.
 Minimal runtime overhead.
 Not suitable for many applications.
Scheduling Algorithms in RTOS (contd)
 Weighted Round Robin
 Jobs scheduled in FIFO manner
 Time quantum given to jobs is proportional to it’s
weight
 Example use : High speed switching network
 QOS guarantee.
 Not suitable for precedence constrained jobs.
 Job A can run only after Job B. No point in giving time
quantum to Job B before Job A.
Scheduling Algorithms in RTOS (contd)
 Priority Scheduling
(Greedy/List/Event Driven)
 Processor never left idle when there are ready
tasks
 Processor allocated to processes according to
priorities
 Priorities
 static - at design time
 Dynamic - at runtime
Priority Scheduling

 Earliest Deadline First (EDF)

 Process with earliest deadline given highest priority
 Least Slack Time First (LSF)
 slack = relative deadline – execution left
 Rate Monotonic Scheduling (RMS)
 For periodic tasks
 Tasks priority inversely proportional to it’s period