Article View: sci.electronics
Article #20833Beyond Asynchronous RS-232...
From: Dave Hamaker
Date: Tue, 21 Feb 1989 08:31
Date: Tue, 21 Feb 1989 08:31
60 lines
3602 bytes
3602 bytes
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
Technical Details
Message-ID:
<315@cfcl.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!nrl-cmf!ames!lll-lcc!unisoft!hoptoad!cfcl!dwhShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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