Interrupt handling is illustrated below.
| Anchor | ||||
|---|---|---|---|---|
|
| Panel | ||||
|---|---|---|---|---|
| ||||
|
| Panel | ||
|---|---|---|
| ||
(1) A device generates an interrupt. (2) The Interrupt Service Routine (ISR) responsible to handle the device executes (assuming interrupts are enabled). The device interrupt is generally the event a task is waiting for. The task waiting for this interrupt to occur either has a higher priority than the interrupted task, or lower (or equal) in priority. (3) If the ISR made a lower (or equal) priority task ready-to-run then upon completion of the ISR, µC/OS-III returns to the interrupted task exactly at the point the interrupt occurred. (4) If the ISR made a higher priority task ready-to-run, µC/OS-III will context switch to the new higher-priority task since the more important task was waiting for this device interrupt. (5) µC/OS-III must protect critical sections by disabling interrupts as some of these critical sections can be accessed by ISRs. |
The above discussion assumed that interrupts were enabled and that the ISR could respond quickly to the interrupting device. However, if the application code makes µC/OS-III service calls (and it will at some point), it is possible that interrupts would be disabled. µC/OS-III disables interrupts while accessing critical sections. Thus, interrupts will not be responded to until µC/OS-III re-enables interrupts. Of course, everything was done to keep interrupt disable times as short as possible, but there are complex features of µC/OS-III that disable interrupts for relatively long periods of time.
...