Hello all, I'm attempting to create an IKit driver/family for DAQ
devices (specifically those from National Instruments), as well as a
user-space framework for data access, but I'm having some trouble
figuring out how to split the code among the various 'strata' of the
IKit. Here's my basic understanding of how this should work:
Driver:
DaqDevice ( base class for all daq drivers with virtual methods for
reading/writing registers and taking interrupts)
NIDaq : public IDaqDevice ( base class for NI daq devices with code
that can be shared among them for low level access )
xSeries : public NIDaq ( classes specific to different NIDaq cards )
User Client:
DaqDeviceUserClient ( base class for daq driver user clients, with
virtual methods for configuration, starting & stopping io)
NIDaqUserClient : public DaqDeviceUC ( base class for NI daq devices )
xSeriesUC : public NIDaqUC ( device specific methods )
User Application/Framework:
DaqDevice ( base class for controlling the drivers, with methods for
starting/stopping acquisition, pushing buffers into the UC and
retrieving data )
This seems to be the way the IKit documentation describes a proper
pci driver setup, but I have been totally unable to find any example
code that would show how to access this data properly from the
Application layer. I've found many examples on how to write PCI
ethernet drivers, but since they plug into lower levels of the IKit,
they don't help me much. The SimplePCIDevice drivers are laughably
simple, and have *zero* information on grabbing device or dma
interrupts, and there doesn't seem to be any other sample code that
does either.
Before anyone lectures me on using the mxBase drivers from NI, the
performance is far too low on SX for them to be usable in our
experiments. I created a mini-driver for e-series boards using the
mxBase methods (directly mapping the register space into userland) but
the sheer number of calls that cross the user-kernal bridge slows the
acquisition down significantly, plus, e-series drivers won't work on
G5s or MacPros, so we need to move forward with a PCIe driver for
m-series cards.
Does anyone have any good pointers or links which could send me in the
right direction for this project? at least any notes on how best to
'stratify' this project so I can keep it general enough to be expanded
in the future?
Thanks,
Rob Dotson
Vision Core Grant, NIH
New York University
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (Darwin-drivers (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com
This email sent to bsdarchive (AT) developershed (DOT) com

>Before anyone lectures me on using the mxBase drivers from NI, the
>performance is far too low on SX for them to be usable in our
>experiments. I created a mini-driver for e-series boards using the
>mxBase methods (directly mapping the register space into userland) but
>the sheer number of calls that cross the user-kernal bridge slows the
>acquisition down significantly, plus, e-series drivers won't work on
>G5s or MacPros, so we need to move forward with a PCIe driver for
>m-series cards.

Well the latest version works with PCIe and the M-series cards.

Register Level Programming of the driver should be fairly equivalent to the DaqDevice level in your scheme.

I have gotten megasample/second data acquisition working using M-series cards streaming with the LV interface. The raw C interface from user land should be a bit better.

I would be curious as to the requirements that need that many calls into the kernel to accomplish the functions of the M-Series Daq. But the pointer to Comedi is the best out there. Their drivers may have some features that you need.
-Scott

Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (Darwin-drivers (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com