AI DMA Transfer for E Series

[Dave Humphrey]

Is there, or will there be, any DDK support for DMA transfer of analog inputs for the E Series boards? I found a recent message concerning DMA transfer for M series but nothing related to E series.

I'm using a PCMIA DAQ 6036E card on a WinCE device (Inhand Elf3). Playing with the DDK analog input examples I found the maximum sample rate I could achieve was 10 kS/s. Narrowing it down further it seems that each register read (ie: theSTC->AI_Status_1.readRegister()) takes around 50 microseconds. This means that that each polled input used in the examples takes 100 microseconds which limits the sample rate to 10k. Since I need a sample rate of 80k minimum this obviously won't work.

I believe my options are:

1. Use interrupts to read the entire FIFO buffer when full (1024 samples)
2. Use DMA to read the entire FIFO buffer

I looked into implementing an interrupt method but it seems to be realtively more complex than the DMA example for the M Series board. It may well be faster to use any available DMA code for the E-series, or even port it from the M Series, than to create an interrupt handler under WinCE.

[Dave Humphrey]

Some updates:

1. Is it even possible to use DMA access for the analog inputs? The DAQ STC and register level documentation don't have anything explicit. They mention DMA access in passing but not actually how to do it.
2. Interrupt access may not actually help much in exceeding the 10kHz limit. You still have to read the FIFO sample by sample which still has the 50 microsecond per read time limitation. This would push the maximum limit to 20 kHz on the current system, still not anywhere near enough.
3. Our previous system used register level programming on the DAQCARD-AI-16XE-50 but with direct calls using DeviceIOControl(). The data input portion would simply read the entire FIFO buffer at once, for example: 
   

Handle = CreateFile ("DAQ1:", ...);
...
DeviceIoControl(Handle, 0x06, &GetDataInfo,  sizeof(GetDataInfo), &OutputBuffer, 2048, &BytesReturned, NULL);

I cannot find any documentation regarding this call on the NI site nor can I find any equivalent call in the modern RLP/STC register level DDK for the DAQ-6036E. I'm assuming that this accesses a driver or some sort similar to the RPL driver, I just need to find the source/documentation for it.

[DiegoF]

Hi Dave,

PCMCIA does not provide standard DMA support.  It's a limitation of the bus.

The main problem is that every register IO goes thru a DeviceIoControl call.  Every time a DeviceIoControl call is made, there's a context switch from your application to the driver and back.  This is inefficient.  Tipically drivers implement the IO on the driver side and provide an API the applciation can use to program the device.  For example, you can have a configure function called by the application that performs all the device configuration.  Some of the reasons why MHDDK is implemented this way are:

- In order to keep the examples as OS independent as possible they are implemented in user mode.  The kernel driver only needs to provide access to the hardware, which usually means a simple OS-specifc driver.  Keeping the kernel driver simple makes it to port or create from scratch to port the MHDDK examples.  Also,  the examples can focus on illustrating the device programming.

- PCI devices are memory mapped.  If you look at the resources of a PCI device in the Windows Device Manager you'll see "Memory Range" resources.  These address spaces can be mapped to the user application.  Once the memory is mapped the application can communicate directly with the hardware using memory IO (pointer accesses), which is very fast and doesn't cause an user-kernel transition.  

- NI PCMCIA devices use IO space (IO Range in the Device Manager).  On x86 processors this means that access to the device is done using another set of assembly funcions (port IO).  PCMCIA IO space cannot be mapped.  To keep the same PCI example the driver provides functions to do the IO on behalf of the application.

The best way to improve performance is to move part of the example code to the driver.   This is essentially option 3 on your list.  You would be writing your own driver, or at least some support functions.  For example, a new Io Control code would be used to read from the FIFO.  The code in the example used to read the FIFO would be moved to the driver side and the application would call DeviceIoControl to request a number of samples.  The loop that queries the FIFO and puts the data in the buffer runs on the driver side.

Hope this provides a starting point.  Let me know if you have any questions.
DiegoF

[Dave Humphrey]

Thanks for the explanation. It turns out a custom driver was actually written that has all the register level DAQ code so it all makes much more sense now. Unfortunately the project documentation did not refer to the driver's creation and its source code was 'hidden' until I dug it up so I was in the dark for a while there.