Timing for ISR Task Resumption

When executing these APIs, the kernel makes note of the event, and then at next system tick, delivers the event to the destination task. This has the advantage that the kernel does not lengthen the execution time of the interrupt handler (which probably comes from a high priority peripheral interrupt) too much. In fact, it adds less than a dozen lines of C code. However, it means that it could take as much as close to a system tick before the targeted task resumes.

 

We wrote a test to determine the time it takes from the REXIS_MailboxPostFromISR call to when the task receives the mailbox message, with the following results from ten runs of the test, running on a 100MHz STM32F411 MCU:

 

2.73ms

7.09ms

9.66ms

3.11ms

1.96ms

2.78ms

7.80ms

7.54ms

1.13ms

3.82ms

 

It takes an average of 4.762ms, which is exactly what one would expect, as that’s about the halfway point of the 10ms system tick period. If the ISR is passing data to the task using the REXIS_MailboxPostFromISR call, then additional calls will queue up for later processing (of course the code must be written such that each REXIS_MailboxPostFromISR call uses a unique message). If the lag proves to be problematic for the design of a system, it is still possible to improve the time significantly. Contact us if such situation arises.