Re: Why ISR contains no arguments and return type is void
From: Ben Bradley (ben_nospam_bradley_at_mindspring.com)
Date: 08/24/04
- Next message: Active8: "Re: Engineering Mathematics"
- Previous message: Walter Harley: "Re: electrolytic working voltage"
- In reply to: Active8: "Re: Why ISR contains no arguments and return type is void"
- Next in thread: Keith Williams: "Re: Why ISR contains no arguments and return type is void"
- Reply: Keith Williams: "Re: Why ISR contains no arguments and return type is void"
- Reply: Active8: "Re: Why ISR contains no arguments and return type is void"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 24 Aug 2004 13:24:56 -0400
On Tue, 24 Aug 2004 12:13:01 -0400, Active8 <reply2group@ndbbm.net>
wrote:
>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.
I've always cringed at the idea (in IBM PC's, which are admittedly
99.97% of the 80(x)86's) of a software "interrupt" or break
instruction being called an interrupt. You know when it's going to
happen and what it's going to do, just as you do in a subroutine call.
Perhaps the worst part was that the word "interrupt" became equated
with BIOS or DOS system call, and "real" interrupts such as the
keyboard interrupt and 18.2(odd) ticks-per-second timer interrupt had
to be called "hardware interrupts" to distinguish them from OS calls.
IIRC, the Mac used a similar instruction (one word, basically "go
to vector x in the vector table") named trap in the 68000, and these
OS calls were called 'trap' calls. At least that didn't cause the
confusion over the name interrupt.
>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.
And there's always comp.arch.embedded.
>HTH
-----
http://mindspring.com/~benbradley
- Next message: Active8: "Re: Engineering Mathematics"
- Previous message: Walter Harley: "Re: electrolytic working voltage"
- In reply to: Active8: "Re: Why ISR contains no arguments and return type is void"
- Next in thread: Keith Williams: "Re: Why ISR contains no arguments and return type is void"
- Reply: Keith Williams: "Re: Why ISR contains no arguments and return type is void"
- Reply: Active8: "Re: Why ISR contains no arguments and return type is void"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|