Page 269 - Embedded Microprocessor Systems Real World Design

Use of an RTOS also can affect the hardware. In the previous example, the
analog-todigital (AD) conversion was assumed to be polled in some manner by the
AD conversion routine. In a preemptive RTOS environment, it may make more
sense to have the ADC cause an interrupt when conversion is complete, allowing
the ADC read to operate at the (high-priority) ISR level.
Another consideration to keep in mind is that any RTOS call can potentially
cause a task switch. In a polling loop like that used in the pool timer, all the inputs
(potential events) are checked once for each pass through the polling loop. Once
a “task” gets control, it keeps control until it is finished. In an RTOS environment,
if the task were to call an RTOS function that passes a semaphore to another task,
the second task may become higher priority and take control. The first task would
be suspended until it again becomes the highest-priority task. In this specific
example, you would probably expect that to happen-passing a semaphore is
expected to wake up the second task.
The same thing can happen if an interrupt occurs during execution of a task-
a higher-priority task may be waiting for that interrupt, and the RTOS may switch
to the other task. The implications of this must be taken into account when design-
ing with an RTOS, as code must be written with the assumption that a task may be
preempted at any time. In addition, assigning priorities to tasks is important for
the same reason.
Another possible preemption problem involves saving the context of the system.
Suppose part of the context includes hardware, such as the state of registers in a
peripheral IC. A task (call it “Z”) saves the context, then is preempted. After enough
time passes, the state of the hardware has changed and the original saved context
is no longer valid. However, when Z again becomes the highest-priority task, it
finishes whatever it was doing and restores the hardware context to the obsolete
value. Although this can happen in a polled environment, an RTOS can open
the window of opportunity due to the fact that a task may remain preempted for
some time.

Applicability of RTOS

An RTOS is not suited to every application. Specifically, an RTOS probably is not
a good solution if the device must execute very-high-speed interrupts, such as a low-
level motor controller, or if the system is simple enough to make an RTOS more
work than a simple sequential or state machine design. This does not preclude the
use of an RTOS if an occasional interrupt occurs that requires immediate service,
but the closer the processor is to bit-level control of the hardware, the less sense
an RTOS usually makes.

250 Embedded Micrqkocessm Systems