IRQ with NI PCI-6534

[luk51000]

I'm basically doing:

DAQmxErrChk (DAQmxCreateTask("mosi",&mosi));

DAQmxErrChk (DAQmxCreateDIChan(mosi,"Dev1/port0/line0","MOSI",DAQmx_Val_ChanPerLine));

DAQmxErrChk (DAQmxCfgDigEdgeStartTrig(mosi,"/Dev1/PFI2",DAQmx_Val_Rising));

DAQmxErrChk (DAQmxCfgSampClkTiming(mosi,"/Dev1/PFI6",5000000.0,DAQmx_Val_Rising,DAQmx_Val_FiniteSamps,1000));

DAQmxErrChk (DAQmxReadDigitalU32(mosi,1000,DAQmx_Val_WaitInfinitely,DAQmx_Val_GroupByChannel,s.data,1000,&s.sampsRead,NULL));

DAQmxErrChk (DAQmxRegisterDoneEvent(mosi,0,callback_function,&s));

This possibly would work fine if DAQmxReadDigitalU32 was to set the task to read when started, then the callback_function would deal with the communication protocols and all and everything would be event/interrupt-oriented. But DAQmxReadDigitalU32 forces the task to start right away.

How could inform the task I want to read but only when I (or the trigger) start(s) the task?

[mudson]

Hello luk51000,

I've been playing around with some things on this end.

A retriggerable task would work nicely here.  Unfortunately, the card you have doesn't support retriggerable triggers.  Right now, it is looking like your best bet will be to start the communications task when SS goes high, and stop it when SS goes low.  This puts us back in a spot where we're having to burn up cycles reading that line on a more regular basis.  We can still use a trigger to start the read, but starting and stopping the task will take some additional coding.  Repeatedly starting and stopping the task will also inflict additional processing overhead.

National Instruments does have SPI libraries, but they are currently only available for use in LabVIEW.
SPI Digital Waveform Reference Library

Another thought:

Monitor the SS line with a DAQmx task.  When the line goes high, stop the DAQmx task and make the callback to the SPI communications functions.  Then start the DAQmx task again when the SPI exchange has finished (assuming SS is low again).

[luk51000]

Just found the trigger would need to be activated with 400 Hz. Do you think destroying and creating a task (+ setting everything) would take too long?

From what I observed until now, the processor usage when using triggers is much lower than when using polling (note that power consumption is also a limitation).

[mudson]

Are you needing to trigger 400 times per second, or just using a 400Hz signal as a trigger?

Starting and Stopping a DAQmx task is kind of the "nuclear option" from a resources point-of-view.

The DAQmxstart verifies, reserves, and commits hardware resources before starting the task.  The stop kicks those resources all the way back to an unverified state.  If you are planning on running the entire routine at 400Hz, the DAQmx start and stop will certainly limit the number of times the code will actually be able to execute.  Using the start and stop commands helps keep the code simple though.

(for some additional background on how DAQmx handles the resources, search NI-DAQmx Help for task state model)

A less severe, but more involved option is to use DAQmxTaskControl to step through the stages of resource reservation, and then unreserve the resources without unverifying them when you're done using them.  The inital task reference and the associated settings should still be useable.

I usually use DAQmxTaskControl when multiple measurements have to share the same resource, and starting and stopping creates too much downtime between measurements.  A measurements benchmark VI I ran demonstrated that, for 1000 iterations, the task control method took 5s less than using Daqmx Start and Stop.

I anticipate that since power consumption is an issue, your code is already pretty lean.  As far as whether or not using DAQmxStart and DAQmxStop will take too long, from this side I can't really say — that will depend on how quickly things execute on your platform, and what your specific needs are.

[luk51000]

Well, both. I'm using a 400 Hz signal to trigger the system, so the software trigger would need to be ready 400 times per second (or faster).

For now, everything is running fine. I'll keep in touch in case the requirements change and we need a new solution.

Thanks for all the help!

[luk51000]

Hi Matthew

I'm not sure where to ask this, but I ran into some very weird problem using this card. The card was transfered to a Windows machine for some time and when we transfered it back, it didn't work. All the example programs insist on exit with no message error ("DAQmx Error: " and "End of program, press Enter key to quit"). We tested it again on windows to see if it was a problem with the card, but it works perfect on LabView. Do you know what might be happening? The linux OS was not changed at all since we first talked.

[mudson]

Welcome back!

Since the card was taken out of the *nix box and then put back in, it is possible it is now being associated with different PCI resources - or it may just have a different designation.  If the card information and location are hard-coded, this is a possible cause of the errors you're getting.

What kind of output do you get from lsdaq?

What happens when we try to communicate the card with one of NI's shipping examples?

[luk51000]

Since the card was taken out of the *nix box and then put back in, it is possible it is now being associated with different PCI resources - or it may just have a different designation.  If the card information and location are hard-coded, this is a possible cause of the errors you're getting.

- What does this mean? Is this reversible? Is this something MAX could have done by itself?

What kind of output do you get from lsdaq?

What happens when we try to communicate the card with one of NI's shipping examples?

- I searched all around and couldn't find the lsdaq. Also, the error (if we can it that) was from running the NI's examples.

[mudson]

MAX doesn't associated hardware with PCI resources - that is a process that typically occurrs before the OS is brought all the way up.  All MAX does is provide a means of interacting with NI hardware.  The modifications typically made to hardware from MAX are limited to calibration constants.

As far as I know, we don't have MAX available for Linux installations, so we provide the lsdaq function (to be called in a terminal) to provide a list of the NI hardware that is present in the system.  You should be able to enter that into a terminal session, and a list of NI hardware attached to the system will be displayed.

It is possible that the card is no longer using the same resources on the PCI bus that it was using last time.  If that is the case, it may have a different identification on your Linux workstation.  If the reference to the card is hard-coded in your program, that will need to change in order to communicate with the card.

What version of the DAQmx (or DAQmxBase) drivers do you have installed on the Linux workstation?

[luk51000]

The lsdaq is not present on my system. I'm about to reinstall to see if it shows up. lspci shows the card, but nilsdev still can't find it.

It's unlikely we changed pci slots. There's was only one pci protection taken out, and it has been like that since the card was first placed.

The version of DAQmx we're using is 8.0.2.

I'm starting a new thread about this new issue.