From: Patrick Maupin on 5 May 2010 22:33 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 6 May 2010 05:27
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. |