On 3/14/07, Matt Bauman <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I recently started playing around with SDCC to program PIC16
> devices. I'm moving from a compiler that implemented interrupts in
> software (by appending an if...then after every line of code!), so
> hardware interrupts are new and marvelous enigmas to me. Forgive my
> ignorance! :)
>
> I have a few general questions about their behavior in several
> situations:
>
> 1. Firstly, how do the interrupt flags work? Do they immediately
> and always cause a vector to the ISR as long as they are set? If I
> were to not reset the interrupt flag after servicing a routine, would
> it infinitely loop that routine?
It will infinitely loop.
> 2. Do interrupts of the same priority level interrupt each other, or
> do they wait for the other to finish?
Look at the datasheet. There are only two interrupts, one at each
level. Inside the interrupt, you have to check the flags to see which
interrupt source caused the interrupt. Does that make sense? It's
easy once you "get it."
So the code ends up looking like this:
void isr_high interrupt 1 {
if (PIR2bits.TMR3IF) {
// deal with TMR3 expiring
PIR2bits.TMR3IF=0;
}
if (INTCONbits.TMR0IF) {
// deal with TMR0 expiring
INTCONbits.TMR0IF=0;
}
}
Notice that I am using two timers, but the ISR has to check flags to
know which one timed out. What if TMR3 times out while in the ISR?
Once interrupts are re-enabled at the end of the ISR, it will
immediately jump to the beginning again.
>
> 3. I think I understand this one, but correct me if I'm wrong.
> There's a warning in the documentation about non-atomic math and
> assignment functions with respect to 16 bit variables. It only
> matters if those 16 bit variables are used in the ISR, correct? The
> chip will still accurately finish 16 bit operations when the ISR
> returns; the problem is just the intermediate state, right?
Right.
>
> 4. If I keep my ISRs relatively short (specifically -- so they
> execute faster than the time it takes to send one byte through
> USART), do I need to worry about interrupting my printf()s to the
> STREAM_USART?
Even if the ISR takes a long time, nothing bad happens. There will
just be some little delay between two characters from the USART.
RS-232 is fine with this. It would be a problem if you were using a
software, bit-banged UART for obvious reasons.
Good luck with interrupts! They're simple once you catch on.
Regards,
Mark
[EMAIL PROTECTED]
--
Most of the time,
for most of the world,
no matter how hard people work at it,
nothing of any significance happens.
-- Weinberg's Law
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
