Hi Neil
I agree I don't think my trouble is too many interrupts.
If I implied that it was not intentional.


What I plan to do in both ISRS is what I do in the first.
I look for start and stop characters so I know a command or packet has been
received.
If I receive a terminating char I push a command to the main loop to tell it
to parse the message buffer.

(In the first ISR if the character is outside the accepted set of the
character or it grows too long I just drop the whole mess and start over but
there really is not that much too it.)

I've stripped everything out of the second ISR but even when I put it high
by itself it causes problems.

Also note the over run error has to be cleared or I will only get two
interrupts and then they just stop even if I send the characters with a
keyboard at a slow rate.

What is the big deal about an over run error?



In the second ISR handle_gps_chars this is the code

void handle_chars_gps(void)
{

 if (RCSTA2bits.OERR) 
 {   
  RCSTA2bits.CREN = 0;    //disable then enable the receiver to clear the
over run error
  RCSTA2bits.CREN = 1;        //if I don't do this I only get two interrupts
and then they just stop
  return;
  }                       
   char_holder = getc2USART();                      //this causes problems
even with out pushing the the character to the NMEA buffer 
 

// push_NMEA_char(RCREG2);                                //this is how i
would normally do things this way to save the function call over head of
getc2USART()
} 

 This ISR works fine at a low priority but makes everything go haywire at a
high prioroty.

 My other ISR has worked fine for months and it is happy to work either high
or low.
Why does this one care about the over run error when the well behaved one
does not care about an over run error?
How can this code operate fine at a low priority but screw everything up at
a high one???
 
 
Phillip
Things should be as simple as possible but no simpler
 
 
 
Phillip Coiner
CTO, GPS Source, Inc.
 
 
Your source for quality GNSS Networking Solutions and Design Services, Now!
-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of
Neil Baylis
Sent: Monday, September 18, 2006 10:16 PM
To: Microcontroller discussion list - Public.
Subject: Re: RE: FW: [PIC] Trouble getting my ISR high

Phillip,

your interrupt rate is actually pretty low. You only have to handle
one byte from the GPS, and/or one keystroke, per interrupt. That's a
tiny amount of ISR code. Your problem is not because of too many
interrupts.

(I'm assuming here that you're not attempting to decode the entire
NEMA message in one interrupt. Do that in the background, or use a
state machine in the interrupt.)

It should definitely work with both of them as high priority
interrupts. I use pic18f in this mode frequently, and it works fine.

One problem: the PIC interrupt doesn't save FSR registers. If your ISR
code uses them, then you could be in for trouble. But I would imagine
that the C library should deal with that. I don't know, because I do
mine in assembler.

Neil



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

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