dwh@cfcl.UUCP (Dave Hamaker) (02/21/89)
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!dwhblarson@skat.usc.edu (Bob Larson) (02/26/89)
In article <315@cfcl.UUCP> dwh@cfcl.UUCP (Dave Hamaker) writes: >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. > >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. While this is true, actual bits/second over a piece of wire is rarely a limitation. Just specifying better wire will get you up to at least the hundreds of megabits per second range. (Coax) A guarenteed, completely out of band flow control is MUCH more important. Modems and such that are woried about a few percent eficency could use this converting from async to sync. >I think automatic speed detection can profitably be included. If your going to spec a new protocol, you might as well specify exactly one speed and use the out of band flow control. The new protocol should be symetrical and include flow control, dtr/dsr, cd, etc without extra wires. >I think I would >change the cabling scheme to use 4-wire modular telephone-style >connection. These connecters are TO common to be considered. Most computers wouldn't like the 100 VAC ring signal from a phone, and the phone co. wouldn't like you shorting out their wires. Since (most) phones don't care about wiring polarity, you'll probably find many existing cables don't have the needed twist. (Not to mention the 2 wire cables.) Phone connectors don't support shielding. Good features of the phone connector include: cheap, easily available. I kind of like the idea of an androginous connector, so all cables may be used as extentions. (The connector would have a male and a female side.) I'd specify: cable: two sheilded twised pairs, shileds isolated from each other. Sheilds are a nessesity now that the FCC has cracked down on RFI. connector: (see above, I havn't found a real one I like) Transmiter: balanced, signal levels specifed so it can be driven from a single 5v power supply. Must respond to flow control within 2 characters. Receiver: opto-isolated, must detect loss of transmission signal (both lines at the same potentional) and force the transmitter to send same back for at least 1 second and reset all compunications paramaters to the defaults. Must accept 256 characters after sending flow control. (This allows 38 ms of transmission delay, enough for the local lines this is speced for.) Speed: 64k bits/second Both sides must be implemented for flow control, etc. even if all data transfer will be in one direction. More out of band signals to negociate error correcting protocol, etc. >How doable is this? The hard part is getting anybody else to implement it. The ANSI commitee that did RS422/RS423 obviously didn't understand what was wrong with RS232c. (25 pins is WAY too many, so they go to 37 plus an optional 15!) >-Dave Hamaker >...!ucbvax!ucsfcgl!hoptoad!cfcl!dwh Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu oberon!ais1!info-prime-request
jbn@glacier.STANFORD.EDU (John B. Nagle) (02/27/89)
In article <315@cfcl.UUCP> dwh@cfcl.UUCP (Dave Hamaker) writes: >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. What he describes turn out to be the specs for a low-end LAN, and is rather close, in fact, to AppleTalk. John Nagle