Using Interrupt ... Where ? When ? Pro & Con ?

[nctnico]

IMHO the most important thing when using interrupts is that their maximum occurance frequency has to be predictable. From there you can calculate maximum response times and the maximum stack usage.

[KL27x]

Sigh. If you snip and combine partial quotes then you can "prove" anything

I quoted you, because I was responding to those statements. You're the one that said these things. I quoted, and provided context. It's all in the thread, if you forgot.
 

- but nobody is impressed with strawman arguments. Especially when you zoom off in directions more-or-less unrelated to the quotes.

That's the kettle calling the pot black. You did not respond to my posts, at all. Well, I take that back. I'm not familiar with Itanic. If that's the chip you base your interrupt overhead on, well I'm not sure that it is representative in general. And I thought I responded very directly to w/e I quoted.

Calculating those maxima is impractical on modern embedded processors - and is steadily becoming more impractical.

Consider an ARM A9 such as is found in phones and Zynq FPGAs, which is dual core, out-of-order, superscalar, dynamic-length pipeline (8-12 stages), L1 and L2 caches, shared memory. Add in that one core is probably running a linux and the other may be running an RTOS, and I challenge you to calculate (not measure) the maximum stack depth and interrupt latency time!

Or you can look at Intel's embedded x86 processors, and you will find the similar problems.

Of course if the discussion is limited to a subset of embedded systems without those features, then it is easier to calculate the maxima.

Isn't this one of those strawman arguments you were speaking of? No one here ever tried to do such a thing. The post started out discussing AVR's, as well. I don't see any mention of this in your explanations. Do they fit with your overall argument? Or are they, indeed, different?

I think TerminalJack has an insightful observation:


Quote

My opinion regarding the use of interrupts is that you can/will make more complex use of them on less complex systems (=lower-end hardware.)  The complexity will be easier to manage on a smaller system.  You also won't likely have an RTOS to leverage.

I quoted Terminal Jack, here, even. Thoughts? Maybe you agree with him? You are undoubtedly knowledgeable. I know this because you posted your resume. Is anyone else on the right track?

[nctnico]

IMHO the most important thing when using interrupts is that their maximum occurance frequency has to be predictable. From there you can calculate maximum response times and the maximum stack usage.

Calculating those maxima is impractical on modern embedded processors - and is steadily becoming more impractical.

Consider an ARM A9 such as is found in phones and Zynq FPGAs, which is dual core, out-of-order, superscalar, dynamic-length pipeline (8-12 stages), L1 and L2 caches, shared memory. Add in that one core is probably running a linux and the other may be running an RTOS, and I challenge you to calculate (not measure) the maximum stack depth and interrupt latency time!

Latency is not worst case response time. Worst case response time is the worst case scenario where other interrupts are handled first. In a good ISR the latency is dwarfed by the amount of code which needs to be executed anyway. For a proof a system keeps working you are after the worst case scenario so assume all caches and pipelines are empty and need to be filled first. Stack depth is easy as well: use a seperate stack for interrupts.

[KL27x]

Continually pushing an argument towards the way an RTOS, which is built to handle interrupts in a pre-specified way, or on Itanium and x86 microprocessors primarily used with an OS is... what it is.

An RTOS is another additional layer that is already built to handle interrupts in a certain, limited way. Of course the use of interrupts will be more limited. And being built to handle parallel tasks to begin with, of course using the RTOS tools to handle events is more appealing.

If you are have direct control over interrupt handling on your device, interrupts can be very broadly useful. You could implement interrupts for a specific application/task, rather than set up a handling algorhithm that works for a general purpose OS. TerminalJack pretty much covered it, and yet the hand keeps trying to talk to the face.

Of course if the discussion is limited to a subset of embedded systems...

is necessary context to make some of the posts on this thread sensible. Mostly yours.

OP: can we keep this limited to 8 bit microcontrollers through single core ARM, for instance?
- Well, sure, you don't need interrupts if you use a 32 core XMOS processor. And if you need to use interrupts you chose insufficient hardware.

The truth is that you're comparing XMOS architecture to a typical RTOS. (Even among RTOS's, there are different ways of managing multithreading and interrupts.) XMOS architecture and extended language can result in a shorter and more predictable latency than a given RTOS running on a single or multi core processor. This is because an RTOS on a multicore processor is doing the same thing, only it's fixed in one method of doing so. The XMOS extended language gives users the access to spinlock/loop and handle interrupts as they see fit for a given task/s. So the interrupt latency can be shorter and more predictable in this case because you're not fixed to a specific RTOS, which may be written with different priorities. Even (especially) with a single core, use of interrupts can be done with extremely short latency and high predictability... depending on the application and/or use (or non-use) of an OS. I imagine that in many specific applications, a single core micro using interrupts can be faster and more predictable even than an XMOS, given the same processor speed. If your app doesn't make good use of multiple cores, maybe you are choosing overadequate hardware. Is XMOS superior at multithreading than any given RTOS? More flexible, it sure seems. But some apps don't benefit from multithreading. For some hardware applications, interrupts are ideal.

I'll put it this way. For certain applications, using a certain, adequate single-core device, one MIGHT be able to accomplish said task satisfactorily using code loop polling. And to achieve this, you MIGHT need to be a genius or a masochist. Whereas if you cannot do said task better (lower and more predictable latency) with an interrupt, you would have to be a moron.