> All right, it was a unanaimous response to use the parallel port instead of
> the serial port to twiddle pins on a IO port. Anyone have a quick snipit
> of code or direction to go. I have the IOport programming howto which shows
> how to set up port to be talked to, but does not explain how to exactly
> talk to the port itself. Any help would be appreciated.
> --
> =========================================================================
> | Andrew F. Nelson Computer Science |
> | URL: http://www.cs.umn.edu/~nelson |
> | Title: WWW Administrator / Systems Staff |
> | Computer Science and Institute of Technology |
> | "Murphy's Law isn't just a saying, it is a way of life!" |
> =========================================================================
I wrote some code to do just this. Look at:
ftp://ftp.cs.colorado.edu/users/kuzminsk/pio-0.96.tar.gz
It's an old user-space parallel port device driver. It requires superuser
privilege to run. It may or may not work right. Also it's not very well
documented, but it's a place to start.
Sebastian Kuzminsky
For Encrypted Mail: PGP Public Key Available upon Request
1. Parallel port programming (was Game port programming)
Well, you do need a driver. But there is a parallel port driver already
through which you can communicate. And then the rest can certainly be
written in a high level language. You can talk to your parallel port
through read/write calls to /dev/lp -- I'm pretty sure. I'll bet it's not
/dev/lp, but you can find it in your dmesg output or just go to /proc/ and
look at devices. It has the same interface as a character based file. That
is, you can't lseek, but you can read and write to the port. If all you
have is 8 flip relays hanging off the port, it's trivial to talk to it. If
you've got more, then you have to dream up some kind of protocol. For
example, if you have 16, you could have the protocol where the first 8 bits
(the first pulse) drive the first 8, and the second pulse through the port
drive the next 8. Printers work on a much higher level. They communicate
streams of data from machine to machine and the data contains the
instructions on what to do. Mostly they're bit streams, but occassionally
(sp!) there will be instructions for color change, end-of-line (i.e., the
rest of this line is 0 bits, so why send it?), etc.
Using the port of your machine should be easy and fun!!
You can actually go to an electronics enthusiasts store (like Radio Shack
in the United States) and buy two bit books which describe how to build a
parallel port LED gizmo. You could certainly drive that from shell scripts.
~> echo "a" > /dev/lp
would turn on a simple bit pattern on the device.
~> echo "Hello" > /dev/lp
would turn on a flashing bit pattern on the device.
-- Randy
ps: you're right, "spamhasruinedemail"
2. [ATM] forerunner he support
3. "rm -rf /usr/ports" before "tar -xvzf ports.tar.gz"???
5. ipchains: icmp "port" 8 to "port" 0
6. Bug in Foxpro Unix - Beware
7. Questions on the purpose of port 53 "domain port" and 6013
9. Unix socket programming - port "zero"?
10. Looking for Linux clone/port of Unix "Ching" program
11. GETSERVBYNAME()????????????????????"""""""""""""
12. Programming the serial and parallel ports.
13. Why am I getting "ILLEGAL PORT COMMAND" messages?