> >The right way to do this is to write a parallel port device driver that
> >performs the operations you want, then call it thru the official
CreateFile,
> >ReadFile, WriteFile, etc, interface.
>
> But that slows everything done massively, this thread was about reading
> data via the parallel port being slow!.

There is no reason it needs to be slow.  I wouldn't want to pass individual
bytes with separate calls, but the app probably doesn't need that anyway.
The device driver should be able to deal with a buffer full of bytes at a
time.

Of course, if you really want to go fast you should:

1  -  Get a separate parallel port card that can do DMA.  This allows a
properly written device driver to maximize the speed with minimal CPU
overhead.

2  -  Don't use a parallel port.  I don't remember how many bytes/second the
original problem needed, but parallel ports can only go so fast.  After that
you could look into SCSI perhaps, althoug it's a lot more complicated.

A few years back a customer needed to get raw data in/out of an NT system to
a custom device.  We ended up using DR11W.  It's rather ugly, but that
didn't matter since it was all encapsulated from the end user's point of
view.  DR11W is very easy to interface to, and we got several MBytes/sec.  I
did have to write an NT kernel mode device driver for the card, but this
also proves that these things don't need to be slow.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olin@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads