Scribd
Upload
111 views

Arm Rtos

A real-time system is one that is required to complete tasks and deliver services within strict time deadlines. Hard real-time systems have fatal consequences for missed deadlines, while soft real-time systems have degraded performance. Real-time operating systems (RTOS) are variants of operating systems designed for constrained environments with limited resources and strict timing requirements. RTOS kernels provide services like task management, intertask communication, timers, and device I/O to help applications meet deadlines in a deterministic manner through priority-based preemptive scheduling.

Uploaded by

dhapra
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
111 views

Arm Rtos

A real-time system is one that is required to complete tasks and deliver services within strict time deadlines. Hard real-time systems have fatal consequences for missed deadlines, while soft real-time systems have degraded performance. Real-time operating systems (RTOS) are variants of operating systems designed for constrained environments with limited resources and strict timing requirements. RTOS kernels provide services like task management, intertask communication, timers, and device I/O to help applications meet deadlines in a deterministic manner through priority-based preemptive scheduling.

Uploaded by

dhapra
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 24

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
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
Real-time and embedded systems operate in
constrained environments in which computer
memory and processing power are limited.

They often need to provide their services within


strict time deadlines to their users and to the
surrounding world.

It is these memory, speed and timing constraints


that dictate the use of real-time operating
systems in embedded software.
RTOS
A variant of OS that operates in constrained environment
in which computer memory and processing power is
limited.

Moreover they often need to provide their services in


definite amount of time.

Hard, Soft & Firm RTOS


Example RTOS: VxWorks, pSOS, Nucleus, RTLinux…
Structure of a RTOS

Applications

RTOS-kernel
BSP

Custom-Hardware
"kernel" ?
The part of an operating system that provides the
most basic services to application software
running on a processor.

The "kernel" of a real-time operating system


("RTOS") provides an "abstraction layer" that
hides from application software the hardware
details of the processor (or set of processors)
upon which the application software will run.
Components of RTOS
 The most important component of RTOS is its
kernel (Monolithic & Microkernel).

 BSP or Board Support Package makes an RTOS


target-specific (It’s a processor specific code onto (processor) which we like to
have our RTOS running).
RTOS KERNEL
Task Management:
This set of services allows application software developers to design their software
as a number of separate "chunks" of software

-- each handling a distinct topic, a distinct goal, and perhaps its own real-time
deadline.

Each separate "chunk" of software is called a "task.“

Services in this category include the ability to launch tasks and assign priorities to
them.

The main RTOS service in this category is the scheduling of tasks as the embedded
system is in operation.

The Task Scheduler controls the execution of application software tasks, and can
make them run in a very timely and responsive fashion.
Intertask Communication and Synchronization:

These services make it possible for tasks to pass information from one
to another, without danger of that information ever being damaged.

They also make it possible for tasks to coordinate, so that they can
productively cooperate with one another.

Without the help of these RTOS services, tasks might well communicate
corrupted information or otherwise interfere with each other.
Timers:
Many embedded systems have stringent timing requirements

Most RTOS kernels also provide some basic Timer services,

such as task delays and time-outs.


Dynamic Memory Allocation:
Many (but not all) RTOS kernels provide Dynamic Memory Allocation
services.

This category of services allows tasks to "borrow" chunks of RAM


memory for temporary use in application software.

Often these chunks of memory are then passed from task to task, as a
means of quickly communicating large amounts of data between tasks.

Some very small RTOS kernels that are intended for tightly memory-
limited environments, do not offer Dynamic Memory Allocation
services.
Device I/O Supervisor:
Many (but not all) RTOS kernels also provide a "Device I/O Supervisor"
category of services.

These services, if available, provide a uniform framework for organizing


and accessing the many hardware device drivers that are typical of an
embedded system.
In addition to kernel services, many RTOSs offer a number of optional
add-on operating system components for such high-level services as
file system organization,
network communication,
network management,
database management,
user-interface graphics, etc.

Each of these add-on components is included in an embedded system


only if its services are needed for implementing the embedded
application, in order to keep program memory consumption to a
minimum.
RTOSs vs. general-purpose operating systems
Real-time operating systems is the need for " deterministic " timing
behaviour in the real-time operating systems.

Formally, "deterministic" timing means that operating system services


consume only known and expected amounts of time.

General-computing non-real-time operating systems are often quite non-


deterministic.

Their services can inject random delays into application software and thus
cause slow responsiveness of an application at unexpected times.
Task scheduling
Most RTOSs do their scheduling of tasks using a scheme called
"priority-based preemptive scheduling.“

Each task in a software application must be assigned a priority, with higher


priority values representing the need for quicker responsiveness.

Very quick responsiveness is made possible by the "preemptive" nature of


the task scheduling.

"Preemptive" means that the scheduler is allowed to stop any task at any
point in its execution, if it determines that another task needs to run
immediately.
The basic rule that governs priority-based preemptive scheduling is
that at every moment in time, "The Highest Priority Task that is Ready
to Run, will be the Task that Must be Running.“

In other words, if both a low-priority task and a higher-priority task are


ready to run, the scheduler will allow the higher-priority task to run
first.

The low-priority task will only get to run after the higher-priority task
has finished with its current work.
Each time the priority-based preemptive scheduler is alerted by an
external world trigger (such as a switch closing) or a software trigger
(such as a message arrival),
it must go through the following 5 steps:
• Determine whether the currently running task should continue to
run.
• If not ? Determine which task should run next.
• Save the environment of the task that was stopped (so it can continue
later).
• Set up the running environment of the task that will run next.
• Allow this task to run.
These 5 steps together are called "task switching."
Intertask communication and synchronization
RTOSs, offer a variety of mechanisms for communication and
synchronization between tasks.

These mechanisms are necessary in a pre-emptive environment of


many tasks.

Without them the tasks might well communicate corrupted


information or otherwise interfere with each other.
The most popular kind of communication between tasks in embedded
systems is the passing of data from one task to another.
Most RTOSs offer a message passing mechanism
• Most RTOSs offer a semaphore or mutex mechanism for handling
negative synchronization (sometimes called "mutual exclusion").

• These mechanisms allow tasks to lock certain embedded system


resources for their use only, and subsequently to unlock the resource
when they're done.

• For positive synchronization, different RTOSs offer different


mechanisms. Some RTOSs offer event-flags, while others offer signals.
Determinism and high-speed message passing

You might also like