Parallel Port Access via API+DeviceIoControl. Obsolete?

[Jaelani]

Hello,

For serial ports access, the Windows API functions are enough and
there's no (or rarely) need to use DeviceIoControl. But for parallel
ports, it seems different. Both Windows API functions including
DeviceIoControl function seem obsolete and are not sufficient enough for
accessing any type of devices.

I'm well familiar with low level serial port access but not for parallel
port, so correct me if I'm wrong. My above conclusion is based on the
fact that there are dozens of third-party device drivers for accessing
parallel port devices.

So my question is: Is my conclusion correct?

Thanks in advance.

[ScottMcP [MVP]]

The parallel driver provided with Windows only does printers, and only
in the simplest port modes. So third party drivers are needed for
nonstandard devices or applications.

[Jaelani]

ScottMcP [MVP] wrote:
> The parallel driver provided with Windows only does printers, and only
> in the simplest port modes. So third party drivers are needed for
> nonstandard devices or applications.

I see.
Thank you very much.

[Bob Masta]

Parallel ports run in Ring 0 on NT,XP, etc, so
user code (in Ring 3) can't access them directly.
That's why you need the drivers. (Actually, all
port I/O, including serial port, is like this...
it's just that Windows provides a standard serial
port driver that is good enough for most
purposes.)

Best regards,

Bob Masta

DAQARTA v4.51
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Sound Level Meter
FREE Signal Generator
Science with your sound card!

[Jaelani]

Bob Masta wrote:
> Parallel ports run in Ring 0 on NT,XP, etc, so
> user code (in Ring 3) can't access them directly.
> That's why you need the drivers. (Actually, all
> port I/O, including serial port, is like this...
> it's just that Windows provides a standard serial
> port driver that is good enough for most
> purposes.)
>
> Best regards,
>
>
> Bob Masta

But are the standard I/O functions (e.g. ReadFile/WriteFile) combined
with DeviceIoControl really insufficient? What kind of operation that's
not possible?

[Markus Schaaf]

Jaelani wrote:

> But are the standard I/O functions (e.g. ReadFile/WriteFile) combined
> with DeviceIoControl really insufficient? What kind of operation that's
> not possible?

Communication between computer and printer is something like this: Drive
the data pins, pulse the 'strobe' pin, wait for a pulse on the
'acknowledge' pin, then stop driving the data pins. This is
oversimplified, but you get the idea. If you need, for instance, D0 set
high and D2 set low for a while, you are out of luck.

[Jaelani]

Markus Schaaf wrote:
> Communication between computer and printer is something like this: Drive
> the data pins, pulse the 'strobe' pin, wait for a pulse on the
> 'acknowledge' pin, then stop driving the data pins. This is
> oversimplified, but you get the idea. If you need, for instance, D0 set
> high and D2 set low for a while, you are out of luck.

:)
That oversimplified explanation alone is already went over my head. I
didn't know that parallel port controller is quite more
active/independent that serial port controller. I guess I have to get a
crash course on parallel port controllel programming.

Thank you.

[pete]

It's not that all that easy; I pondered for long before I grokked
parallel I/O.

First, let's call the parallel-port hardware by the name "PIO" for
short. The PIO stands between your program and the device you are
trying to control. That device -- the one on the other side of the PIO
from you -- has connectors or pins that receive commands and data from
your program; and other pins that send status back to your program.
Let's call the collection of these paths by the name "interface."

The arrangement and function of data, command, and status pins on the
device is of course entirely up to the designer, so every device's
interface is in practice unique. This uniqueness precludes any general-
purpose driver for PIO-controlled devices.* It's the impossibility of
general-purpose drivers that I think Markus is talking about when he
says "If you need, for instance, D0 set high and D2 set low for a

while, you are out of luck"

The PIO that stands between you and your device exists to arrange and
organize the device's unique interface and to present that interface
to you in a manageable, understandable way (IMO).

Imagine that your device is a coffeemaker. And let's say that the
coffeemaker has a data input: desired coffee strength. And it has a
data output: current coffee temp. It also has to have some command
inputs: turn the heater plate on and off, start/stop brewing. We also
need a status output: coffee is done. And there might be some not-so-
obvious commands to the coffeemaker, like: the desired-coffee-strength
data is available so, coffeemaker, please read it now (this is the
'strobe' in Markus's example).

To run the coffeemaker is merely (heh! merely! :-) to set and clear
bits in the PIO as you wish.

The PC implements the PIO just as if it were an Intel 8255A chip. The
data sheet for the 8255A is:

http://www.ic-on-line.cn/IOL/viewpdf/8255A_38897.htm

And an English-language discussion of its use is:

http://www.sharpmz.org/mz-700/8255ovview.htm

HTH

-- pete

------------
* Of course, there must be exceptions and the exception here is the
printer interface, a de facto standard invented by the printer
manufacturer Centronics in a universe far away. In early days, every
printer had to be "Centronics compatible" and still is.

[Bob Masta]

You might want to check out Jan Axelson's
comprehensive site for all kinds of ports at
<www.lvr.com>