|
A Guide to online information
about:
Real-Time
Operating Systems
by Benjamin
Day
Real-Time Operating Systems
A real-time operating system (RTOS) offers
services that allow tasks to be performed within predictable timing
constraints. Or, more simply put, an RTOS allows applications to be
executed in a timely manner. What is timely will be largely defined
by the application. For example, when filling your automobile's gas
tank at a Chevron FastPay service station, you would expect the credit
card to authorize the transaction within a finite period of time,
a few seconds at most, regardless of how many others are also using
the system.
According to the Comp.Realtime
Newsgroup FAQ,
to guarantee timeliness, an RTOS must have several characteristics,
including multitasking, preemption, priority, predictable task synchronization,
priority inheritance and known behavior. (In case a few of these terms
sound a bit unfamiliar to you, I have included a glossary later in
this article.) Interestingly, with a little inspection, you will find
that some of the RTOS products that I list here do not actually provide
all of these characteristics, or at least leave some of these characteristics
out of their default configurations.
One such characteristic is preemption,
or the ability of the operating system to switch tasks without the
express permission of the current task. Some RTOS vendors argue that
when priorities are appropriately assigned to tasks during design,
it is possible to eliminate the need for preemption. Generally, the
vendors who take this perspective disable preemption in the default
configuration of their RTOS, however you can easily enable the feature
if you have a differing opinion on the issue.
The other such characteristic is priority
inheritance. A problem can arise when a high-priority task must wait
for a resource that is owned by a low-priority process. Because many
tasks may be executing with a higher priority than the resource owner,
the resource owner may not be able to complete its task within a timely
period. When this condition occurs, the high-priority task has effectively
assumed the priority of the resource owner. Many RTOS vendors resolve
this problem by allowing the resource owner to inherit the priority
of the highest priority task waiting for the resource, thus allowing
the real-time demands of the high-priority waiting tasks to be met.
Again, some RTOS vendors do not offer this feature, arguing that careful
design will eliminate the need for priority inheritance.
Of all the RTOS characteristics mentioned
in the Comp.Realtime
Newsgroup FAQ, the most difficult
is certainly known OS behavior. The FAQ suggests knowing the following
details of the RTOS you are using: interrupt latency, maximum execution
times of all system calls and the maximum time that the RTOS and interrupt
service routines disable interrupts. Unfortunately, this information
is not so easily obtained. Each RTOS vendor tends to support dozens
of processors and on a given processor, many architectural issues
including pipelining, cache, and bus design play a significant role
in these timings making it impossible for the RTOS vendor to provide
this information to you on a datasheet. However, if you are fortunate
enough to have working hardware prior to selecting an RTOS, you may
want to insist on evaluating the product and collecting this timing
data on your own hardware.
A superior RTOS will guarantee timeliness
of your application at a higher processor utilization than other RTOSs.
You will not want to overlook the timing issues because they will
play a major roll in whether your RTOS can deliver processor utilization
or processor capacity necessary for your application while still guaranteeing
it real-time performance.
However, as a quick caution, you can
bring even a superior RTOS to its knees if your own application has
ill-behaved interrupt handlers. Your RTOS vendor has likely coded
extremely small interrupt service routines, and may only disable interrupts
for the first few instructions of the interrupt handler to improve
interrupt latency. Your interrupt service routines should also be
as short as possible. The interrupt service routines should leave
the real work to the real-time tasks.
Vendors
One of the hardest tasks of developing
an embedded system can be figuring out what RTOS vendor supports your
processor. Hopefully, the subsequent tables will help you figure out
some of your alternatives.
Real-time operating systems for 8-bit
processors
Real-time operating systems for 16-bit
processors
Real-time operating systems by vendor
Reference Resources
Here are a few references that you should
find useful if you want to take a look at the theory and understand
the software-engineering approach to real-time systems.
Real-Time
Systems Design and Analysis : An Engineer's Handbook
by Philip A. Laplante
Structured
Development for Real-Time Systems : Essential Modeling Techniques
by Paul T. Ward and Stephen J. Mellor
A
Practitioner's Handbook for Real-Time Analysis : Guide to Rate Monotonic
Analysis for Real-Time Systems
by Mark H. Klein, Thomas Ralya, Bill Pollak and Ray Obenza
Also, earlier I mentioned that some RTOS
vendors chose to ignore priority inversion while others implement
priority inheritance algorithms to solve the problem. If you want
more detailed information about the subject, here is an excellent
paper to read:
Sha, L., Rajkumar, R. and Sathaye, S.:
Priority Inheritance Protocols: An Approach to Real-Time Synchronization.
IEEE Transactions on Computers, Vol. 39(9). pp.1175-1185.
Glossary of RTOS Terms
| Atomic |
An operation is said
to be atomic if it can be completed without interruption. |
| Context
Switch |
The process of changing
execution from one process to the next. The time required to perform
a context switch will have a significant impact on performance.
So, knowing how much information is stored as part of a task's
context may be important to you. The minimum amount of information
required to perform a context switch is largely processor dependent,
however, the RTOS vendor may have chosen to include some extra
information that will slow down the context switch. |
| Cooperative
multitasking |
In a cooperative multitasking
environment, generally the current running task will be allowed
to run until it completes or until it chooses to yield to another
task. Yielding to another task may be explicit through a call
to a yield function or it may be implied through a call to a function
that may cause it to wait for an event or resource. |
Counting
Semaphore |
A mechanism for synchronizing
processes and their access to resources. |
| Critical
Section |
A section of code in
a program that must be executed while no other piece of code is
running. Typically, this means that all interrupts must be disabled.
So, critical sections should be kept as small as possible. |
| Deadlock |
Deadlock is a condition
where multiple processes may be waiting for a resource to be made
available which will never become available. Generally, the programmer
must design the system to prevent deadlock from occuring. The
typical approach to preventing deadlock in an embedded system
is for tasks to always request needed resources in a predefined
order. |
| Deferred
interrupt processing |
Deferred interrupt processing
is an approach used to minimize interrupt latency by reducing
the amount of time spent inside interrupt service routines. Typically,
the interrupt handler sends a message to the operating system
indicating that the interrupt has occurred allowing the operating
system to invoke a task to handle the external event. The improved
interrupt latency due to this approach should result in more deterministic
behavior of the system. |
| Event |
An event is generally
a mechanism provided by the RTOS to permit communications between
processes. |
| Interprocess
communications |
Processes or tasks generally
need a synchronized method of communications. The relationship
between the tasks could be various, including one-to-one, one-to-many,
or many-to-many. An RTOS needs to provide mechanisms to permit
all of these kinds of communications. Common mechanisms include
mailboxes, queues, and events. |
Memory
management |
Real-time operating
systems frequently provide specialized memory management routines
to help solve common embedded system problems. An RTOS may provide
the ability to allocate memory in fixed sized blocks or from distinct
memory pools, each of which may have special purposes. For example,
distinct server processes may have unique memory pools for allocation.
Typically the goal is to help avoid memory fragmentation that
could lead to a system failure. |
| Mailbox |
A mechanism provided
by an RTOS for interprocess communications. A process may have
a mailbox that other processes can send messages to. |
Multitasking/
Timeslicing |
A CPU typically can
only have a single state or context. Essentially, the CPU can
only do one thing at a time. Mutitasking the process of frequently
changing context to make it appear as if the CPU were performing
multiple tasks simultaneously. This task switching may occur on
either a cooperative or preemptive multitasking basis. |
| Mutual Exclusion |
Refers to ensuring that
a shared resource cannot be accessed simultaneously to prevent
unwanted interaction. One example of the need for mutual exclusion
would be keyboard I/O. Generally, an operating system must ensure
that only one process can have access to the keyboard at a time |
Preemptive
multitasking |
In a preemptive multitasking
system, a supervisor or scheduling task can change which task
is currently executing without the permission of the current task.
In a preemptive system, the scheduler will generally switch tasks
at a periodic interval known as the timeslice. |
| Priority |
In a real-time operating
system, tasks can be assigned a priority. Usually, the scheduler
will allow higher priority tasks to run before lower priority
tasks are allowed to run. However, there may be a lot of variations
between different real-time operating systems and how they treat
tasks varying priorities. Some systems will not allow lower priority
tasks to execute at all until the higher priority tasks have completed.
Other systems may assign larger time slices to higher priority
task, yet still allow low priority tasks to execute with a smaller
time slice. |
Priority
Inheritance |
Priority inheritance,
an approach to dealing with the problem of priority inversion,
allows a low-priority task to become high priority if it owns
a resource that a high-priority task is waiting for. The goal
of priority inheritance is to minimize the amount of time high-priority
tasks are required to wait for needed resources. |
| Priority
Inversion |
In a system where a
high- and a low-priority task may both need access to the same
resource, it is possible that the high-priority task may have
to wait for the low-priority task to complete. This is called
priority inversion. In such a situation, the low-priority task
may not get its time slice until other high-priority tasks complete. |
Process/
Thread/Task |
A process, thread, or
task is a unit of execution. The use of these terms may be somewhat
indistinguishable at times, especially from one RTOS to the next.
However, some environments actually define more than one of these.
For example, under Windows NT, a process is usually an executable
program. And that process may have multiple smaller threads associated
with it. Sometimes, as is the case with Windows NT, the terminology
in part describes how much context information is associated with
it. |
| Queue |
A mechanism provided
by an RTOS for interprocess communications. Usually, one process
acts as a consumer, removing messages from the queue. And, one
or many processes may act as producers adding messages to the
queue. |
| Reentrant/Non-Reentrant |
Reentrant code is code
which does not rely on being executed without interruption before
completion. Reentrant code can be used by multiple, simultaneous
tasks. Reentrant code generally does not access global data. Variables
within a reentrant function are allocated on the stack, so each
instance of the function has its own private data. Non-reentrant
code, to be used safely by multiple processes, should have access
controlled via some synchronization method such as a semaphore. |
| Resource |
A resource is usually
a mechanism provided by the RTOS to synchronize access to an object
within the system, which requires mutually exclusive access. The
object within the system, also frequently called a resource, may
be a physical device such as a keyboard or an EEPROM, or just
a system variable. |
| Scheduler |
The scheduler is the
portion of the RTOS responsible for determining which task will
run next. Real-time operating systems use a wide variety of algorithms
for making this selection. Sometimes it is as simple as just allowing
the next available process with the highest priority to run. Other
systems may have a hybrid prioritized round-robin system where
tasks are only allowed to run for a specific timeslice before
the next task is run. |
| Semaphore |
A mechanism for ensuring
mutual exclusion or synchronizing processing related to a resource. |
| Time slice |
The largest amount of
time that a task will be allowed to run in a preemptive multitasking
system before the scheduler may invoke a new task. |
If you would like
to add any information on this topic or request a
specific topic to be covered, contact Benjamin
Day. Ben Day works for Schweitzer Engineering Laboratories
in Pullman, Washington making electric power safer, more reliable,
and more economical.
Circuit Cellar provides up-to-date information
for engineers. Visit www.circuitcellar.com
for more information and additional articles.
For subscription information, call (860) 875-2199, subscribe@circuitcellar.com
or subscribe
online. ęCircuit Cellar, the Magazine for Computer Applications.
Posted with permission.
|
RESOURCE
PAGES
