Interrupt handling is illustrated below.
| Anchor | ||
|---|---|---|
|
OS_CFG_ISR_POST_DEFERRED_EN in os_cfg.h. When set to 0, µC/OS-III uses the Direct Post Method and when set to 1, µC/OS-III uses the Deferred Post Method. As far as application code and ISRs are concerned, these two methods are completely transparent. It is not necessary to change anything except the configuration value OS_CFG_ISR_POST_DEFERRED_EN to switch between the two methods. Of course, changing the configuration constant will require recompiling the product and µC/OS-III.
Before explaining why to use one versus the other, let us review their differences
|
| 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.
You can determine the interrupt latency, interrupt response, interrupt recovery, and task latency by adding the execution times of the code involved for each, as shown below.
Interrupt Latency = Maximum interrupt disable time;
Interrupt Response = Interrupt latency
+ Vectoring to the interrupt handler
+ ISR prologue;
Interrupt Recovery = Handling of the interrupting device
+ Posting a signal or a message to a task
+ OSIntExit() + OSIntCtxSw();
Task Latency = Interrupt response
+ Interrupt recovery
+ Time scheduler is locked;
The execution times of the µC/OS-III ISR prologue, ISR epilogue, OSIntExit(), and OSIntCtxSw(), can be measured independently and should be fairly constant.
It should also be easy to measure the execution time of a post call by using OS_TS_GET().
The scheduler is locked only when handling timers and therefore, task latency should be fast if there are few timers with short callbacks expiring at the same time. See Timer Management. µC/OS-III is also able to measure the amount of time the scheduler is locked, providing task latency.