Phillip wrote :

> Sent: den 28 juni 2006 22:13
> To: 'Microcontroller discussion list - Public.'
> Subject: RE: [PIC] C18 resource remaining metric/test
> 
> 
> Hi Jan-Erick
> Thanks I was writing a response to Olin.
> So I just read your message.
> This of course clears up a lot.
> Once again I apologize for saying one thing when I meant another.
> I certainly appreciate the everyone's help and don't intend 
> to antagonize anyone by wasting their time.

No problem. :-)
When seeing the "clear TMR3IF" with the wrong comment, it was
clear what was the "problem"... :-)

> I used the high level interrupts for the serial ports and the 
> low level interrupts for button presses/ switch de-bouncing.
> My reasoning was that I didn't want to be servicing a 
> switch/button press which compared to a serial character
> is very slow and could be preempted without much effect
> and might make me miss a character if it were at the
> same level of priority as a serial character.
> So in my mind the switches/buttons that have a lower priority 
> should be a serviced with lower priority interrupt.
> (Don't hesitate to correct me if you see a better way to 
> structure things.

OK, let's back a step.

Using the double-prio-interrupt feature is OK if you have
*any* interrupt that in itself takes more time to execute
then the longest acceptable delay for any *other* interrupt.

Now, let's take your case. You have two interrupts enabled,
TMR3-overflow and USART-receive, right ?

A USART-receive interrupt can not come faster then the
baudrate x10 (aprox). I do not remember if you sepecified
the baudrate, but *generaly* speaking, you have quite
a *lot* of instruction cycles between each received character.

E.g, at 9600 baud you have aprox 1 ms between each
USART interrupt. That is up to 10.000 instructions (@40Mhz).
One can do a lot of processing with 10.000 instructions...

Now the kayboard check routine. Does it realy take that many
cycles to check if some PORT-bit is low/high ? I hope you
don't have things like debouncing-delays in the ISR itself !

So the question is, what would hold the processor in the
switch/button routine for that long that a USART interrupt
would be missed ?

Note also that an ISR should normaly be stable in runtime
and have no points where it could be "stuck" for some
unknown time. Usualy, when one have this problem, parts
of the ISR (the parts that would have no problem to be
"interrupted" by another interrupt) could be moved out
of the ISR into the main code.

Regards,
Jan-Erik.



-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist