Unless explicitly stated, this book refers to both pseudo and true parallel execution as concurrent execution for the sake of simplicity.
Following the outside-in approach, certain types of tasks can be identified near the application edge (i.e., where an application needs to create an interface with an I/O device), whereas other tasks can be internal to the application. From the mobile handheld example, if a design team were to further decompose the application, these internal tasks would be identified. Applications, such as calculator or calendar programs, are some examples of internal tasks or groupings of tasks that can exist within the overall handheld mobile application. These internal tasks are decoupled from the I/O devices; they need no device-specific information in order to run
Guideline 1: Identify Device Dependencies
· Guideline 1a: Identify Active I/O Devices
· Guideline 1b: Identify Passive I/O Devices
Guideline 2: Identify Event Dependencies
Guideline 3: Identify Time Dependencies
· Guideline 3a: Identify Critical and Urgent Activities
· Guideline 3b: Identify Different Periodic Execution Rates
· Guideline 3c: Identify Temporal Cohesion
Guideline 4: Identify Computationally Bound Activities
Guideline 5: Identify Functional Cohesion
Guideline 6: Identify Tasks that Serve Specific Purposes
Guideline 7: Identify Sequential Cohesion
Guideline 1: Identify Device Dependencies
All real-time systems interface with the physical world through some devices, such as sensors, actuators, keyboards, or displays. An application can have a number of I/O devices interfacing to it. Not all devices, however, act as both input and output devices. Some devices can act just as inputs or just as outputs. Other devices can act as both. The discussions in this book refer to all of these devices as I/O devices.
The outside-in approach focuses on looking at the I/O devices in a system and assigning a task to each device. The basic concept is that unsynchronized devices need separate handling. For simple device interactions, processing within an ISR may suffice; however, for additional device processing, a separate task or set of tasks may be assigned. Both active and passive I/O devices should be considered for identifying potential areas of an application that can be decomposed into concurrent tasks.
As shown in Figure 14.4, hardware I/O devices can be categorized as two types:
· Active I/O devices
· Passive I/O devices
Figure 14.4: Some general properties of active and passive devices.
Active I/O devices generate interrupts to communicate with an application. These devices can generate interrupts in a periodic fashion or in synch with other active devices. These devices are referred to in this book as synchronous. Active devices can also generate interrupts aperiodically, or asynchronously, with respect to other devices. These devices are referred to in this book as asynchronous .
Passive I/O devices do not generate interrupts. Therefore, the application must initiate communications with a passive I/O device. Applications can communicate with passive devices in a periodic or aperiodic fashion.
Active devices generate interrupts whether they are sending input to or receiving output from the CPU. Active input devices send an interrupt to the CPU when the device has new input ready to be processed. The new input can be a large buffer of data, a small unit of data, or even no data at all. An example of the latter is a sensor that generates an interrupt every time it detects some event. On the other hand, an active output device sends an interrupt to the CPU when the device has finished delivering the previous output from the CPU to the physical world. This interrupt announces to the CPU and the application that the output device has completed the last request and is ready to handle the next request.
Passive input or output devices require the application to generate the necessary requests in order to interact with them. Passive input devices produce an input only when the application requests. The application can make these requests either periodically or aperiodically. In the case of the former, the application runs in a periodic loop and makes a request every time through the loop, called polling a device. For aperiodic requests, the application makes the request only when it needs the data, based on an event asynchronous to the application itself, such as an interrupt from another device or a message from another executing task.
Special care must be taken when polling a passive input device, especially when sampling a signal that has sharp valleys or peaks. If the polling frequency is too low, a chance exists that a valley or peak might be missed. If the polling frequency is too high, extra performance overhead might be incurred that uses unnecessary CPU cycles.
Guideline 1a: Identify Active Devices
Active input or output I/O devices use interrupts to communicate with real-time applications. Every time an active input device needs to send data or notification of an event to a real-time application, the device generates an interrupt. The interrupt triggers an ISR that executes the minimum code needed to handle the input. If a lot of processing is required, the ISR usually hands off the process to an associated task through an inter-task communication mechanism.
Similarly, active output devices also generate interrupts when they need to communicate with applications. However, interrupts from active output devices are generated when they are ready to receive the next piece of data or notification of some event from the application. The interrupts trigger the appropriate ISR that hands off the required processing to an associated task using an inter-task communication mechanism.
The diagram for both an active I/O device acting as an input or an output to an application and for a device generating interrupts in a synchronous or asynchronous manner is similar to the one illustrated in Figure 14.5.
Figure 14.5: General communication mechanisms for active I/O devices.
Some typical tasks that can result from identifying an active I/O device in a real-time application are listed in Table 14.1.
Table 14.1: Common tasks that interface with active I/O devices.
Task Type |
Description |
Asynchronous Active Device I/O Task |
Assigned to active I/O devices that generate aperiodic interrupts or whose operation is asynchronous with respect to other I/O devices. |
Synchronous Active Device I/O Task |
Assigned to active I/O devices that generate periodic interrupts or whose operation is synchronous with respect to other I/O devices. |
Resource Control Device I/O Task |
Assigned for controlling the access to a shared I/O device or a group of devices. |
Event Dispatch Device I/O Task |
Assigned for dispatching events to other tasks from one or more I/O devices. |
Recommendation 1: Assign separate tasks for separate active asynchronous I/O devices.Active I/O devices that interact with real-time applications do so at their own rate. Each hardware device that uses interrupts to communicate with an application and whose operation is asynchronous with respect to other I/O devices should be considered to have their own separate tasks.
Читать дальше