'Inttrupt routine & another inttrupt?'
Just a question: What happens if your program is doing the inttrupt service
routine and another Intflag getting set? Is the inttrupt directly detected
by the PIC after the retfie instuction?
ICQ : 918640 (I Seek You)
HAM : PE1RUH
S-Mail: Eerste Vijverstraat 6
5258 HR Berlicum, The Netherlands
Phone : +31-73-503-4733
|On Wed, 21 Oct 1998 17:34:22 +0200 Radboud Verberne <hsbos.nl> r.verberne
>Just a question: What happens if your program is doing the inttrupt
>service routine and another Intflag getting set? Is the inttrupt
>detected by the PIC after the retfie instuction?
Yes... unless your "main ISR" has not yet dealt with that
interrupt. My typical interrupt handler has a bunch of btfsz
instructions polling the appropriate interrupt flag bits followed by
calls of the handler for that device. The end of the routine has the
You COULD enable interrupts in the ISR and allow interrupts to
interrupt interrupts, but the limited stack depth in the PIC is sure to
cause problems. There are also reentrancy problems in the ISR code.
I'm sure that my code often gets an interrupt set after the ISR
has already polled that device, causing an immediate interrupt after the
retfie. This could be avoided by having the ISR loop 'til none of the
interrupt flags are set, possibly speeding interrupt response time since
you'd only have to save and restore context once. I haven't had to
resort to this (yet), though.
Hallikainen & Friends, Inc.
See the FCC Rules at http://hallikainen.com/FccRules and comments filed
in LPFM proceeding at http://hallikainen.com/lpfm
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
or call Juno at (800) 654-JUNO [654-5866]
part 0 3085 bytes
I've done this on some occasions; the PIC's interrupt hardware is
extremely simple, so there's no complex "faking" as can sometimes
be needed on, e.g., an 8x51.
Basically you need to consider that nesting ISR's means two things:
(1) The stack depth of the nesting ISR is in addition to that of the
(2) Anything the nesting ISR does to registers may bash the underlying
ISR; either the nesting ISR has to avoid any instructions that may
affect flags or W, or else you need seperate file registers to
save W and F for the two interrupts.
Generally, then, the only time that it makes sense to have ISR's nest
is if there's a very simple routine that is allowed to execute during
a longer and more complicated one. For example, suppose you have a
routine which you would like to execute precisely once every 5000
clock cycles, and which may take over 1000 cycles to execute. Since
the RTCC's prescalar won't allow timing durations of that sort, and
since writing to the RTCC clears the prescalar (BOO HISS!) the only
option is to use a 1:1 prescalar and deal with the interrupt every
256 cycles (once every 20 interrupts we perform the "real" ISR and
jog the RTCC a bit).
movlw 123 ; Jog count by 120; add 3 to dea
; with PIC's synchronizing delay
... real meat of ISR goes here
Note that interrupts may be safely nested at any point after the
third instruction; unless twenty interrupts occur before the main
ISR is done the nested interrupts won't disrupt anything.
By the way, when doing nested interrupt stuff like this, it's often
useful to use INCFSZ/DECFSZ in situations where the skip-on-zero is
not needed (provided it won't cause trouble), since unlike INCF/DECF,
they don't set flags. Also, using BSF and BCF instructions on the
RTCC may be somewhat handy. For example, if it's desired to have the
ISR execute every 135 cycles this may be accomplished by
bsf RTCC,7 ; Skips ahead 128 counts, but drops 3
decfsz RTCC,f ; Drops back a count, plus 3 more
While not nearly as clear as:
the approach with "bsf" and "decfsz" has the decided advantage that
it does not affect any flags or W.
In short, nesting ISR's is fine provided that the nested ISR's tread
very lightly. It takes a bit of getting used to, but allows for some
Dr. Imre Bartfai
Yeah. That's why one can enter into an endless loop when forgetting to
reset the appropriate IF.
On Wed, 21 Oct 1998, Radboud Verberne wrote:
More... (looser matching)
- Last day of these posts
- In 1998
, 1999 only
- New search...