From: Patrick Maupin on
On May 5, 7:38 pm, Symon <symon_bre...(a)hotmail.com> wrote:
> On 5/5/2010 10:03 PM, glen herrmannsfeldt wrote:
> > Also, the RS232 asynchronous communication stop bit is needed
> > to allow for possible clock differences between two stations.
>
> Also, I am interested in your concluding statement about RS232 stop
> bits. I gather you live in a world of half-duplex.
>
> How would you propose to eradicate the stop bit in a world where we are
> all synchronised?
>
> How would we synchronise ourselves?
>
> Would we need to be adjacent?

First of all, I'm never sure exactly how serious some of your
questions are. Especially on the latter two questions, I'm not sure
exactly where your tongue is. But on the off-chance that it's not
firmly planted in your cheek, I will endeavor to answer some of these
questions.

In asynchronous serial communications, the start and stop bit happen
even in full duplex communication -- they have nothing to do with half
duplex. Turn-around in half-duplex modems is a much more cumbersome,
time-consuming event than a single bit time will allow for. That's
what the RTS and CTS signals are for ("Request to send" and "Clear to
send", as in "I want to talk" and "OK, nobody else is talking, I fired
up our carrier and it's been long enough the other side should have
locked to it, so you can start sending bits.")

But async itself is a very simplistic scheme. The only "locking" of
the source and destination clocks happens based on the leading edge of
the start bit. Assuming the simple case of 8N1 (8 bits, no parity,
one stop bit), ten bits are transmitted for every 8 bits. That may
sound like 8b/10b, but trust me, it's not! There is no DC balance, no
guaranteed transitions, no out of band framing indicators, none of
that fancy stuff.

The worst case for RS232 is recovering the 0x00 character, which at
8N1 will be 9 low bits followed by a high bit. If the receiver clock
is too fast, it might think there is a missing stop bit ("framing
error" or "break") If the receiver clock is too slow, it might think
that what was transmitted was a 0x80 (think the stop bit was the last
data bit).

After receiving the leading edge of the start bit, you use "dead
reckoning" to try to sample in the midpoint of every bit. You hope
that the delta between your clock and the source clock is not too
much, and that the cable is not so long that pre-charge distorted the
first bit a lot, and that the interminably long slew rate is
symmetrical around your receiver's transition point. A quick back of
the envelope calculation shows that for 8N1, you could support a
receive/ transmit clock delta of approximately 5% if there were no
start bit distortion and no slew asymmetry. Many typical RS232
circuits (ab)use this tolerance to transmit or receive a percent or
two off the nominal frequency.

There are lots of ways to get rid of the need for a start and stop bit
short of using full-blown 8b/10b. Bisync is an ancient one; SDLC/HDLC
is merely old. Both of these technologies send packets of bytes at a
time, usually with a CRC for error correction, whereas async is
perfectly happy to send a single byte, and is often used for short
hauls with no error detection or correction.

BTW, because async is so simple, the UART is usually given as a task
to the intern. Guess which block often comes back with lots of corner
case errors?

Regards,
Pat
From: Symon on
On 5/6/2010 3:33 AM, Patrick Maupin wrote:
> On May 5, 7:38 pm, Symon<symon_bre...(a)hotmail.com> wrote:
>> On 5/5/2010 10:03 PM, glen herrmannsfeldt wrote:
>>> Also, the RS232 asynchronous communication stop bit is needed
>>> to allow for possible clock differences between two stations.
>>
>> Also, I am interested in your concluding statement about RS232 stop
>> bits. I gather you live in a world of half-duplex.
>>
>> How would you propose to eradicate the stop bit in a world where we are
>> all synchronised?
>>
>> How would we synchronise ourselves?
>>
>> Would we need to be adjacent?
>
> First of all, I'm never sure exactly how serious some of your
> questions are. Especially on the latter two questions, I'm not sure
> exactly where your tongue is. But on the off-chance that it's not
> firmly planted in your cheek, I will endeavor to answer some of these
> questions.
>
In this case the questions are rhetorical to provoke Glen into thinking
about what he posts.
Thanks, Symon.