I have a similar issue with 16F1823, when I enable Rx interrupt, the
interrupt handler dropping characters, even at 2400. I then changed to
using a busy wait, check incoming availability on the main loop, and avoid
the problem, I think it is the case where the sender is sending char at
standard rate and the incoming buffer dropped the char.

The issue can be verified by connect Tx to Rx and sending char through Tx
in the main loop, and using interrupt to get the char from Rx, no
processing, if sender continuous send, it will drops character at 2400.

-- Youda


On Thu, Jul 11, 2013 at 10:29 AM, Joe Wronski <jwronski@stillwatereng.net>w=
rote:

> I think we're missing a fre details, mainly what is the data rate, how
> tight is the loop, and how much processing is done "right away" as the
> data comes in?  If you eliminate the processing, are you still missing
> data?  I'd check that by just putting the data in an appropriate sized
> ring buffer with no other processing, and see if all the data appears in
> the buffer.
>
> And since the interrupt enable seems to be an issue, be sure that you
> have haven't accidentally turned on TXIE, as that will remain on and
> interrupting until something is placed in TXREG.   I have run into
> problems where the PIC was continuously servicing a TXIF ISR which was
> not being checked and cleared.
>
> Joe W
>
>
>
> On 7/11/2013 12:28 PM, Neil wrote:
> > Been banging my head over a problem with the EUSART missing chars
> > coming into a PIC18F24K22.
> >
> > Quick overview -- I am sitting in a busy loop waiting for chars with
> > RC1IF, and processing anything that comes in right away.  I do have a
> > serial-receive interrupt routine that gets used later, but it's
> > disabled for now (PIE1bits.RC1IE =3D 0).  But it seems to be missing
> > about 5% of the incoming data, which I've verified is on the line with
> > a logic analyzer.
> >
> > After much ado, it seems that my serial-receive interrupt is being
> > called even though RX1IE is not set.  I've verified that PIE1 is also
> > being set to anything where this interrupt can be accidentally
> > enabled.  I've temporarily worked around it by setting my own
> > variable/flag, and telling the receive interrupt to check for that also=
..
> >
> > Anyone else run into this, or is there something else I may be missing
> > here?  IE: Is this really a bug, or will this turn out to be a "Doh!"
> > moment?
> >
> > Cheers,
> > -Neil.
> >
> >
>
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.