Scribd
Upload
268 views34 pages

Real Time Operating System in Embedded S PDF

This document provides an overview of real-time operating systems for embedded systems. It defines hard and soft real-time systems and explains the role of an OS in real-time applications. Key features of real-time OSs discussed include scheduling, resource allocation, interrupt handling, and other issues. Specific RTOSes covered are Linux with RTLinux, LynxOS, VxWorks, and pSOS. Application examples include a fire alarm system using wireless sensors.

Uploaded by

Fandik Armansyah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
268 views34 pages

Real Time Operating System in Embedded S PDF

This document provides an overview of real-time operating systems for embedded systems. It defines hard and soft real-time systems and explains the role of an OS in real-time applications. Key features of real-time OSs discussed include scheduling, resource allocation, interrupt handling, and other issues. Specific RTOSes covered are Linux with RTLinux, LynxOS, VxWorks, and pSOS. Application examples include a fire alarm system using wireless sensors.

Uploaded by

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

REAL TIME OPERATING SYSTEM FOR

EMBEDDED SYSTEMS

MOHD YASIR KHAN


B.TECH-VII SEM

Department of Electronics and Communication Engineering


Faculty of Engineering and Technology
Jamia Millia Islamia University
New Delhi
PRESENTATION OUTLINE
Definitions
Role of an OS in Real Time Systems
Features of Real Time Operating Systems
 Scheduling
 Resource Allocation
 Interrupt Handling
 Other Issues
Linux for Real Time Systems and RTLinux
Other RTOS’s
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
HARD AND SOFT REAL TIME
SYSTEMS
Hard Real Time System
 Failure to meet deadlines is fatal
 example : Flight Control System
Soft Real Time System
 Late completion of jobs is undesirable but not fatal.
 System performance degrades as more & more jobs miss
deadlines
 Online Databases
(Qualitative Definition)
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
FEATURES OF RTOS’S
Scheduling.

Resource Allocation.

Interrupt Handling.

Other issues like kernel size.


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
RESOURCE ALLOCATION IN RTOS
Resource Allocation
 The issues with scheduling applicable here.
 Resources can be allocated in
 Weighted 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
LINUX FOR REAL TIME
APPLICATIONS
Scheduling
 Priority Driven Approach
 Optimize average case response time
 Interactive Processes Given Highest Priority
 Aim to reduce response times of processes
 Real Time Processes
 Processes with high priority
 No notion of deadlines
Resource Allocation
 No support for handling priority inversion
INTERRUPT HANDLING IN LINUX
Interrupts are disabled in ISR/critical sections of
the kernel
No worst case bound on interrupt latency
avaliable
eg: Disk Drivers may disable interrupt for few
hundred milliseconds
Not suitable for Real Time Applications
Interrupts may be missed
OTHER PROBLEMS WITH LINUX
Processes are non preemtible in Kernel Mode
System calls like fork take a lot of time
High priority thread might wait for a low priority
thread to complete it’s system call
Processes are heavy weight
Context switch takes several hundred
microseconds
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
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
AN EXAMPLE: 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
RTOS: TARGET ARCHITECTURES

Processors MIPS

Microcontrollers ~20
ARM7 100-133
ARM9 180-250
Strong ARM 206
Intel Xscale 400
Mips4Kcore 400
X86
THANK YOU!

You might also like