RTOS/TM4C129ENCPDT: TM4C129ENCPDT Interrupt latency

Greetings Todd,

Always enjoy reading your helpful guidance to those here.

May I expand this thread (slightly) by asking if the use of an RTOS causes any degradation in performance to, "Interrupt Entry Latency" (which I believe to be 12 cycles - for Cortex M3/M4) and to "Interrupt Exit Latency?" (believed to be 10 cycles - same devices)

One last question - does an RTOS impede or degrade - in any manner - the ability to support "interrupt pre-emption."    (the ability of those interrupts - promoted to "pre-emptive status" - to interrupt the processing of another (in process) yet lower priority interrupt.)

It would appear that these questions land w/in the theme of this thread - perhaps (even) providing slight enrichment... Thanks much - your time & attention - your efforts here are much appreciated...

cb1_mobile said:

May I expand this thread (slightly) by asking if the use of an RTOS causes any degradation in performance to, "Interrupt Entry Latency" (which I believe to be 12 cycles - for Cortex M3/M4) and to "Interrupt Exit Latency?" (believed to be 10 cycles - same devices)

This would often be the case, but whether it does so compared to an application depends on the application. It is necessarily true that an RTOS must turn off all interrupts that can access the RTOS primitives during scheduling. This necessarily adds variation to the latency (increasing the maximum latency). It does not necessarily affect the minimum latency but that depends on RTOS design.

However applications may need to perform similar blocks of interrupts for synchronization so the question of whether you get a net worse response using an RTOS may not have an easily deterministic answer.

Indeed it's quite possible for an application written using support from a good RTOS to have better latency than one written with no RTOS simply because of the support for separate processes and IPC abstraction. Even better for some applications, might be an event driven RTOS.

cb1_mobile said:

One last question - does an RTOS impede or degrade - in any manner - the ability to support "interrupt pre-emption.  

That would depend entirely on the RTOS. There are quite different schemes used by different RTOS for interrupts and the scheme and the implementation details will make a difference.

Robert

Thank you Robert - much appreciated.

It is noted - SO often here - that "RTOS is chosen" - but rarely (i.e. almost never) is RTOS performance compared/contrasted w/that of Non-RTOS.

Such seems (highly) curious - and it proves (extremely) rare for any "add-on technique" (such as RTOS) to "always & only" produce benefit - w/out extracting (balancing), "trade-offs!"

Blind acceptance - minus "all the facts" (as you note - sometimes "difficult to tease out") cannot always prove optimal - especially when "one horned" lurks (so) nearby...

Thank you, Todd - appreciated.

If I understand your writing (re: Hwi dispatcher, additional context, "arg" parameters etc.) there "must" be some execution penalties (be they time or added program complexity) which attach to the use of such "RTOS."

Note too (skilled) poster Robert's comments - noting the "likelihood" of an RTOS - under certain conditions - causing reduced MCU performance.

My point - it proves (extremely) RARE - for any "add-on" technique - to provide ONLY Benefits - w/out extracting (some) costs!    And those costs - appear to be SO often - little questioned/examined by (many/most) here...

ToddMullanix said:

Having said that, TI-RTOS supports "zero-latency" interrupts.

If ever there was a mis-named feature it is this. Managed and unmanaged interrupts is a far better descriptor.

ToddMullanix said:

The caveat is that the interrupt cannot make a call into the kernel that might impact scheduling. It can post another interrupt that is RTOS managed that can make kernel calls (e.g. Semaphore_post).

This can be useful, and it's also doable in systems that do not explicitly support unmanaged interrupts. On an RTOS system that supports only a subset of kernel calls for managed interrupts this approach effectively converts a two level interrupt response into a three level response.

ToddMullanix said:

TI-RTOS does nothing to impede or degrade the interrupt pre-emption on the TM4C device.

This I do not believe. In fact you contradict it earlier when referring to the difference between managed and unmanaged ('zero-latency') interrupts.  The fact that only priority zero interrupts are not disabled implies the others are. That only priority zero interrupts are not disabled is a degradation. How serious that is depends upon the application needs.

Robert

cb1_mobile said:

My point - it proves (extremely) RARE - for any "add-on" technique - to provide ONLY Benefits - w/out extracting (some) costs!    And those costs - appear to be SO often - little questioned/examined by (many/most) here...

Mind you that cost, in increased latency and execution time, is usually paid back by decreasing the costs the application would normally introduce managing the same needs itself. You are correct though, that if those costs are important they need to be considered. And determining how important they are is an early question to answer as well.

Robert

Robert Adsett said:

If ever there was a mis-named feature it is this. Managed and unmanaged interrupts is a far better descriptor.

Yep. We are trying to move the documentation to use managed and un-managed, but the wheels of documentation are slow sometimes. 

Robert Adsett said:

This I do not believe. In fact you contradict it earlier when referring to the difference between managed and unmanaged ('zero-latency') interrupts.  The fact that only priority zero interrupts are not disabled implies the others are. That only priority zero interrupts are not disabled is a degradation. How serious that is depends upon the application needs.

I meant that the RTOS does to change the behavior of the interrupt priority or preemption behavior in general. The exception being when the managed interrupts are disabled for internal house-keeping reasons (e.g. updating an internal linked list) and that maximum duration is documented in the benchmarks (and is where this thread started). Sorry, I that was implied, but reading back over it, I agree I should have added that.

Todd

ToddMullanix said:

Yep. We are trying to move the documentation to use managed and un-managed

That's good news. The first time I encountered your current term we spent considerable amount of time trying to determine just what the poster was talking about. They seemed to be talking about something that wasn't possible.

ToddMullanix said:

I meant that the RTOS does to change the behavior of the interrupt priority or preemption behavior in general. The exception being when the managed interrupts are disabled for internal house-keeping reasons (e.g. updating an internal linked list) and that maximum duration is documented in the benchmarks (and is where this thread started).

I figured but the uninitiated might not grasp it so I thought it should not just sit there w/o complaint. You not only do have introduced latency but it's non-deterministic latency.

In most cases it's either not going to matter or there will be an improvement because the application is so much better structured and avoid ad-hoc solutions.

There have been a few people playing around with the idea of using an event driven structure rather than an RTOS for better performance in embedded systems. I'm not sure yet that it's a general solution but I suspect it would improve a lot of applications.

Robert