Re: general purpose driver for Printer Port?
- From: "David Craig" <drivers@xxxxxxxxxx>
- Date: Mon, 16 Jun 2008 12:16:56 -0700
I would consider using a filter on the standard parallel port driver since
it is rather difficult to replace the Microsoft released version. Let the
standard version handle the hardware and have the filter maintain a request
for data it places into its buffers holding on to them until requested. You
could grab the port exclusive and keep other programs from accessing it
directly if you had a root enumerated driver of your own that your software
opened. It would not be a filter in that case, but a pseudo parallel port
driver that only your programs would know about.
I think that covers the two possible options I can think of and may give you
what you need. Switching your hardware to use USB may be the best solution
overall since it is a much faster buss and can handle PnP much easier. I
think there is a parallel port enumerator to create a form of PnP, but it is
legacy hardware and doesn't really support true hardware based PnP.
"anonym" <anonym@xxxxxxxxxx> wrote in message
news:3tx5k.33446$gc5.3065@xxxxxxxxxxxx
Has anyone ever seen/heard of a general purpose driver for PC Parallel (
ie. Printer ) Port?
It would do some or all of the following:
1. Respond to interrupts (ACK line on pin 10) so that synchronously with
the outside world, it would pass data/status register values to/from a
memory buffer. Separate buffers for INPUT and OUTPUT of course.
2. In addition to memory buffers for register values, another set of
similar buffers holds timestamp values (performance counter) captured
along with each interrupt. Separate timestamp buffers for INPUT and
OUTPUT of course.
3. Also on the wish-list is to provide some event notification when
buffers were full, 1/2 full, empty; or alternately it could be a circular
buffer, in which case events can be set-up to notify at regular buffer
index step multiples.
4. The timestamp buffer values can either be directly synchronous to
interrupt trigger; or they can be asynchronous, in which case the driver
actual waits the time period specified by the buffer value, before it
either outputs or inputs port data values. A "mode selection" makes this
available.
5. Could these buffers be available to both kernel driver and user
application transparently, so that program interaction approaches
real-time?
This would be quite useful for doing direct hardware interfaces and/or
control applications with a PC running windows, as it would bypass the
usual requirement to purchase expensive DAQ hardware/software. For data
stream say up to 1Mhz, simple acquisition/generation of both Time and
Frequency domain signals become possible. Perhaps even some simple
control loop processing too!
Is this too much to ask from a Device Driver? Any pit-falls or gotchas
that could arise?
I would even settle for a Driver that captured INPUT only as long as it
was an interrupt driven sequence of data and timestamp values dumped into
a buffer.
If this wonderful general purpose Driver does not exist, does if have to
be kilo $$$ to contract someone to write such a driver for 32bit Windows
XP ?
Does the "Device Driver" community post/share various examples anywhere?
Maybe I can find something close to what I need and modify it myself.
~anonym
.
- Follow-Ups:
- Re: general purpose driver for Printer Port?
- From: anonym
- Re: general purpose driver for Printer Port?
- References:
- general purpose driver for Printer Port?
- From: anonym
- general purpose driver for Printer Port?
- Prev by Date: general purpose driver for Printer Port?
- Next by Date: Re: general purpose driver for Printer Port?
- Previous by thread: general purpose driver for Printer Port?
- Next by thread: Re: general purpose driver for Printer Port?
- Index(es):
Relevant Pages
|
