Hardware Reference
In-Depth Information
application tasks. For example, in order to get data from an I/O device, each task must
enable the hardware to generate interrupts, wait for the interrupt, and read the data
from a memory buffer shared with the driver, according to the following protocol:
< enable device interrupts >
< wait for interrupt >
< get the result >
In many operating systems, interrupts are served using a fixed priority scheme, accord-
ing to which each driver is scheduled based on a static priority, higher than process
priorities. This assignment rule is motivated by the fact that interrupt handling routines
usually deal with I/O devices that have real-time constraints, whereas most applica-
tion programs do not. In the context of real-time systems, however, this assumption is
certainly not valid, because a control process could be more urgent than an interrupt
handling routine. Since, in general, it is very difficult to bound a priori the number of
interrupts that a task may experience, the delay introduced by the interrupt mechanism
on tasks' execution becomes unpredictable.
In order to reduce the interference of the drivers on the application tasks and still
perform I/O operations with the external world, the peripheral devices must be handled
in a different way. In the following, three possible techniques are illustrated.
APPROACH A
The most radical solution to eliminate interrupt interference is to disable all external
interrupts, except the one from the timer (necessary for basic system operations). In
this case, all peripheral devices must be handled by the application tasks, which have
direct access to the registers of the interfacing boards. Since no interrupt is generated,
data transfer takes place through polling.
The direct access to I/O devices allows great programming flexibility and eliminates
the delays caused by the drivers' execution. As a result, the time needed for trans-
ferring data can be precisely evaluated and charged to the task that performs the op-
eration. Another advantage of this approach is that the kernel does not need to be
modified as the I/O devices are replaced or added.
The main disadvantage of this solution is a low processor efficiency on I/O operations,
due to the busy wait of the tasks while accessing the device registers. Another minor
problem is that the application tasks must have the knowledge of all low-level details
of the devices that they want to handle. However, this can be easily solved by encap-
Search WWH ::




Custom Search