Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!ucbarpa.Berkeley.EDU!edward
From: edward@ucbarpa.Berkeley.EDU (Edward Wang)
Newsgroups: comp.dcom.modems
Subject: Re: New "Alternate Connector For Use With ANSI/EIA-232-D"
Message-ID: <31381@ucbvax.BERKELEY.EDU>
Date: 19 Sep 89 07:28:46 GMT
References: <870.251007A2@zswamp.fidonet.org> <328@gp.govt.nz> <8539@hoptoad.uucp>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: edward@ucbarpa.Berkeley.EDU.UUCP (Edward Wang)
Organization: University of California, Berkeley
Lines: 19

In article <8539@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>...  If TX Clock is being driven
>from outside, you use it as your transmitter clock; if the other side
>needs to flow control you, it stops the clock or slows it down as
>required.  You do the same to the other side by slowing or stopping RX Clock
>to alter the data flow on your RX Data line.

Don't you get into round-trip-time problems with long wires
and high data rates?


Anyway, I think we should just forget this single-character
transmission business.  Packet protocols have so many
advantages (error detection, etc.), and character-at-a-time
IO is already so heavily penalized that we almost never
have just one character to transmit.  (Keyboard input
is at such a low rate that it doesn't matter.)

Short of that, it's a great idea to clean up rs232c.