Generating SPI using PCIe-6535B

Question

Hi,
I have a data ready signal generated every 100uS or so by a SPI slave.
The SPI master must then generate 96 SPI clocks anhd capture the returned data.
The process is repeated every 100uS. The 96 SPI clocks must be completed before the next event hence the need for a ardware or RT system.
Would it be possible to program the PCIe-6535B to act as the SPI master i.e. to generate the clocks, store the data such that a Windows LabView program may reliably pick up the data without loss?
Or am I looking at something more like a RIO?
References & code examples would be great!
Solved!
Go to Solution.

Answer 1

Hi PeterRQ,
There should not be any latency issues when running SPI communications on your PCIe-6535B, provided that the application has been programmed sufficiently.  
Looking at a simplified situation whereby you are only looking to set up a digital input/output task for the PCIe-6535B, with no need to process the digital data you receive back, the device can be programmed to execute 96 clock pulses within the desired 100 us.  Software latency would not be an issue, since the DAQ card will continue to execute its pre-programmed functionality (using the DAQmx driver) until the program is stopped. However, I suspect that you wish to process the data in some way and this can cause issues if not correctly coded for.
In order to acquire your data deterministically while still being able to process the acquired data, I would use a Producer/Consumer architecture (in LabVIEW 2012 go to File >> New... Producer/Consumer Design Pattern (Data)).  The producer loop could be used to  acquire data and the consumer loop could be used to process the data.  You will need to avoid running large amounts of data processing code in the producer loop of your LabVIEW code as this will inevitably slow down the execution of the DAQmx read function and as a result will mean the buffer (2048 Samples) could overflow.
Going back to an earlier post, you asked:
"If the PCIe-6535B requires that the LabView software makes some decision before the 96 bits are sent then this problem boils down to the reaction speed of the LabView software. If software latency is the involved then I would imagine then that I would have to get a real-time version of Labview."
Using the Producer/Consumer architecture,  LabVIEW itself would not require any more processing inside software other than the enqueueing of an array of your input data.  Everything else is handled by the device driver, which in this case is DAQmx.  The limitation here would be the CPU you are using to interface with the drivers.
A real time system could be used to ensure greater determinism on the processing side of your application although this is not necessary.
Our Serial Protocol Communication Reference Design for Digital Waveform Devices tutorial page includes examples of how DAQmx can be used to code for SPI communications on the PCIe-6535B.  If you download the "serial_wfm_1_0_1_lv86.zip" file, you will have the option of running the "DAQmx SPI - Internal Clock.vi" example VI.  This example VI first builds an SPI waveform and then sets up your DAQmx task to output the digital waveform.  You should find this useful to look over and incorporate into the Producer/Consumer architecture of your code.
Let me know if this helps.
Marshall B
Applications Engineer
National Instruments UK & Ireland