On Tue, Jan 22, 2002 at 02:03:01AM -0500, der Mouse wrote:
> > You should probably allow errors below 2% or something like that.
> > The async 8N1 protocol allows for more error (but that depends on how
> > the receiver samples the data)
> 
> Well, yeah, if the receiver samples stupidly, it takes only a tiny
> error to corrupt data. :-)  I recently built the equivalent of a UART
> out of discrete logic (counters, shift registers, &c) and recall going
> to some lengths to sample as close to the middle of the bit time as was
> practical (I think I got it to within one part in 16) - and to end the
> character as soon as I sample the stop bit, in case the sender is fast
> and the next start bit begins "early".  Such techniques should allow up
> to something like 5% disagreement between sender and receiver (half a
> bit time of drift over ten bit times is about one part in 20).

True.  Some UARTs take several samples of each bit and then use a majority
logic to decide the "real" state of the bit.  I guess they will still
work if they sample, say, 5 times (twice before the middle of the bit,
once at the middle, and twice after that), because the majority of samples
will be correct (eg. the mid-bit sample and the ones after that).

> How about one part in 64?  That's an easy enough change to make, and it
> brings a request for 115200 resulting in 113636+ within tolerance
> (though not by much - one part in 64 is 1.5625% error, and
> 115200->113636 is about 1.36% error).

That's still pretty tight, IMHO :)  But OTOH, the other end of the serial
link will probably have a certain bit rate error as well, so you'd better
leave some headroom for it, too..

> > Some software (minicom, for example) doesn't let you to type in the
> > baudrate, so if the only way to get 115200 bps out of your driver is
> > to ask for 113636 bps, you won't be able to use minicom at all :-)
> 
> (Won't be able to use it at 115200 at all, that is.)  Well, in general,
> my attitude is that that's a deficiency in minicom.

Yes, but you can't expect the user to know the exact bit rates his/her
serial interface can produce ;-)  If I say "115200 bps" I mean "as close
to 115200 bps as you can get, unless you can't get close enough to work
with other standard 115200 bps devices".

> But I'd point out
> that you can't get 115200bps out of the hardware, no matter what the
> driver does.

Yep.

  -jm