Win32 programming for ECP

Leif Opseth

unread,

Mar 18, 1998, 3:00:00 AM3/18/98

to

Hi,

I'm trying to use the PC parallel-port for high-speed data-aquisition,
utilising the lpt.vxd driver/Win32 and ECP-mode. I need help on the
following issues:

1. The ECP-handshake says that the ReverseRequest-line (line 16 on 25-pin
connector) should go LOW to initiate a transfer in reverse direction (a
read from the PC), but after a call to Win32 function
CreateFile("LPT!",........) this line stays HIGH. Do I need to do some
additional hardware-handshaking to get the printer-port into its reverese
direction mode (with line 16 put LOW) or is it possible to do this through
software ?

2. The documentation on the standard Windows95 printer-driver (lpt.vxd) and
it's use is awful. I've seen somewhere that the Win32 functions ReadFile
and WriteFile cannot be used on the parallel-port, and that I have to use
the DeviceIoCtrl function instead. Can anyone confirm this and are there
any sample-code available ?

3. Does the lpt.vxd support EPP as well as ECP ? If not, are there any
available drivers I can use to get access to EPP through Win32 routines ?

Thanks,
Leif Opseth

Colene J. Allen

unread,

Mar 18, 1998, 3:00:00 AM3/18/98

to

Hello Leif,

Most of what you've asked in this post is over my head, except for the
question about EPP. EPP is NOT supported by Windows 95 in any way shape
or form.

Good luck finding the answers to the other questions.

Regards,

Colene Allen
MSN Windows NT Forum Contributor
MCP - Windows 95

Andrew Klossner

unread,

Mar 18, 1998, 3:00:00 AM3/18/98

to

> I'm trying to use the PC parallel-port for high-speed data-aquisition,
> utilising the lpt.vxd driver/Win32 and ECP-mode. I need help on the
> following issues:

> 1. The ECP-handshake says that the ReverseRequest-line (line 16 on 25-pin
> connector) should go LOW to initiate a transfer in reverse direction (a
> read from the PC), but after a call to Win32 function
> CreateFile("LPT!",........) this line stays HIGH. Do I need to do some

> additional hardware-handshaking to get the printer-port into its reverse
> direction mode?

The nReverseRequest line only has that meaning after the host and
printer have successfully negotiated to ECP mode. Have you done that?

I have discovered through trial and error that Windows will only
attempt ECP mode if the printer port has an IRQ and a DMA channel
assigned. Check Control Panel / System / Resources for that LPT port.

-=- Andrew Klossner (and...@teleport.com)

jason hummel

unread,

Mar 18, 1998, 3:00:00 AM3/18/98

to

Leif Opseth wrote:

> Hi,

>
> I'm trying to use the PC parallel-port for high-speed data-aquisition,
> utilising the lpt.vxd driver/Win32 and ECP-mode. I need help on the
> following issues:
>
> 1. The ECP-handshake says that the ReverseRequest-line (line 16 on 25-pin
> connector) should go LOW to initiate a transfer in reverse direction (a
> read from the PC), but after a call to Win32 function
> CreateFile("LPT!",........) this line stays HIGH. Do I need to do some

> additional hardware-handshaking to get the printer-port into its reverese
> direction mode (with line 16 put LOW) or is it possible to do this through
> software ?
>
> 2. The documentation on the standard Windows95 printer-driver (lpt.vxd) and
> it's use is awful. I've seen somewhere that the Win32 functions ReadFile
> and WriteFile cannot be used on the parallel-port, and that I have to use
> the DeviceIoCtrl function instead. Can anyone confirm this and are there
> any sample-code available ?
>
> 3. Does the lpt.vxd support EPP as well as ECP ? If not, are there any
> available drivers I can use to get access to EPP through Win32 routines ?
>
> Thanks,
> Leif Opseth

Sorry, you'll wind up either buying or writing your own device driver to
do so. MS's view on the subject is: LPT is for printers (one way street),
not hardware developers:-) It kinda goes against the print spooler technology
since you're monopolizing the port, contention handling becomes an issue.

I agree, it's not the smartest thing MS could have done. It certainly opens

