Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!nrl-cmf!ames!lll-lcc!unisoft!hoptoad!cfcl!dwh
From: dwh@cfcl.UUCP (Dave Hamaker)
Newsgroups: sci.electronics
Subject: Beyond Asynchronous RS-232...
Summary: Request for comments on an idea for enhanced asychronous serial comm.
Message-ID: <315@cfcl.UUCP>
Date: 21 Feb 89 08:31:38 GMT
Reply-To: dwh@cfcl.UUCP (Dave Hamaker)
Organization: Canta Forda Computer Laboratory, Pacifica, CA
Lines: 60

I have an idea for serial communications which sounds good to me, but
as a software type I'm not sure if it makes sense from an electronics
perspective.  This seems the obvious place to ask for feedback.

As background, there is a tendency to denigrate asynchronous communi-
cations as being 20% slower than synchronous communications because of
the start/stop bits required for each character in the former.  Also,
there has been an evolution of synchronous called "bit synchronous"
which is used in the SDLC/HDLC schemes.  I asked myself what a
corresponding evolution of asynchronous might be like.

What I came up with was the idea of using a start bit to signal the
transition from the idle state to the transmitting state, omitting
start/stop bits between adjacently-transmitted characters, and requiring
a minimum of nine stop bit times between non-adjacently-transmitted
characters.  The all-ones character is followed by an extra zero bit
to: 1) distinguish it from the return-to-idle-state pattern, and 2)
force line-state transitions so clock-drift can be compensated for.
The all-zeros character is likewise followed by an extra one bit
to: 1) mainly force the line-state transitions, and 2) allow the
coding of other signals, such as break.  Break is a long all-zeros
signal which must be at least three bit times longer than a character
time at the slowest defined bit rate, so that it is a speed-independent
signal.  The pattern of a character's worth of zero bits followed by
a zero bit then a one bit is a prefix used to multiplex status
information into the data stream, so we can use three-wire-style
interconnection.  I haven't settled on a particular coding scheme
for such status information, but the status-exchange protocol will
require enough sophistication to make disagreement as to current
status highly unlikely.

Status deals with things like hardware flow-control signals, ready
signals, and carrier-detection.  I think automatic speed detection
can profitably be included.

I can envision putting this kind of thing into a package which is
pin-compatible with current UARTs and USARTS, but I think I would
change the cabling scheme to use 4-wire modular telephone-style
connection.  DTE and DCE equipment would use exactly the same
connector socket with the same pin assignments (no more null
modem cables): looking into a socket without worrying about the
left-to-right/right-to-left pin assignment question yet, we get
something like:
                pin 1 = transmit data
                pin 2 = transmit ground
                pin 3 = receive ground
                pin 4 = receive data
which allows a common ground usage if you tie pins 2&3 together, but
also lets you wire for separate grounds and twisted pair.  Standard
modular plug cables connect pin 1 to pin 4 and pin 2 to pin 3; which
is _exactly_ what you want.

How doable is this?

(I know I have probably been overly concise in the above presentation,
but it is already getting long.  I'll happily respond to requests for
clarification.)

-Dave Hamaker
...!ucbvax!ucsfcgl!hoptoad!cfcl!dwh