Scribd
Upload
39 views

Real-Time Operating Systems Rtos

Real-time operating systems (RTOS) are designed for embedded systems where tasks must be completed on time to avoid fatal consequences. There are two types of real-time systems - hard where missing deadlines is fatal, and soft where late completions are undesirable. RTOS features include priority-based scheduling algorithms to deterministically allocate CPU time, small kernel size to minimize interrupt latency, and preemptive multitasking to ensure the highest priority ready task always runs. Task priorities are typically assigned based on importance and frequency of execution to meet timing constraints.

Uploaded by

Rajee singh
Copyright
© © All Rights Reserved
Available Formats
Download as ODP, PDF, TXT or read online on Scribd
39 views

Real-Time Operating Systems Rtos

Real-time operating systems (RTOS) are designed for embedded systems where tasks must be completed on time to avoid fatal consequences. There are two types of real-time systems - hard where missing deadlines is fatal, and soft where late completions are undesirable. RTOS features include priority-based scheduling algorithms to deterministically allocate CPU time, small kernel size to minimize interrupt latency, and preemptive multitasking to ensure the highest priority ready task always runs. Task priorities are typically assigned based on importance and frequency of execution to meet timing constraints.

Uploaded by

Rajee singh
Copyright
© © All Rights Reserved
Available Formats
Download as ODP, PDF, TXT or read online on Scribd
You are on page 1/ 25

Real-Time Operating Systems

RTOS

For Embedded systems


Real-Time Systems
• Result in severe consequences if logical
and timing correctness are not met
• Two types exist
– Soft real-time
• Tasks are performed as fast as possible
• Late completion of jobs is undesirable but not
fatal.
• System performance degrades as more & more
jobs miss deadlines
Real-Time Systems (cont.)
– Hard real-time
• Tasks have to be performed on time
• Failure to meet deadlines is fatal
• Example :
– Flight Control 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
Most Real-Time Systems are
embedded
• An embedded system is a computer built into a
system but not seen by users as being a
computer
• Examples
– FAX machines
– Copiers
– Printers
– Scanners
– Routers
– Robots
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
– File system / Network / Windowing support
– OS primitives reduce the software design time
Features of Real Time OS
(RTOS)
• Scheduling.

• Resource Allocation.

• Interrupt Handling.

• Other issues like kernel size.


Scheduling in RTOS
• More information about the tasks are
known
– Number of tasks
– Resource Requirements
– 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
Scheduling Algorithms in RTOS (cont.)

• Clock Driven
– All parameters about jobs (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 (cont.)

• Weighted Round Robin


– Jobs scheduled in FIFO manner
– Time quantum given to jobs is proportional to it’s
weight
Scheduling Algorithms in RTOS (cont.)

• Priority Scheduling
– 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
Schedulers
• Also called “dispatchers”
• Schedulers are parts of the kernel
responsible for determining which task
runs next
• Most real-time kernels use priority-
based scheduling
– Each task is assigned a priority based on its
importance
– The priority is application-specific
Preemptive Kernels
• The highest-priority task ready to run
is always given control of the CPU
– If an ISR makes a higher-priority task
ready, the higher-priority task is resumed
(instead of the interrupted task)
• Most commercial real-time kernels are
preemptive
Preemptive Kernels (cont.)
Advantages of Preemptive
Kernels
• Execution of the highest-priority task
is deterministic
Resource Allocation in RTOS
• Resource Allocation
– The issues with scheduling applicable here.
– Resources can be allocated in
• Weighted Round Robin
• Priority Based
• Priority inversion problem may occur if
priority scheduling is used
Assigning Task Priorities
• Not trivial
• In most systems, not all tasks are
critical
– Non-critical tasks are obviously low-
priorities
• Most real-time systems have a
combination of soft and hard
requirements
A Technique for Assigning Task
Priorities
• Rate Monotonic Scheduling (RMS)
– Priorities are based on how often tasks
execute
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
• There was no notion of deadlines
Interrupt Handling in Linux
• Interrupts were disabled in ISR/critical
sections of the kernel
• There was no worst case bound on
interrupt latency avaliable
– eg: Disk Drivers might disable interrupt for
few hundred milliseconds
Interrupt Handling in Linux
(cont.)
• Linux was not suitable for Real Time
Applications
– Interrupts may be missed
Other Problems with Linux
• Processes were not 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

You might also like