I used a updated the portio sample ddk driver to try and communicate
with the LPT port hardware directly. The driver only works when the
Microsoft Parallel port driver is installed at the same time. Do I
need to configure the example driver as a parallel port driver and
install in place of the microsoft driver if I want a stand alone driver?
-Rick
I haven’t noticed a recent response to this, so I’ll offer this (I think some of it was said earlier, tho):
I used to do a lot of little parallel port projects for people who had interesting or quirky one-off communication protocols on the port.
This works best if you work with the system support, rather than trying to replace it.
The DDK documentation and samples provide good basic information here (or at least it was enough for me to muddle through the process in those days).
Basically, you open /device/parallel (n usually being 0) to access the port’s arbitrator device (port device, if you prefer). It has a variety of KM-only IOCTLs allowing you and all the other protocol drivers that may need to use the port to coexist without walking all over the state of the port each of you wishes to control. There are then a set of internal I/O control codes you can use to acquire exclusive use of the port, establish a general operating mode (vis-?-vis ECP, EPP, etc), get all the I/O addresses for the legacy port registers and any additional ECP registers, even connect an interrupt handler.
If you look at the section on parallel ports, and particularly IOCTL_INTERNAL_GET_PARALLEL_PORT_INFO, IOCTL_INTERNAL_PARALLEL_PORT_ALLOCATE and associated structures, you can probably figure out what I’m getting at. After acquisition, you should also use IOCTL_INTERNAL_PARALLEL_CLEAR_CHIP_MODE to leave the port in IEEE-1284 compatibility (aka “the way the parallel port always used to work”) mode. I say that last because that’s usually the mode all these custom protocols typically are designed for (where you’re using register access to wiggle the data, control, and status lines in some unusual way).
One advantage to this is not having to try to figure out plug-and-play configuration issues wrt the port. Another is that you have a lot less trouble coexisting with all the dongles and other gear people are always expecting to be able to seamlessly use along with whatever device it is you are trying to control. I wish I could say it is perfect, but most of the time, you eventually run into some product somewhere that simply couldn’t abide by this or misused it (say by acquiring and never releasing the port, or better yet, doing exactly what you are proposing, and thus making it impossible for anything else to be done with the port). Or into some device whose unique protocol interferes with yours in some way…
In spite of the mini-rant (and bad memories of how a task so seemingly simple can go awry), there are markets where you really do not want to coexist, or at least bosses and marketing departments who insist upon it being of no priority. So if you are in this situation, I’d suggest you still consider whether not having to support the Pnp issues is enough still reason enough to go this route.
If not, then the parallel port driver code is in the DDK, and should show you how it gets the port set up so that you can combine that with your protocol-specific stuff and make a replacement driver.
I might be able to help with more specific questions later, if needed, but I have to warn you I haven’t been in the details of it in at least 5 years. I fear I’ve got a well-demonstrated tendency to get the details all muddied up and confused after a lot less idle time than that (which is why I waited for someone better-prepared to offer something first).