Newsgroups: comp.robotics
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!bloom-beacon.mit.edu!spool.mu.edu!agate!darkstar.UCSC.EDU!nic.scruz.net!earth.armory.com!rstevew
From: rstevew@armory.com (Richard Steven Walz)
Subject: Re: Connection to Computer
Organization: The Armory
Date: Mon, 5 Dec 1994 12:43:52 GMT
Message-ID: <D0C8p6.9qA@armory.com>
References: <3bdnr8$t30@sun.lclark.edu> <3blmsc$hij@handler.eng.sun.com>
Sender: news@armory.com (Usenet News)
Nntp-Posting-Host: deepthought.armory.com
Lines: 54

In article <3blmsc$hij@handler.eng.sun.com>,
Chuck McManis <cmcmanis@Sun.COM> wrote:
>Mohammad Taei Tehrani (ttehrani@sun.lclark.edu) wrote:
>: 1- What port is better and easier to use, parallel or serial?
>
>The parallel port can move more data faster, there are fewer wires
>to hook up if you use the serial port. If your data rate < 115Kb
>(11K bytes/sec) use the serial port, else use the parallel port.
>
>: 2- In C or C++ how can I read the ports?
>
>By calling the library routines designed for that purpose. Look
>in the manuals that came with your C compiler.
>--Chuck McManis
>Internet: cmcmanis@Eng.sun.COM
-------------------------------------------------
Yes, tis true. C has no I/O of its own in kernel. It must use the library
routines for your particular machine. Else how could it be transportable!?
Anyway, I wanted to bring out a SIMPLE TRUTH about the parallel port. One
does NOT have to wire up ALL the lines and use them as the OS typically
does with printers or the like. For close local outboard I/O purposes, they
function as fast or faster than your UART/serial port, and they are already
at TTL levels, for the simple project I/O that people need for simple
programmers and such that would normally have to have something stupid,
like another set of RS-232C level shifters and a UART right outside the
computer to convert the messback to TTL. It is extremely easy to use the
totally reconfigurable port lines of the parallel port for data in or out,
on any parallel port. And one need not use more lines than one wishes to
control. The I/O can be addressed directly, with either the right function
or with in-line assembly. There are only the three addresses per port,
directly mapped to the output and input lines, and the state of all the
output lines can be read back. The serial port should only be used with
another already serial device, and with nothing else, because controlling
the UART is far more of a hassle in any kind of software, or else the
limitations of the library functions for this will become apparent. The
simple kinds of I/O, such as simple multiplexed data logging and data
transfer to outboard devices such as programmers and the I2C-type serial
EEPROM programming protocols, for example, are prebuilt into the capacity
of your paralle port, and are easy to implement. In the case of serial
EEPROMs, for example, only two lines and the ground need to be implemented,
and the open drain/collector data bidirectional line is already facilitated
in the port's control lines!! They are already of that type! It makes no
sense to do experimenter projects with the serial port when the parallel
port makes it so easy. Obtain the parallel port FAQ by Zhahai Stewart,
written with C programmers in mind, from:
             ftp.armory.com   /pub/user/rstevew/ibmlpt.faq
                               and also get the file: tomlpt.faq
which will give you a straight forward approach to experimenting with your
parallel port. Good luck, and I welcome any questions about this subject.
But only after you really read and work at understanding those files. What
seems long and drawn out is just being said over and over till you "light
up" with the realization of how simple it is.
-Steve Walz   rstevew@armory.com

