I'm working strictly in C with nidaqmx on a Linux box with an NI-6534 (DIO) and am looking for example implementations of SPI. I've download some of the example code from the following but the "nidaqmx" examples are a bunch of VI's which I don't, er, speak.
Does anyone have any pure nidaqmx that implements SPI - or at least a "recipe" on how to set up burst mode, etc.?
Have you checked out any of the shipping examples in the NI-DAQ folder? There are several example types in the National Instruments\NI-DAQ folders for Text based programming. Also, the Text Based NI-DAQmx Data Acquisition Examples Dev Zone article may help as well.
Yes, I have seen the examples. They show how to do basic handshaking but not SPI. I expect hundreds+ of folks have done SPI with nidaqmx and was trying to not reinvent the wheel.
I believe that you will find this document helpful. It comes with some of our hardware that is more specifically designed for SPI but chapter 10 will give you details about the SPI API for C.
Thanks, but that is apparently a completely different API from NIDAQmx. I presume I can't use it with the NI 6534. The API is pretty opaque; it doesn't really give me hints of what to do in NIDAQmx.
I looked into this a bit and found some relevant information for you:
This forum thread you referenced does have discussion on page 3 which talks about the compatibility of the 6534 with the preexisting examples/reference libraries created for NI-HSDIO and NI-DAQmx. There are some obstacles to overcome with using these, since they based their DAQmx versions on the newer PXIe/PCIe-6535/36/37 cards. To quote notable posts:
"I literally JUST had the same exact problem with the 6534. If you look at the Serial Protocol Communication Reference Design for Digital Waveform Devices (http://zone.ni.com/devzone/cda/epd/p/id/6200), you'll notice that it has been updated to exclude the 6533 and 6534. Also the VI's have been modified to change the oreder of the event trigger and first write task. The 6534 does not support the data active. Another problem that you would probably run into is that usage of the ports are unidirectional. By that I mean each port can be input or output, but all 8 or 16 pins need be the same direction. ALSO, all 8 or 16 pins need to be used, which means they need to be tied to the task with dummy data. I had a couple NI guys helping me out to figure this out for my application, and the solution was to purchase a 6535/6/7 board.
If this is not an option for you, then the main problem that I could not solve was a way to synch the input and output tasks. In the "Init IntClk Device.vi", you'll notice that the Active Data event is used to trigger the input task FROM the output. We were not able to replicate this trigger with any event available on the 6534. An option was to trigger BOTH input and output tasks on a signal from a second DAQ board. We were having trouble doing this through the software or RTSI cable, but I don't believe we tried wiring an actual wire between 2 boards.
Time is a critiacl factor in my application, so the price of the 6535 is less than the risk of development time involved. I was able to get the VI's working perfectly on a 6537 though."
And as a workaround for Data Active Event replacement on the 6534:
"The 6534 does not support the Data Active Event (which was referenced earlier) so, you are correct in that you will need to use a data line to synchronize the two tasks. This can be done by appending a digital signal to the digital SPI waveform that contains a data high (1) in the beginning followed by enough zeros to match the length of the digital SPI waveform. Then you would need to route this signal to a PFI line to trigger your digital input task.
You can modify the digital signal in the SPI Close VI and using the Append Digital Signals VI. Remember though, if you add waveforms you need increase your channel count to account for this.
The example is built for the 6535/6/7 boards but you could try this out to see if you can get it working with your device."
I found more discussion about SPI and the 6534 here:
Unfortunately, we do not have a known base example that will start you up and running with the 6534 and SPI communication. It is to my knowledge that while using the preexisting examples tailored for the 6535/36/37 can be modified for the application, the method of modification is actually flexible based on an application by application basis, making it a little difficult to come up with a set example that will work like one would expect it to. Throughout the readings I've posted, overcoming line direction being port-configurable only instead of a per line basis, and synchronization without a hardware event on the 6534, will make adjustments to the program more tricky.
I apologize that we do not have more examples to start from, and besides the resources in the forums and the reference libraries, we will be more than willing to assist questions regarding functionality of the 6534 and how specific features on the device work, both in hardware and software. I wish the best of luck as you continue your development.
To continue discussion, you asked about using burst handshaking on the 6534 in C. I'm unaware if you have found this already or not, but for future reference we do have an example which also utilizes double buffering: http://zone.ni.com/devzone/cda/epd/p/id/634
The 845x software will not work for the 6534, but can still be utilized as reference material if you so wish to use it. However, it is very tailored to using our hardware that is specifically designed for serial/SPI communication.
There are a lot of VI's that have C equivalents, and please feel free to post here for explanations on VI's if you need them. DAQmx is very good at making C functions have very similar names to VI's used in LabVIEW. If you reference the help manuals for both Programming C in DAQmx Base and Programming LabVIEW in DAQmx (previous link explains where to find the help on your machine, and the LV references reside there).
A final comment on the reference library you posted. The functionality of it is not to program the hardware, but to correctly organize the waveforms that you can generate via SPI. Looking at your previous responses, it is not clear whether you wanted guidance on hardware configuration or waveform creation, or both. Let us know how we can help further, thanks.