Hi Robert --
You might take a look at http://www.comedi.org/ , which is an open
source driver project that includes support for e-series devices (and
maybe m-series now?).
If you do write your own driver, there are a variety of ways to lay
out the project, including the way you have specified below. I have
written a couple of custom drivers for these boards, and the model I
have settled on is:
DaqUserClient -- only one -- it includes all functionality needed for
all devices.
DaqDriver -- core driver class
DaqESeries -- subclass of DaqDriver, supports all Eseries devices
DaqMSeries -- subclass of DaqDriver, supports all M series devices
For the differences in boards, like acquisition speed, number of Aout
channels, etc., I include those as parameters in the IKit
personalities for each board type. Those values can be accessed and
used by the "series" driver class to customize its operations, and
can also be accessed via the user client.
I haven't set up DMA for NI boards (haven't needed it for these
projects), but it should be pretty straightforward once you have the
rest of the driver in place.
Then, I have a framework library that manages all of the user-space
IKit matching and loading, creating threads to receive data on,
etc. So the applications that use the devices do it via a nice
clean interface.
Writing code for M-series is a pain, because there is still no low-
level documentation available. However, M-series is so close to E-
Series in operation, that you can use the E-series docs for much of
it. Also, the guys on
are very responsive to specific questions/problems.
Scott Gillespie
http://www.appliedbrain.com
Message: 3
Date: Tue, 6 Feb 2007 14:42:49 -0500
From: "Robert Dotson" <robert.dotson (AT) productofbrooklyn (DOT) com>
Subject: IKit PCI Drivers/Frameworks
To: darwin-drivers (AT) lists (DOT) apple.com
Message-ID:
<@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
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
--
Darwin-drivers mailing list
Darwin-drivers (AT) lists (DOT) apple.com
End of Darwin-drivers Digest, Vol 4, Issue 22
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