Even though an interrupt controller is present in most designs, some CPUs still vector to a common interrupt handler, and the ISR queries the interrupt controller to determine the source of the interrupt. At first glance, this might seem silly since most interrupt controllers are able to force the CPU to jump directly to the proper interrupt handler. It turns out, however, that with µC/OS-III, it’s easy to have the interrupt controller vector to a single ISR handler. Listing 9-4 describes the sequence of events to be performed when the interrupt controller forces the CPU to vector to a single location.
L9-4(1)An interrupt occurs from any device. The interrupt controller activates the interrupt pin on the CPU. If there are other interrupts that occur after the first one, the interrupt controller will latch them and properly prioritize the interrupts.L9-4
(2)The CPU vectors to a single interrupt handler address. In other words, all interrupts are to be handled by this one interrupt handler.
L9-4(3)The ISR executes the “ISR prologue” code needed by µC/OS-III. as previously described. This ensures that all ISRs will be able to make µC/OS-III “post” calls.L9-4
(4)You call a µC/OS-III C handler, which will continue processing the ISR. This makes the code easier to write (and read). Notice that interrupts are not re-enabled.L9-4
(5)The µC/OS-III C handler then interrogates the interrupt controller and asks it: “Who caused the interrupt?” The interrupt controller will either respond with a number (0 to N-1) or with the address of the interrupt handler for the highest priority interrupting device. Of course, the µC/OS-III C handler will know how to handle the specific interrupt controller since the C handler is written specifically for that controller.
...
The “while” loop terminates when there are no other interrupting devices to service.
L9-4(6)The µC/OS-III “ISR epilogue” is executed to see if it is necessary to return to the interrupted task, or switch to a more important one.
...