1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Why ISR contains no arguments and return type is void

Discussion in 'Embedded' started by sudheervemana, Aug 24, 2004.

  1. HI all,

    Can any one clear me why cant we pass the arguments to an
    ISR and also why the ISR returns nothing.

    With Regards,
    Sudheervemana.
     
    sudheervemana, Aug 24, 2004
    #1
    1. Advertisements

  2. Because "we" don't call the ISR --- the CPU does that by itself, and
    it has no arguments in hand to pass in, nor would it know what to with
    a result value, if there were one.
     
    Hans-Bernhard Broeker, Aug 24, 2004
    #2
    1. Advertisements

  3. sudheervemana

    Al Borowski Guest

    I'm curious. What arguments would you want to pass to an ISR? And where
    would the returned thing go?

    Keep in mind that generally (except on some CPUs, where 'software
    triggered' interrupts are used for OS calls) you have no control exactly
    when an interrupt would occur. It doesn't make sense to pass it things,
    or have things returned.

    Al
     
    Al Borowski, Aug 24, 2004
    #3
  4. sudheervemana

    Mark Haase Guest

    The ISR gets called by the CPU in the middle of the running code. The
    CPU pushes all of the current program's execution information (eg.
    program counter, stack pointer and others) and then runs the ISR. So
    there really is no calling code for the ISR...thus nobody to pass
    arguments or fetch results.

    Technically I suppose a CPU could pass an argument to an ISR, but I
    don't know if it would be meaningful at all.

    Why did you want to? Or are you just curious?

    If you want to return information from an ISR to your main program, you
    can set global flags in the ISR. Just make sure nobody else is modifying
    the global flags when the ISR gets called. You might get an inconsistent
    state.
     
    Mark Haase, Aug 24, 2004
    #4
  5. sudheervemana

    tim Guest

    This is not true of all processors. With some, the parameter
    passed (by the CPU) is the Interrupt number which you can
    then use inside the ISR.

    tim
     
    tim, Aug 24, 2004
    #5
  6. I'm not the OP, but the interrupt number/index/vector/whatever
    might be handy. That way you could hook the same ISR to
    multiple interrupts and have it behave slightly differently
    based on which interrupt caused it.

    For example, you've got 4 UARTs and the receive processing for
    all of the is identical (except for which UART you access and
    which buffer you put data into). Hooking one ISR to all four
    and then using the "parameter" to determine which
    UART/buffer-pair to service would be elegent.
     
    Grant Edwards, Aug 24, 2004
    #6
  7. I honestly don't see the big gain between that and 4 micro-ISRs
    that each do essentially just

    ACC := {this interrupt's number}
    jump to commonISR
     
    Hans-Bernhard Broeker, Aug 24, 2004
    #7
  8. sudheervemana

    Bruce Guest

    Can any one clear me why cant we pass the arguments to an
    The ISR can't return a value because technically there is no "caller" to the
    ISR, so it's declared as type void.

    For this same reason no arguments can be passed to the ISR since there is
    no caller, no telling where program flow is at the time of the interrupt, etc,,.


    -Bruce
    http://www.rentron.com
     
    Bruce, Aug 24, 2004
    #8
  9. Not a big gain, but sometimes a few instructions matter.
     
    Grant Edwards, Aug 24, 2004
    #9
  10. If they do, then nice style will have to yield to efficiency. On a
    CPU with individual ISR vectors, you just have to not use the trick I
    just showed. On a single-ISR platform, you'ld have to start worrying
    about how to squeeze single instructions out of a multi-way branch
    statement.
     
    Hans-Bernhard Broeker, Aug 24, 2004
    #10
  11. You've got a lot of answers already, so you might have grasped the
    concept. In some cases though, when the interrupt handler is called by
    the OS, the former can have arguments and return value. In QNX6 we (tinw)
    use the interrupt handlers that have the following prototype

    const struct sigevent* handler (void* area, int id);

    The handler is called by the OS kernel and returns to the OS kernel. It
    does not (and should not) deal with interrupt controller directly, has
    it's own rather limited stack and can be preempted by a handler of higher
    priority interrupt.

    BTW, in QNX4 the prototype was

    pid_t handler (void);


    HTH,
    Vadim
     
    Vadim Borshchev, Aug 25, 2004
    #11
  12. sudheervemana

    roller Guest


    what about polling the "interrupt" flag (of all the devices connected to
    that interrupt line) which is set when an interrupt gets serviced?
     
    roller, Aug 25, 2004
    #12
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.