This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

function and isr

what is the difference between jump to a function and jump to the isr? what are the steps involved?
(discuss regarding return also)

  • "what is the difference between jump to a function and jump to the isr? what are the steps involved?"

    There is only one step. If you jump, you jump -- one step. No more. No less.

  • If you jump, you jump

    Erik would probably say: "if you run - you run. But if you crawl - you crawl !"

    :-)

  • what is the difference between jump to a function and jump to the isr? what are the steps involved?

    Is this a question asked in a class at school? If so, I would question their teaching methods. Rather than discussing 'functions' and 'ISRs' in general, I think it would be much more beneficial to learn about a certain architecture (CPU/language/OS/...) and how it all works within the architecture. There would not be a need for such questions then. After all, engineers deal with certain architectures in their work, they don't speculate about 'functions' and 'ISRs' in general.
    This reminds me how at my first electronics lesson I was confronted with a sofisticated model of a bipolar transistor valid from 0 Hz to 1 GHz. Now I realize that you should start thinking about a transistor as a simple switching device, later extending the model to cover other use cases. Incompetent teachers...

  • "Incompetent teachers..."

    When I was at college, I was told that a function should have no more than three lines of code.

  • "Rather than discussing 'functions' and 'ISRs' in general, I think it would be much more beneficial to learn about a certain architecture"

    I disagree!

    The concept of the "function" call & return is pretty fundamental whatever architecture you use, and whatever language. It is also important to understand the difference from an "unstructured" jump.

    Similarly for interrupts - and you need to understand the concept of the interrupt in order to know the place of an interrupt handler (or "service routine")

    It is important to undersand the concepts before moving on to the implementation in any particular language and/or architecture.

    That's my opinion, anyhow...

  • The concept of the "function" call & return is pretty fundamental whatever architecture you use, and whatever language. It is also important to understand the difference from an "unstructured" jump.

    I am not suggesting to scrap the teaching of concepts. I'm just trying to say that once you intruduce a concept, you should show how it works within a certain architecture. This will show the students the practical significance of the concept and help keep them interested.

  • ...jump to a function and jump to the isr...

    Your question is so open-ended that it sounds like a school question. Nonetheless, here is some information that addresses some of your questions and differentiates functions and ISRs.

    • A function is called by a program in response to flow control.
    • An ISR is called when its associated interrupt is triggered.
    • An ISR may call a function.
    • A function "probably" doesn't call an ISR. But, a function could trigger an ISR.
    • Some interrupts can be masked or disabled which prevents their ISR from getting invoked.
    • Some interrupts cannot be masked and are given a special name of NMI. But, on the PC, even the NMI can be masked.
    • In some architectures, a function may be triggered by an SWI and a function may trigger an SWI. This means that the SWI acts more like a function call and does not really invoke an ISR in the traditional sense. However, it is probably acceptable to interchange the terminology in this case.
    • Functions and ISRs both usually return unless they include a bug or, possibly intentional, endless loop that prevents such. However, in the latter case this could be used to trigger a watchdog interrupt and its associated ISR.
    • ISRs generally don't have a return value.
    • Functions may or may not have a return value depending on their definition.

    Jon