I've written some PIC programs...got them working...and am generally feeling
very good! Now I'm starting to get into the real project that I have before
me. This requires interrupt driven I/O with multiple types of I/O and
interrupts going on simultaneously (I/O, USART, A/D, timers, etc.). I'm
very confused about one thing with regard to interrupts and I hope someone
can point me in the right direction...
When I'm servicing an interrupt at 0x04, what happens if/when another
interrupt occurs? I know that interrupts are disabled so I won't get
re-vectored back to 0x04, but will I lose that interrupt? The datasheets
show that some peripherals (like the A/D) clear their ADCON0:GO bit when
they complete, even if interrupts are disabled. So does this mean I need to
be checking those bits right before I re-enable interrupts? Or...as soon as
I re-enable interrupts via RETFIE will I get immediately vectored back to
0x04 to pick up the interrupts that occurred while interrupts were disabled?
On a related subject...are there things that I definitely should never do
inside an interrupt service routine?
Thanks for help or pointers to where I can find this out for myself...
In the application I'm writing for an F84, I'm using all the interrupts
(timer, RB0, RB5-7 change, and EEPROM write complete).
What I did for my ISR was decide on the priority of the interrupts, and
check the flags in that order, calling the functions to handle the
interrupts if te interrupt flags wetre set. At the end of the ISR, before
restring context and calling 'retfie', I check that all interrupt flags are
still clear. If any flag has become set again due to another interrupt, I
just 'goto ISR' and start again.
This seems to work fine for me. It guarantees interrupts are processed
according to the priority you assign and avoids any unnecessary interupt
latency by staying in the ISR as long as possible, rather than letting it be
called many times in a row.
I think you should take a look at AN585 "A Real-Time Operating system
for PIC16/17". There are a lot of very useful theory and practice
there.
JS> I've written some PIC programs...got them working...and am generally feeling
JS> very good! Now I'm starting to get into the real project that I have before
JS> me. This requires interrupt driven I/O with multiple types of I/O and
JS> interrupts going on simultaneously (I/O, USART, A/D, timers, etc.). I'm
JS> very confused about one thing with regard to interrupts and I hope someone
JS> can point me in the right direction...
JS> ............
--
Best regards,
Oleg spam_OUTremove_this_word.serginTakeThisOuTfcita.dn.ua
>When I'm servicing an interrupt at 0x04, what happens if/when another
>interrupt occurs? I know that interrupts are disabled so I won't get
>re-vectored back to 0x04, but will I lose that interrupt? The datasheets
One of the peripheral interrupt flags will be set and remain set until you
do something that clears it. Look at the documentation for the specific I/O
module you are using to see if reading a register automatically clears the
interrupt flag or if you have to explicitly clear it (BCF).
>show that some peripherals (like the A/D) clear their ADCON0:GO bit when
>they complete, even if interrupts are disabled. So does this mean I need
to
>be checking those bits right before I re-enable interrupts? Or...as soon
as
>I re-enable interrupts via RETFIE will I get immediately vectored back to
>0x04 to pick up the interrupts that occurred while interrupts were
disabled?
The latter is true. Just do a RETFIE.
>On a related subject...are there things that I definitely should never do
>inside an interrupt service routine?
Don't change any registers that are being used by the foreground process.
If you must use FSR for instance, then save it to a location dedicated for
this purpose and restore it prior to executing a RETFIE. I assume you
alredy have (or can easily find in any Microchip databook) the code to save
and restore the W register and the STATUS register.
You should also think of external peripherals like registers .. don't leave
them in a state that differs from the state they were in prior to the
interrupt unless your interrupt service routine is the only thing that uses
them (or the foreground process won't be affected if the state of the
peripheral randomly changes .. not usually the case).
fcita.dn.ua