up the possibility for a rash of LPT drivers like back in the Win 3.1/comm.drv
days:-(

After seeing hundreds of posts regarding this subject, something really
needs
to be done about it. Probably the smartest thing someone could do, is create a
"freeware" lpt driver for the hardware people. At a bare minimum, it would set
a standard set of data structures/api's interface. Unfortunately, this would
mean
two version to provide such functionality, one for 95 and the other for NT,
which i don't think any one would like to do for free. The only other
alternative
to that solution, is for everyone in the NG's to "pitch in" by forming two
groups.
The total group being responsible for the interface, while each individual
group
being responsible for it's particular OS's implementation.

If any one is interested in doing so i'll be more than happy to provide a
"clearing house" of sorts. I'd be more than happy to keep up with
documentation,
provide a conduit between the NG's and the lpt development groups, and finally
a small homepage to publish such results. The most important aspect, imho, is:
the interface, the obviously needed lpt data structures, and implementations,
should
fall into line with the current Win32 API. If your interested in partaking in
such,
you may either respond to this post or drop by the home page,
www.ols.net/~keycad1.

I only bring this to light since i've spent a great deal of effort
attempting to provide:
a working set of code examples, a help file, note the api differences between
95/NT
and their workarounds, and a bug list, for the Win32 API regarding the serial
port.
This would fall into what i'm currently doing and follow one of my points of
interest.
And while we're on the subject of drivers, the 95 serial.vxd sure needs some
work too:-)
(i.e. rts toggle mode, fifo bug, ev_ring, getting the status of rts/dtr lines)
Can't obviously
do it all my self.<g>

Regards,
jason hummel

Michael Slade

unread,

Mar 19, 1998, 3:00:00 AM3/19/98

to

In article <01bd5270$740a78a0$7c5f...@contecws008.nera.no>, l...@contec.no
says...

>
>Hi,
>
>I'm trying to use the PC parallel-port for high-speed data-aquisition,
>utilising the lpt.vxd driver/Win32 and ECP-mode. I need help on the
>following issues:
>
>1. The ECP-handshake says that the ReverseRequest-line (line 16 on 25-pin
>connector) should go LOW to initiate a transfer in reverse direction (a
>read from the PC), but after a call to Win32 function
>CreateFile("LPT!",........) this line stays HIGH. Do I need to do some
>additional hardware-handshaking to get the printer-port into its reverese
>direction mode (with line 16 put LOW) or is it possible to do this through
>software ?
>
>2. The documentation on the standard Windows95 printer-driver (lpt.vxd) and
>it's use is awful. I've seen somewhere that the Win32 functions ReadFile
>and WriteFile cannot be used on the parallel-port, and that I have to use
>the DeviceIoCtrl function instead. Can anyone confirm this and are there
>any sample-code available ?
>
>3. Does the lpt.vxd support EPP as well as ECP ? If not, are there any
>available drivers I can use to get access to EPP through Win32 routines ?
>
>Thanks,
>Leif Opseth

I share your frustration - I'd like to do some sending and retrieving of data
from the parallel port, too. Can't find the documentation either! What are the
best places in the MSDN or elsewhere that you have found?

Is there an example of using the parallel port or is it all serial port with
the parallel case left as an example to the reader?

However, I suspect that what you want to do may not be as simple as it seems.

I think that the port, even if 'ECP enabled', gets into ECP or EPP mode as a
result of a IEEE 1284 negotiation with the peripheral.

Michael Slade

Richard Wirth

unread,

Mar 23, 1998, 3:00:00 AM3/23/98

to

jason hummel <key...@ols.net> wrote:

>
>
>Leif Opseth wrote:
>
>> Hi,
>>
>> I'm trying to use the PC parallel-port for high-speed data-aquisition,
>> utilising the lpt.vxd driver/Win32 and ECP-mode. I need help on the
>> following issues:

>>............

>>
>> Thanks,
>> Leif Opseth
>
>
> Sorry, you'll wind up either buying or writing your own device driver to
>do so. MS's view on the subject is: LPT is for printers (one way street),
>not hardware developers:-) It kinda goes against the print spooler technology
>since you're monopolizing the port, contention handling becomes an issue.
>
> I agree, it's not the smartest thing MS could have done. It certainly opens
>
>up the possibility for a rash of LPT drivers like back in the Win 3.1/comm.drv
>days:-(
>
> After seeing hundreds of posts regarding this subject, something really needs
>to be done about it. Probably the smartest thing someone could do, is create a
>"freeware" lpt driver for the hardware people. At a bare minimum, it would set
>a standard set of data structures/api's interface. Unfortunately, this would mean
>two version to provide such functionality, one for 95 and the other for NT,
>which i don't think any one would like to do for free. The only other alternative
>to that solution, is for everyone in the NG's to "pitch in" by forming two groups.

>.....................

>
>you may either respond to this post or drop by the home page,
>www.ols.net/~keycad1.
>

>(i.e. rts toggle mode, fifo bug, ev_ring, getting the status of rts/dtr lines)
>Can't obviously
>do it all my self.<g>
>
>
>Regards,
>jason hummel
>

Hi,

Last year a friend of mine who is always playing with hardware on the
LPT-Port asked me for a lpt-driver for NT. So I wrote a small and very
simple tightly coupled lpt-driver. It only supports per byte access to
the lpt ports via ioctrl. So it is very slow. But for first testing it
is working. If one needs better performance (via block-i/o) we have to
define a new interface for read / write. Any suggestions?
If anyone is interested, send an e-mail...
(I would give the driver for free)

Regards,
richard wirth

r.w...@wirthware.nowhere.de
>>> replace ".nowhere." with ".da-net."....