But nobody (read your datasheets) ever calls them
anything but "stop
bits", not "stop bit time".
Nobody ever calls them DE9, either, always DB9. Doesn't make it
correct. (Doesn't make it wrong, either, of course; just pointing out
that popularity isn't that reliable a guide.)
[...] I think
I once saw documentation on one [UART] which implied
that it was willing to tolerate receiving a character that was only
(what the receiver's clock says is) only a little over 9.5 bit times
long, [...]
But is there any point to that in modern gear? In fact, why not a
PLL to synchronize the receiving clock?
(a) There can be a more-or-less arbitrary clock phase shift between
consecutive characters; (b) PLLs generally take a little while to
synchronize - at least a few cycles - which means losing the first few
bits; (c) if you know the clock frequency, a PLL is overkill (and still
suffers from the foregoing), and, if you don't, it's impossible in
general to get it from a single character (as I pointed out upthread
with the 312.5 us pulse example). And you can't count on having more
than one character to work with.
At least, assuming we're still talking async, which I thought we were.
Oh, and (d) PLLs are significantly more complex, and thus expensive,
than a divided-down high-frequency clock, whereas the latter is good
enough for almost all applications. (This admittedly loses some of its
force for modern purposes, since either one is ridiculously cheap these
days, at least when on the same die as a bunch of other stuff.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at
rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B