Reading from parallel port via ECP and DMA

NTDEV
1

Hello,

I am trying to set up a simple digital data acquisition via the parallel port. The idea is to sample the inputs at regular intervals. The problem here is the word “regular”. The application calls for hardware timed data acquisition.

At first glance this sounds like a case for inpout32.dll and using the inp32 function. However, this would be a software timed data acquisition: I have only very little control over exactly when the data are read from the port.

My idea is to make use of ECP and the DMA capabilities of the port.
See for example here:

http://www.beyondlogic.org/ecp/ecp.htm

The handshake is easy to fake. And the PeriphCLK pin would simply be conntected to a constant clock at 10kHz. This would make the port read the data at 10kHz and the DMA would take care to copy the data into memory. I could be certain that the data are sampled with no jitter.

This is the idea. The problem is how to get it to work.

At first I thought of using CreateFile to open the port and then ReadFile to read from it. The problem however is that ReadFile does not work with the parallel port. Apparently, parport.sys has not implemented this functionality.

Then I searched the Internet high and low and the best I could find was the use of inpout32.dll and similar libraries which do not help or the recommendation to use ReadFile which does not work. Alternatively, there are a few rather expensive realtime solutions which seem to be way overpriced for the simple thing I want to do.

Isn’t there a standard solution for reading data from the parallel port? How do scanner drivers do it? They also have to transmit large amounts of data via the parallel interface, surely there is a solution for that?

The system runs WindowsXP and this would be for c/c++.

Thanks in advance for any help you can provide.

Marcus

2

xxxxx@siemens.com wrote:

I am trying to set up a simple digital data acquisition via the parallel port. The idea is to sample the inputs at regular intervals. The problem here is the word “regular”. The application calls for hardware timed data acquisition.

At first glance this sounds like a case for inpout32.dll and using the inp32 function. However, this would be a software timed data acquisition: I have only very little control over exactly when the data are read from the port.

My idea is to make use of ECP and the DMA capabilities of the port.

Bad idea. Parport.sys does not support DMA for parallel ports at all.
It completely ignores the resource, because the performance is always
worse than polling. If you were to use it (and I recommend you do not),
you would have to write your own driver to replace parport.sys.

The handshake is easy to fake. And the PeriphCLK pin would simply be conntected to a constant clock at 10kHz. This would make the port read the data at 10kHz and the DMA would take care to copy the data into memory. I could be certain that the data are sampled with no jitter.

I think you are dramatically overestimating the capabilities of
ISA-style DMA. You can’t just set it up as fire-and-forget like this.
It requires as much care and feeding as a polled solution.

What are you hard requirements? Does it matter exactly when you read
the data? That is, if you poll at 12ms then 8ms then 13ms then 7ms, do
you get different results than if you poll exactly 10ms?

If so, then you cannot implement a software solution. Allow me to
recommend an alternative. You can get a Cypress FX2 experimenter’s kit
from a company called QuickUSB. That would allow you to gather the data
in firmware in hard real-time and shove it in a FIFO, which you could
read at your leisure via USB.

If you want, our company could help you craft a solution.

Isn’t there a standard solution for reading data from the parallel port?

Sure, but not real-time.

How do scanner drivers do it? They also have to transmit large amounts of data via the parallel interface, surely there is a solution for that?

Scanners use a kernel-mode driver sitting on top of parport.sys, but
scanners are not timing dependent.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Hi Tim,

thank you very much for your reply.

What are you hard requirements? Does it matter exactly when you read
the data? That is, if you poll at 12ms then 8ms then 13ms then 7ms, do
you get different results than if you poll exactly 10ms?

Jitter is not allowed, I really do need to read the data at the exact times.

But reading through your reply and digesting its main points I think I begin to see where I made a mistake: When I looked at the ECP handshake I just saw that the data are read at the moment of the positive edge of the PeriphCLK signal. Thus, I thought that I have a guaranteed read time. The problem is that the read cycle is initiated by the host via the nReverseRequest signal. If the DMA is not ready, this can take forwever and thus I would lose many cycles.

My idea would probably work much of the time, but also fail in many cases.

Best regards,
Marcus