William Chops Westfield wrote:
(Hmmm.  Must be careful here, dealing with the *big* guys!)

> I don't see how you can resynchronize accurately without a mark
> condition lasting more than one CHARACTER time.  Otherwise, there's no
> way to distinguish the stop/start bit combination from any other two
> consecutive zero ("space") bits.

  Ahhh!  You presume *immediate* correction.  I wasn't proposing
immediate resynchronisation.  Let's face it, whatever caused the loss of
synch in the first place must have garbled at least two characters, so
you're not going to recover everything, a few more errors is neither
here nor there.  Consider perhaps a continuous stream of PPP data.

  The one thing that characterises the data is the previous stop/
current start bit.  That pair is *always* Mark/Space.  If characters are
out of synch, then when the receiver expects to see a stop bit followed
by a start, if it *happens* to see a Mark:Space pair at that point then
it will continue out of synch.

  But not every character will contain that combination at that point
(whenever that point is).  Any other combination will cause the receiver
to *wait* for that combination, so the timing slips later in the
character stream.  With a mix of characters as I said, it will sooner or
later slip successively back until it is *actually* synchronising on the
real Stop/ start pair.

  And a point about implementing software UARTs.  Whether or not you
utilise a framing error (break detect) function, it is for this reason
quite desirable that the stop bit detection "lock out" on a space
(framing error or break) until a mark is secured (perhaps for a complete
bit time) rather than "running open" and returning continuous NULs.
--
  Cheers,
        Paul B.