| Table of Contents |
|---|
µC/OS-III handles event posting from interrupts using two different methods: Direct and Deferred Post. The method used in the application is selected by changing the value of OS_CFG_ISR_POST_DEFERRED_EN in os_cfg.h. When set to DEF_DISABLED, µC/OS-III uses the Direct Post Method and when set to DEF_ENABLED, µC/OS-III uses the Deferred Post Method. Note that the Deferred Post method is currently DEPRECATED and will be removed in a future µC/OS-III release.
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.
Deferred Post Method
In the Deferred Post Method (OS_CFG_ISR_POST_DEFERRED_EN is set to DEF_ENABLED), instead of disabling interrupts to access critical sections, µC/OS-III locks the scheduler. This avoids having other tasks access critical sections while allowing interrupts to be recognized and serviced. In the Deferred Post Method, interrupts are almost never disabled. The Deferred Post Method is, however, a bit more complex as shown in the figure below. Note that the Deferred Post method is currently DEPRECATED and will be removed in a future µC/OS-III release.
All the extra processing is performed to avoid disabling interrupts during critical sections of code. The extra processing time only consist of copying the post call and arguments into the queue, extracting it back out of the queue, and performing an extra context switch.
Similar to the Direct Post Method, it is easy to determine interrupt latency, interrupt response, interrupt recovery, and task latency, by adding execution times of the pieces of 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 the Interrupt Queue
+ OSIntExit() + OSIntCtxSw() to Interrupt Queue Handler Task;
Task Latency = Interrupt response
+ Interrupt recovery
+ Re-issue the post to the object or task
+ Context switch to task
+ 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 constant.
It should also be easy to measure the execution time of a post call by using OS_TS_GET(). In fact, the post calls should be short in the Deferred Post Method because it only involves copying the post call and its arguments into the interrupt queue.
The difference is that in the Deferred Post Method, interrupts are disabled for a very short amount of time and thus, the first three metrics should be fast. However, task latency is higher as µC/OS-III locks the scheduler to access critical sections.
Direct Post Method
The Direct Post Method is used by µC/OS-II and is replicated in µC/OS-III. This method is enabled by default, the Deferred Post method is currently DEPRECATED and will be removed in a future µC/OS-III release. The figure below shows a task diagram of what takes place in a Direct Post.
The 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. When OS_CFG_ISR_POST_DEFERRED_EN is set to DEF_DISABLED, µC µ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.The key factor in determining whether to use the Direct Post Method is generally the µC/OS-III interrupt disable time. This is fairly easy to determine since the µC/CPU files provided with the µC/OS-III port for the processor used includes code to measure maximum interrupt disable time. This code can be enabled testing purposes and removed when ready to deploy the product. The user would typically not want to leave measurement code in production code to avoid introducing measurement artifacts.
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.
...
It should also be easy to measure the execution time of a post call by using OS_TS_GET().
In the Direct Post Method, the 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.