> > The manual says regarding RCSTA,FERR "Can be updated by reading RCREG
> > register and receive next valid byte".  I talked with the factory
> > about this and they said that once you have a framing error the USART
> > gets out of sync.  To get back into sync you need at least one byte's
> > worth
> > of stop bit. Only then will the next start bit be recognized
> >
> If I can jump in. Is this true? I am planing a project that will use a
> 16C65 USART with RS422 interface. The data recieved  has a continus
> stream of characters, so the longest time that I ever get a stop is 2
> bit times (1 start, 8 data, no paraty, 2 stopbits). For my device to
> work it is necessary for the data to be pluged in while the data source
> is transmitting. If what you say is true then there is no way that I
> could ever ger the USART to sync with a data character. Do I understand
> you?

Yes and no... it depends largely on the data stream in question.  If the
data stream contains entirely bytes in the range $40-$7F [i.e. the bit
pattern, LSB first, is xxxxxxHL] then even if nothing else causes a
false start-bit detect, the HL transition between bits 6 and 7 will be
seen as a start bit and neither the PIC's UART, nor any other, would ever
be able to recover.  Sync recovery in many other cases may be possible,
however; any byte containing the value $FF will ALWAYS cause a UART to
regain sync and bytes with high-order bits set often will.  Bytes with
many high-order bits clear may cause a UART to resync, depending upon
whether the UART looks for a falling start-bit EDGE or a low-start-bit
LEVEL.

By the way, one design I've used in software UARTs that should also be
reasonable in a hardware UART is to use a 32-bit shifter which runs at
3x the baud rate and look for certain bits to have certain values.  If
they do, latch the byte (from the proper stages) and clear the shifter.
This approach provides excellent sync recovery since it will not falsely
detect a start bit unless that suspected start bit has a stop bit a
suitable distance after it.  Any idea whether there'd be any problem
implementing this approach in silicon? [possibly using a longer shifter
and higher clock rate?]  Shift-latches are pretty cheap.