Difference between ISR and Function Call?
I want to understand difference between ISR (Interrupt Service Routine) and Function call.
I feel both the function call and ISR are the same from the hardware perspective. Please Correct me if I am wrong. All I could found about ISR and Function call is as follows:
ISR:
Asynchronous event that can occur any time during the execution of the program
Saves the PC, Flags and registers on the stack and disables all the interrupts and loads the address of the ISR
ISR cannot have arguments that can be passed to it
- Cannot return values
- Enables the interrupts
- Generally small as they are taking the time of some other process
- Some of ISR have have their own stack
Function:
Occurs when ever there is a function call
Saves the PC and registers on the stack
Can have arguments
Can return values
No restriction on the size and duration of execution
Is there any more difference other than this ? Please let me know. I have also read about having a function call from ISR how does that take place. Please highlight on it.
Answer
So having asserted that they are the same, you go on to list the ways in which they are different - which perhaps rather answers your question.
Your first four points about ISRs are broadly and generally true. The points about enabling interrupts is not necessarily the case and is an implementation decision by the programmer, and may be determined by the architecture, and being small is a guideline not a requirement - and "small" is entirely subjective".
The differences are not so much in respect of how they are coded (though ISR's typically impose a number of restrictions and may also have privileges that normal functions do not), but rather in how they are invoked and the behaviour of the processor.
A function (or procedure or sub-routine more generally) must be explicitly called and is part of the same context and thread of execution as its caller. A hardware ISR is not explicitly called but rather invoked by some external event (external to the processor core that is - on-chip peripherals may generate interrupts). When an interrupt is called the context of the current thread is automatically preserved before switching context to the ISR. On return, the reverse context switch occurs restoring the state of the processor before the interrupt so that execution continues from the point of interruption.
The mechanism can be complicated by the presence of a multi-threaded operating system or scheduler whereby the ISR itself may cause a thread-context switch so that on return from an ISR a different thread of execution or context is switched in. Such mechanisms are managed by the operating system in this case.
There is another kind of ISR supported on some processors - that of a software interrupt. A software interrupt is used like a function call in the sense that it is explicitly invoked by an instruction rather than a single event, but offers an indirection mechanism whereby the caller does not need to know the address of the ISR and indeed that address may change. In that sense it is little different than calling a function through a pointer, but because it is an ISR it runs in the interrupt context, not the caller's context, so may have restrictions and privileges that a normal function does not.
Fundamentally an interrupt is able to respond directly and deterministically to events where otherwise you might poll or test for an event then handle it, but could only handle it at the time you choose to test for it rather than on its actual occurrence, which may be variable and unacceptably long.