izen@amelia.nas.nasa.gov (Steven H. Izen) (12/06/89)
I know what even parity and odd parity are, but what does *space* or
*mark* mean in a parity choice? Also, I think I understand what happens
when the bits/parity is 8/none or 7/even or 7/odd. But where is the parity
bit stored when 8/even is used? Is there any good introductory reference
to this?
Thanx.
--
Steve Izen: {sun,uunet}!cwjcc!skybridge!izen386!steve / Quote corner:
or steve%izen386.uucp@skybridge.scl.cwru.edu /
or izen@cwru.cwru.edu /-------------------------/ My second bike is a car.
| The problem is that I *was* paying attention.gwyn@smoke.BRL.MIL (Doug Gwyn) (12/07/89)
In article <4090@amelia.nas.nasa.gov> izen@cwru.cwru.edu (Steven H. Izen) writes: >... what does *space* or *mark* mean in a parity choice? Space is always 0, mark is always 1. >where is the parity bit stored when 8/even is used? Assuming the "8" means "8 data bits", 8/even describes a nine-bit transmission format (actually, in asynchronous mode it will be 11 bits due to one start and one stop bit per character). >Is there any good introductory reference to this? Digital Press used to sell a good intro to data communications by McNamara. I don't know if it's still in print.
prc@erbe.se (Robert Claeson) (12/07/89)
In article <4090@amelia.nas.nasa.gov>, izen@amelia.nas.nasa.gov (Steven H. Izen) writes:
: I know what even parity and odd parity are, but what does *space* or
: *mark* mean in a parity choice?
Space = parity always cleared.
Mark = parity always set.
: Also, I think I understand what happens when the bits/parity is 8/none
: or 7/even or 7/odd. But where is the parity bit stored when 8/even is
: used?
Yes. The parity bit is *not* part of the data sent, but of the *protocol*
used to send the data. Therefore, parities and such have more to do with
start and stop bits than with the data bits. Any reasonable tty driver
should strip off all *protocol* information (including software flow control)
and only pass you the interesting stuff, ie the data without any parity.
So, 7 data bits and even parity is really sent as <start bit> <7 data bits>
<parity bit> <stop bit>. Some weird protocols uses two or even one-and-a-half
stop bit. Therefore, 8 data bits and even parity is sent as <start bit>
<8 data bits> <parity bit> <stop bit>. Nothing strange about it.
: Is there any good introductory reference to this?
Not as far as I know, but I'd like to see one.
--
Robert Claeson E-mail: rclaeson@erbe.se
ERBE DATA ABgwyn@smoke.BRL.MIL (Doug Gwyn) (12/08/89)
In article <1038@maxim.erbe.se> prc@erbe.se (Robert Claeson) writes: >Some weird protocols uses two or even one-and-a-half stop bit. 1.5 stop "bits" are standard at 110 bps. This has historical origins in the design of electromechanical teletypewriter units such as the Teletype model 33 (a real classic). In asynchronous communication, a UART receiver can be set for 1 stop bit even if the transmitter provides more than 1, because the extra "stop" marking is indistinguishable from line idle and won't confuse the receiver. The basic operation of electromechanical teleprinters in this regard is as follows: Current flows continually while in an idle condition. This current energizes a solenoid in the receiver that keeps a clutch disengaged. When a start bit occurs, the solenoid disengages and the clutch engages, typically locking a cam-like device onto a continuously rotating shaft. As successive data bits occur, a data electromagnet moves back and forth, setting up mechanical "gates" (selector levers or equivalent) that will determine the exact positioning of the print head. After all data bits have occurred, the rotating cam triggers the print mechanism and the selected character is printed (along with carriage advance, etc.). The stop bit energized the solenoid that catches and holds the rotating cam with open clutch, restoring the idle condition. If you like mechanical devices, these machines are fascinating. Rumor had it that Teletype Corp. had their engineer Kleinschmidt committed to a mental institution and would let him out just long enough to design a new model. From studying these creations, I can believe it!
buck@siswat.UUCP (A. Lester Buck) (12/09/89)
In article <1038@maxim.erbe.se>, prc@erbe.se (Robert Claeson) writes: > In article <4090@amelia.nas.nasa.gov>, izen@amelia.nas.nasa.gov (Steven H. Izen) writes: > : Is there any good introductory reference to this? > > Not as far as I know, but I'd like to see one. There are several good references. One is C Programmer's Guide to Serial Communications by Joe Campbell, 1987 Howard W. Sams & Company $22.95 paperback ISBN 0-672-22584-0 -- A. Lester Buck buck@siswat.lonestar.org ...!texbell!moray!siswat!buck