Interrupt handling is illustrated below.
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.