Date: Wed, 16 Feb 2000 12:51:12 -0700 From: Brett Glass <brett@lariat.org> To: Terry Lambert <tlambert@primenet.com> Cc: freebsd-chat@FreeBSD.ORG Subject: Re: Gimme FreeBSD anyday! Message-ID: <4.2.2.20000216123513.0445b480@localhost> In-Reply-To: <200002161920.MAA17806@usr02.primenet.com> References: <4.2.2.20000216114210.04307b30@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
At 12:20 PM 2/16/2000 , Terry Lambert wrote: >Actually, it's part of the Bell 103C standard, defining how >modems should function. Bell 103C wasn't synchronous over the wire; it was just an FSK rendering of the RS-232 or current loop signal. So, it didn't really care how long a break was! It just translated the line level into one tone or the other. >DEC implemented the break on VT100 terminals to be "as long as >the break key remained depressed". So did Western Electric in the Teletype. It broke the current loop while you held the key down, and the print head "chattered" to indicate that the loop was broken. The Teletype sometimes took two baud times to recover from a break before it would get the following character right. >However, it seems to me that the only reason for varing from >the 250ms 103C definition is to allow you to break in a >shorter time at a higher baud rate, since so long as you >were going at a higher baud rate, you would have more sampling >intervals to detect the break than at a lower baud rate. That's what UARTs do. They base their decision about whether there's a "break" on the number of character times for which the line has been at zero. 10 character times is a good number because it triggers even the most poorly designed UARTs. The National Semiconductor UARTs used in most PCs trigger fairly reliably at 3, but other UARTS and many modems want more. Since any modem above 300 baud does async-to-sync conversion and has to send a special signal over the wire to indicate a break, it's important to be sure you trigger recognition by the modem. My empirical tests showed that 10 character times was reliable and left a little margin for error. >As far as timings, I've always wondered why in _hell_ vendors >did not adhere to the RS232C specification when it came to >implementing external clock pins. I mean, we would never, ever >have had to care about baud rate matching if they had implemented >this stuff according to the specification. The external clock pins in RS232C were for synchronous applications, IIRC. And there were problems with skew. Also, line drivers and receivers were hideously expensive. (I remember having a long argument with a boss over whether we should put one extra MC1488 chip in a design to implement a few more handshake lines.) Finally, there's the issue of current. RS232C requires drivers to be able to sink and source a lot of it. You often had to beef up your power supply to handle more lines. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.2.20000216123513.0445b480>