Best way to access to the parallel port
Nassim
First,let me explain the situation : I have a special device that is
connected to the parallel port(Using ECP or EPP) and I need to
communicate with,use DMA(PC to the device) and IRQ under Windows
2000/XP.
For the moment, I have successfully used some I/O drivers to access
directly to the port(PortTalk,DLPortIO...),but it seems to be in a
dirty way(and I am not sure that I can use DMA),as these drivers are
using some undocumented functions to LOCK/UNLOCK ressources,overriding
the parport.sys driver.
For the moment,I am quite confused,because I don't know what is the
best way to access to the parallel port.
Must I write an UpperFilter driver for parport.sys that handle some
custom IOCTLs?
Must I write a parallel port class driver(Like parclass)?
Or,can I just lock ressources when I use the application,as it is going
to be the only one that access to the parallel port,when loaded?
I also heard that if It's also possible to remove parport.sys and to
replace it with a "home made" driver,but I am not interested by this
case cause I want to keep the parallel port working normally with other
applications.
Thank you in advance and sorry for my bad english.
Nassim.
Arkady Frenkel
all such programs ( you mention ) do , in W9x you can directly read/write
( but any case that emulation )
Arkady
"Nassim" <nassim.bo...@st.com> wrote in message
news:1111065503....@g14g2000cwa.googlegroups.com...
Spiro Trikaliotis
Arkady Frenkel <ark...@hotmailxdotx.com> wrote:
> If you are in NT kernel Oses you have to write ( filter ) driver , that what
> all such programs ( you mention ) do
Well, but filter driver will not be the best choice, IMHO. The OP should
look up IOCTL_INTERNAL_PARALLEL_PORT_ALLOCATE,
IOCTL_INTERNAL_GET_PARALLEL_PORT_INFO,
IOCTL_INTERNAL_GET_PARALLEL_PNP_INFO,
IOCTL_INTERNAL_PARALLEL_CONNECT_INTERRUPT, and the like.
Regards,
Spiro.
--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
Tim Roberts
>
>First,let me explain the situation : I have a special device that is
>connected to the parallel port(Using ECP or EPP) and I need to
>communicate with,use DMA(PC to the device) and IRQ under Windows
>2000/XP.
Impossible. The Windows parallel port driver (parport.sys) simply does not
support DMA. It discards the DMA channel number when it is given resources
by the I/O manager.
And that's a good thing. ECP DMA is stupid. You're talking about the old
ISA style DMA: 8 bit transfers, blocks no larger than 64k, buffer must be
in contiguous pages in the low megabyte of PHYSICAL memory, and it isn't
any faster than polled I/O.
Besides, HP is trying to extract booty from innocent folks by claiming to
have a patent on ECP DMA.
>For the moment, I have successfully used some I/O drivers to access
>directly to the port(PortTalk,DLPortIO...),but it seems to be in a
>dirty way(and I am not sure that I can use DMA),as these drivers are
>using some undocumented functions to LOCK/UNLOCK ressources,overriding
>the parport.sys driver.
They aren't undocumented functions. These products simply ignore the
presence of parport.sys. Parport doesn't do anything unless there is upper
driver actively using the port, so it doesn't particularly care that
someone else is dinking with the physical ports.
>For the moment,I am quite confused,because I don't know what is the
>best way to access to the parallel port.
>Must I write an UpperFilter driver for parport.sys that handle some
>custom IOCTLs?
>Must I write a parallel port class driver(Like parclass)?
That's the method I would recommend. That's what the 1284.4 drivers (like
parallel port scanners and such) do.
>I also heard that if It's also possible to remove parport.sys and to
>replace it with a "home made" driver,but I am not interested by this
>case cause I want to keep the parallel port working normally with other
>applications.
That's a good thing, but it means you cannot use DMA.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc
nassim.bo...@st.com
First,thank you for your replies.
I am currently developping a device driver that is a parport class
driver.
For the DMA, I get all the information using IoGetDeviceProperty,then I
use DMA_ADAPTER to take care of the transfert.
I have still two problems :
- IRQ connection is not working with
IOCTL_INTERNAL_PARALLEL_CONNECT_INTERRUPT (If I set
EnableConnectInterruptIoctl in DeviceParameters of the registry,the
driver crash when allocating the dma channel).The IRQ connection is
working with IoConnectInterrupt but I am not sure that It is good to
mix parport calls with custom IRQ management.
- DMA is working partially : I got all the control signals on the ECP
port,but it seems that data is not sent and that the IRQ is never
risen(I set up everything in Windows to allow IRQ on ECP port).
Any ideas?
Thnk you in advance.
Best regards.
Nassim.
Tim Roberts
>
>- DMA is working partially : I got all the control signals on the ECP
>port,but it seems that data is not sent and that the IRQ is never
>risen(I set up everything in Windows to allow IRQ on ECP port).
Are you sure? parport.sys really does not like to use interrupts.
Why are you going to all the trouble of overriding the IRQ and using DMA
instead of just passing buffers to parport.sys and letting it use the
method it prefers? ECP DMA is not faster than polled I/O. There is no
benefit. That's why parport.sys never uses it.
Nassim Bouayad-Agha
Finally,everything went well!
I finished my driver and It is now supporting DMA in ECP mode,using
some interfaces of parport.sys(Interrupt).
I prefered using DMA instead of READ/WRITES because It's much more
efficient for large buffers tranfers.
Thanks you all!
Nassim.
Tim Roberts
No, it isn't. That's why parport.sys doesn't even try to use DMA. It
takes a lot of overhead work to set up a buffer in the low megabyte of
physical space, lock it, and copy your data to it 32k at a time.
Remember that this is old-style 8-bit ISA DMA, not "modern" PCI
bus-mastering. It doesn't run at PCI speed. It runs slowly enough that
you don't gain all that much in net performance, certainly not enough to
make it worth the extra trouble.