Page 266 - Embedded Microprocessor Systems Real World Design

RTOS and Interrupts

Obviously, an RTOS needs to handle interrupts if it is to manage a real-time
operating system. When an interrupt occurs, the processor hardware handles the
interrupt as it normally would, saving the return address and vectoring to the ISR.
Assuming that a task is running when the interrupt occurs, the return address is
saved on that task’s stack. An RTOS usually will have special kernel services for
interrupts. When the ISR gets control, it can use these special services.
The simplest ISR servicing technique is to set a semaphore, do whatever must
be done to reset the hardware that generated the interrupt, and then exit.
Consequently, an RTOS usually will provide at least three kinds of services for ISRs.
The first service, interrupt entry, allows the ISR to notify the RTOS that the inter-
rupt occurred. The interrupt entry routine may save the processor context or other
information and may be a generic routine provided by the RTOS vendor. The
second ISR service is to request a semaphore set. The third service is an exit service
call that notifies the RTOS when interrupt servicing is complete.
Special RTOS services are provided for ISRs because the ISRs cannot use the
normal RTOS services. The normal RTOS services usually do not allow reentry. If
an interrupt occurs while the RTOS is executing and the ISR attempts to use the
RTOS function that was executing, disaster usually will result.
When the ISR exits (via the RTOS), the RTOS may perform a task switch, giving
another task higher priority than the one that was interrupted. In the serial
communication example, the receive interrupt may cause the RTOS to switch to
the receive task. When the receive task is done, the RTOS can return control to the
interrupted task. Since the processor context was saved on the task stack, resum-
ing the task after an interrupt essentially is the same process as resuming a task that
has become unblocked.

Typical RTOS Communication

Every RTOS is different, but the following is a list of RTOS services that would be
typical (I made up descriptive names):

Define Task. This defines a task to be executed. The typical parameters passed
to the RTOS might include the task number, priority, and the task entry address.
Activate Task. Requests activation of a task. The parameters passed to RTOS
would include the task number.
Deactivate Task. Deactivates a task. The parameters would include the task
number.

Real-Time Operating Systems 247