Hi,
I have never seen nor came across the situation where need to pass parameter in interrupt service route or ISR that return any type.

I'm wondering if it's possible to pass parameters in an Interrupt Service Routine (ISR) or if we can have an ISR that returns any type ?

 

Hi,
I have never seen nor came across the situation where need to pass parameter in interrupt service route or ISR that return any type.

I'm wondering if it's possible to pass parameters in an Interrupt Service Routine (ISR) or if we can have an ISR that returns any type ?

ISR's cannot "pass parameters" in the usual "C" programming kinda way, but they can (must) interact with memory locations and peripheral registers.

Declare a variable 'volatile' if its molested inside an ISR.

Don't let ISRs read multi-byte variables asynchronously, imagine the mainline code is in the middle of doing a multi-byte multiply and the ISR fires and tries to read the resulting number - garbage happens.

 

Tell us how you think one could pass a parameter to an ISR or how its return value might be used?

Let’s restrict this to the case of an external hardware interrupt. What might it pass or what might a returned value mean?

 

Tell us how you think one could pass a parameter to an ISR or how its return value might be used?

I don't know if this is useful or not, but an ISR is like a function in C language, right? And in C, we pass arguments to functions or get values back. So, I was wondering if it's possible to do the same with ISRs. Can it be done, or is it just not that useful in embedded system?

 

There is no available mechanism for doing that. The alternative is to have memory locations with some rules about who can do what to those locations and when.

 

An ISR is not like any function in C language.
A function can pass arguments in the argument list or as a returned value.

Who or what is going to fill the arguments in the input list?
Who or what is going to receive the arguments in the output list or the return value?
There is no viable mechanism for doing either or both of the above. An ISR is invoked asynchronously. It can be triggered at any time or place in the program process.

 

I suppose hardware could be designed to pass a parameter indicating what caused the interrupt. This is usually done by reading known hardware registers and by the fact that the different interrupts are vectored to different handlers. I see no compelling reason to change that. Any additional work done by the processor would likely increase latency, which is a bad thing.

 

ISR's cannot "pass parameters" in the usual "C" programming kinda way, but they can (must) interact with memory locations and peripheral registers.

Declare a variable 'volatile' if its molested inside an ISR.

Don't let ISRs read multi-byte variables asynchronously, imagine the mainline code is in the middle of doing a multi-byte multiply and the ISR fires and tries to read the resulting number - garbage happens.

You can manipulate multi-byte variables asynchronously if the actions are atomic in the non-interrupt context. You cant do this with interrupt masking or using atomic multi-byte hardware registers like 16-bit timer value latches.