parallel port access?

[Suchandra Thapa]

Jochen Küpper <jochen at pc1.uni-duesseldorf.de> wrote:
>>>>>> Suchandra Thapa wrote on Thu, 07 Dec 2000 08:26:19 GMT:
>
>Well, on many unices there is the common idea of a printer beeing a
>file:-) This means you have a driver sitting behind it, and simply
>writing to that file sends your data to the port.
>Direct access to the ports in general requires kernel-level priorities
>or root-access and going through ioperm or such...

    Although, the printer may be  just a file on unices, 
I see generic access to the parallel port as being more than just printing.
I take generic access to the parallel port to mean that you are able to
change the status of individual lines so you can interface with 
various devices that don't follow the standard printer methods (I'm not
sure this exists witht the variety of printers out there).  If I were
to use the parallel interface from the python library, I would certainly
hope for this type of functionality since printing to files can be done
without the interface by opening a connection to lptx on windows/nt or
opening a pipe to lpr on unix.
    Also a printer does not correspond to a parallel port.  The printer
may in actuallity be a networked printer down the hall or something
in another location entirely.  
    
>I don't see a need to write a driver for each platform, only DOS
>probably, which doesn't bring one by itself [1].
>
>So I would say you'll need a generic wrapper function for sending data
>to the OS, that's it. On Unix I'd say all the problem reduces to find
>out wether there is a printer-file and what it is called.
>
>[1] Then a parport is such a simple device, for most applications you
>really don't need a real driver...

    It depends on what mode you are using and what device you are communicating
with.  If you look at timing diagrams for ECP or EPP operations, there
are fairly strigent requirements on the how quickly certain lines have to 
change.  E.g. if you raise line 1 (ACK) to +5 V to indicate a data transfer 
then you must raise lines 2-9 (data) to the values being transfered
within x milisecs or the device will raise one or more of the control lines 
to indicate an error and you need to deal with that then.  Also devices
like scanners and zip drives have more complex protocols than printers.

    For windows nt a kernel driver must be written since the os doesn't
provide the required functionality and you can't go around the os and 
access the port directly.  With windows 98, you can access the hardware but 
it's probably better to write a driver and use that. I'm not sure what the
requirements are for various unixes, but I suspect a driver would be required
to get the level of control I've indicated.

-- 
------------------------------------------------------------------
			    |
Suchandra Thapa             | "There are only two kinds of math books. 
s-thapaNO at SPAMuchicago.edu  | Those you cannot read beyond the first 
			    | sentence, and those you cannot read 
			    | beyond the first page."
			    |                       -C.N. Yang
------------------------------------------------------------------