Chuck Guzis wrote:
On 7/28/2006 at 2:49 AM der Mouse wrote:
No, the line - the DTE data line, that is - is
potentially changing
state 2400 times a second; ergo, 2400 baud. 20% of those bit times
convey almost no information when viewed at a higher level, but that is
irrelevant. ("Almost" because they do convey a little information,
namely, where character boundaries fall in the data stream - though
even that they convey imperfectly if characters are sent back-to-back.)
One could perhaps make a case for the start bit, as it signals the start of
a character and so conveys some information. But the stop bit isn't even a
bit; it's an empty, information-less time, doing nothing but demarcating
the beginning of the start bit. As long as the signal returned to a
spacing level sometime, I suspect the actual content of the "stop bit" time
is immaterial. Although I've not tried it, I suspect that 1/2 stop bits
would work fine with most modern UARTs. Maybe someone with a bit-banger
program at hand could verify this.
Most UARTs only *check* one stop bit -- regardless of the
actual setting of the "number of stop bits" parameter.
And, most (modern) UARTs try to sample near the center of
the bit-time (usually within 5% thereof). So, conceivably,
something O(0.5) would work.
But, you also need to allow for relative deviations in
bit-rate clocks between sender and receiver. So, the UART
should start hunting for the next start bit AS SOON AS
it has determined the STOP bit's presence.
Conceivably, it could begin hunting as soon as the last
*DATA* bit was detected (since a UART can obviously count
bit-times :> ). But, you'd need to ensure *some*
marking states were present in the data stream before
the clock deviations exceeded half a bit-time in order
to safely recover the data stream.
And, of course, there's a lot more logic involved in
doing this than was present in early UARTs. So, the
stop bit was a convenient place to "fix things up"
in the data stream.
Of course, today's EIA232 implementations bring their
own slew of "issues"... run at higher bit-rates than
the standard was intended to address, less capable of
driving reactive loads, etc.