Re: Why ISR contains no arguments and return type is void

From: Active8 (reply2group_at_ndbbm.net)
Date: 08/24/04 

Date: Tue, 24 Aug 2004 12:13:01 -0400

On Tue, 24 Aug 2004 20:13:50 +1000, Roger Lascelles wrote:

> An ISR is called when a hardware event occurs and is not called by code, so
> parameters cannot be passed to it. In addition, when you write an ISR, you
> know what conditions caused the interrupt,

Not always, you may have to check flags while in the ISR to
determine the event.

> and therefore know what to do
> about it, without needing parameters to give additional information.
>
> An ISR returns nothing, because there is no calling code to read the
> returned values - on return, program execution returns to the original
> instruction stream.
>
> Roger
>
This is not entirely true, but the OP hasn't even bothered to
mention what friggin' uP he's using. In ix86 ass'y, there are BIOS
Ints. You place a value like which sector to read in the ax or eax
register, IIRC, and the return value (success/failure) is returned
there. Check Ralph Brown's INT list. FYI, I wrote a boot sector
program to load the boot code into that special location (55aa or
aa55). It took 3 attempts to read the sector. I initially programmed
a infinite loop to read the sector until success and NAV's
Bloodhound TM scanner promptly let me know I had a memory resident
virus. Pretty cool. Nowdays, NAV sucks. TFB.

Anyway, Let's talk PICs for sake of argument. You *can* put a value
in a register before returning from your ISR. You can also load a
file register(s) with whatever status(es) you need to check in the
ISR before the ISR is called but you might encounter race conditions
- Google "the dining philosophers". You can also call the ISR from
code and use a retlw instead of using retfie. You'd set up a
conditional to check a register to see if the int flag was set by a
hdw int, or if you set it yourself - check whether you *can* set
that flag yourself first. Again, a race condition will foul up your
day, so always consider what might happen if while in the process of
calling that int code, a real int occurs. If you can set the int
flag before doing anything else, that instruction will finish
executing and lock out pending ints.

Maybe you don't care if an int executes while the program is
processing your call. Just remember you have to save any registers
you're using (first order of biz in an ISR) that might get wiped out
when the real int occurs.

Another thing you can do is post your questions to piclist.org,
avrfreaks, or an appropriate programming group instead of here.

HTH 

-- 
Best Regards,
Mike

Relevant Pages

  • Memory allocation modifications in ibm_newemac driver
    ... The problem is this - when I enable a large MTU and run data through the EMAC and also am reading and writing data to a disk, memory becomes so fragmented that allocating a new SKB fails. ... static int emac_reset ... goto bail; ... if (isr & EMAC4_ISR_TXPE) ...
    (Linux-Kernel)
  • Re: Why ISR contains no arguments and return type is void
    ... If an interrupt can be caused by 3 causes, A, B, or C then the condition ... In addition, when you write an ISR, ... Check Ralph Brown's INT list. ... > in a register before returning from your ISR. ...
    (sci.electronics.design)
  • Re: Why ISR contains no arguments and return type is void
    ... In addition, when you write an ISR, you ... 99.97% of the 8086's) of a software "interrupt" or break ... Check Ralph Brown's INT list. ... >in a register before returning from your ISR. ...
    (sci.electronics.design)
  • Re: Making a function safe for use in an ISR
    ... This function can not be a stand-alone ISR (with register save ... If this is supposed to be standard C, then int can not be 8 bits. ... Floating point instructions should be avoided even if the instruction ... the FPU stack is used as MMX data registers ...
    (comp.arch.embedded)
  • Re: Making a function safe for use in an ISR
    ... int iterative_factorial{ ... function unsafe to use in an ISR? ... Look at code-generation strategies for compilers on 'baby ... be reentrant on a 'big' CPU but (unless the compiler-writers have been ...
    (comp.arch.embedded)