There are two errors detected, "framing" and "overrun".

A framing error can occure anytime, such as something
disturbing the serial line. The framing error is cleared
automaticly whenever there is a correctly "framed"
character. This is an error out of control by your
firmware.

The overrun error is different. It *that* occures, you have
a major application/firmware problem !
In general, overruns should never occur and one can,
by design of the firmware, make sure that they don't.

> So what I got a bad character....who cares?

No, you havn't got "a bad character", your firmware
didn't read the *previous* characters, which is a bit
different. And you have no idea what so ever if you
dropped one, two, three or more characters !

If the framing error flag is set, the *last* received
char could be corrupted.
If the overrun flag is set, on *or more* characters
have been missed and are lost.

So "overrun" is something that should be avoided.

Another thing...

This line "char_holder = getc2USART();" could (if run
in a high prio interrrupt) interrupt the *same* function
in the low prio interrupt, right ? Even if that one uses
getc1USART() i guess, right ?

Maybe those funtions can't be interruptet and the
other one called at the same time (so to speak) ?

I bet there is *someting* that is messing up things
between the two interrupt levels !

Besides of that, I have no commets on your code,
since it's not assembler... :-)

Jan-Erik.
Best Regards,



-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu]On 
Behalf
Of Phillip
Sent: den 19 september 2006 20:40
To: 'Microcontroller discussion list - Public.'
Subject: RE: RE: RE: FW: [PIC] Trouble getting my ISR high




Hi Jan-Erik
I am testing to see if the bit is set.
I don't believe it should be set.
I think this condition is bogus or the hardware is lying......I know 
it
sounds even crazier if I say it out loud.
Even if it is not I don't see why I need to clear the darn thing even 
if it
is set.
So what I got a bad character....who cares?
How does the over run prevent further interrupts from occurring?
Where is it written that if there is an error on a USART that 
interrupts are
now stopped forever?
I thought the whole idea of having those errors was so that you could 
drop a
character without having to process it or maybe as an aide to be able 
to
work out the baud rate on the fly.



void handle_chars_gps(void)
{

  PIR3bits.RC2IF = 0;                     //reading a char is supposed 
to
clear the interrupt flag so I should not need to do this eh?

 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(char_holder);  
} 
 
 Mucho thanks
 
 
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
Jan-Erik Soderholm
Sent: Tuesday, September 19, 2006 12:17 PM
To: piclist@mit.edu
Subject: RE: RE: RE: FW: [PIC] Trouble getting my ISR high

> I'm not that sure that an overrun is really physically occurring (I 
do
> believe the bit is set because clearing it makes things work) but I
> can't think of a way to prove it.

Add a test on the OERR bit ?

Jan-Erik.



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

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



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