NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/sgi/16641

Text File | 1992-11-19 | 3.3 KB | 78 lines

Newsgroups: comp.sys.sgi
Path: sparky!uunet!spool.mu.edu!agate!doc.ic.ac.uk!cc.ic.ac.uk!imperial.ac.uk!vulture
From: [e-mail] (Thomas Sippel - Dau)
Subject: Re: Need help on serial I/O
Message-ID: <[e-mail]>
Keywords: TTY, Parity, driver, termio, serial
Sender: [e-mail] (Thomas Sippel - Dau)
Nntp-Posting-Host: cscgc
Reply-To: [e-mail]
Organization: Imperial College of Science, Technology and Medicine
References: <[e-mail]>
Date: Thu, 19 Nov 92 10:30:56 GMT
Lines: 63

In article <[e-mail]>, [e-mail] (John Fwu/HawkEye) writes:
- We got an 12-bit plus sign A/D converter with asynchronous
- serial interace.  The way it send 12 bit is pad the 12 bit
- into two bytes.  The lower byte has "even parity" and the upper
- byte has "odd parity".  We need to base on the parity to figure
- out the byte order then put the 12 bit data together.
-
- Base on my experience, we can use ioctl set the serial (tty) port
- to "none", "odd" or "even" parity.  How can we handle both parity
- at the same time.  May be we may set the parity to "even", then
- the upper byte will cause a "parity error".  How can we detect
- the "parity error" or it just not available in the UNIX tty
- driver?  If we were able to detect the parity error, can we
- also get the upper byte intact?

You need to set the port parity to none, because you want to
transfer eight bit data. If you get parity errors you need to
improve the cabling. More likey you would loose bytes if you
disable inetrrupts for too long, though with the Indogo or PI
you would have to work hard to manage that.

The way I see this is that the controller uses the parity to flag
whether it sends an upper or lower byte, with no guarantee that
a lower byte will always be followed by an upper byte (or vice
versa if you think big-endian).

Thus it might be that you get an upper byte, then a few lower bytes,

viz:                      o2  e12  e15  e33
to mean that values:          212, 215, 233

have been detected. You would need to confirm that. This does not
allow you to detect parity errors.

Conversely, if there is always a pair of bytes, the first one lower,
the next upper, then lower, then upper, etc. you would need a way
to resynchronise in case you lost a byte.

Having got these values and decided which bytes to pair, you can set
up a 256 entry table containing the values that the bytes represent, thus

      0)   0 + even parity      0
      1)   1 +  odd parity    128     (assuming lower byte contains 7 bit)
      2)   2 +  odd parity    256
      3)   3 + even parity      3
...
    128)   0 +  odd parity      0
    129)   1 + even parity      1
    130)   2 + even parity      2
...

and you can just use:  value = table [ byte 0 ] + table [ byte 1 ]

regardless of whether they come big-endian or little-endian.

Hope this helps.                      Thomas

--
*** This is the operative statement, all previous statements are inoperative.
*   email: cmaae47 @ ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
*   voice: [phone] x4937 or 4934 (day), or [phone] (fax)
*   snail: Imperial College of Science, Technology and Medicine
*   The Center for Computing Services, Kensington SW7 2BX, Great Britain