Generating SPI using PCIe-6535B

[PeterRQ]

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!

[Marshall_B]

Hi PeterRQ,

From what I understand, the problem boils down to whether you can produce 96 SPI clock cycles before the next data ready signal is sent after 100 us.  The PCI3-6535B can output digital signals at 10 MHz meaning the shortest amount of time taken to output a digital signal is 0.1 us.  

Given that you want to produce 96 SPI clocks and that each digital signal will take 0.1 us, the total time taken would equate to 9.6 us.  Based on these figures you should have no problem with outputting the 96 clocks within 100 us.

You may also find the following information useful:

Understanding the SPI Bus with NI LabVIEW

SPI Digital Waveform Reference Library

[PeterRQ]

Hi,

Yes, the device can stream bits at 10MHz once the device is being driven.

There is then the question of latency.

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.

So what I am really trying to understand is if this device (or any other) may be programmed to create the 96 bits as a pure hardware determined response to a hardware detected condition (the DRDY pulse) and so avoid software latency issues. This would also require that the device may buffer the 96 MISO bits generated by the device under test.

[Marshall_B]

Hi PeterRQ,

Thank you for clarifying that for me.  

You are correct in thinking that you need to program the device using a real-time version of LabVIEW.  LabVIEW running on a Windows operating system can only operate on a ms timebase, whereas a Real Time operating system will allow you to use a us timebase.  

Let me know if this helps.

[PeterRQ]

Hi,

Just to clarify.

Are you saying that there is not an NI hardware based solution i.e. a bit of NI hardware that may be programmed to generate and capture a bit stream on test conditions being met?

I found https://www.ni.com/docs/en-US/bundle/pxie-653x-pcie-653xb-specs/resource/pxie-653x-pcie-653xb-specs.... but it is not clear to me what this devices capabilities are.

It seems that the device would be capable of asynchronously buffering MISO data with a 2048 sample buffer.

I did not understand the "Triggers" section though.

There seems to be an option to trigger the "Sample Clock" but the manual is not clear.

If I can trigger clock generation for a period of time then it looks like the 2048 sample buffer would be adequate to hold data until Windows gets round to checking.

I want to be sure before I go down the LabView RT road.

[Marshall_B]

Hi PeterRQ,

I have had a further look into this for you and have found out that it is possible to code our hardware to run SPI communications but there are a particular set of 

tools which need to be used.

For example, have you seen the NI USB-8451?  This device uses its own API to code for SPI communications.

I have also found information on our SPI Digital Waveform Reference Library which can be used to program any hardware timed digital I/O device.  Going back to the original question of coding for the PCIe-6535B, you could use the digital waveform library to program the device.

Let me know if this helps

[PeterRQ]

Thanks,

Yes there are libraries that perform SPI functions. I could also bit bang.

The core problem remains latency which I found no mention of in the references.

Given that VIs were involved in the SPI clock I can only assume that the examples are software constructs and therefore latency will be an issue.

Perhaps if I drop 'SPI' from the question and pose the problem as this:

On detecting a high to low transition how may I start to generate 96 clock (approx) 1MHz pulses (starting within 20 uS of event) and capture the state of a digital input line synchronous with the generated clock.

I could even use a stand alone clock source gated in some way if that helps.

Originally the question was could the PCIe-6535B be pre-armed to react this way.

I am looking for references which I can double check, understand and synthesize.

[Marshall_B]

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.

[PeterRQ]

Hi,

Thanks that's helpful.

I understand what you are saying.

The DAQ hardware may be programmed to generate the clocks & capture the input bits using oversampling, say >= x4 for SPI.

In software I may create events by enqueing the hardware data & process in another task.

This would give me a system that can withstand up to 5 event delays in the enqueing section (2048/(96*4 )) and virtually any delay during the decoding/processing.

Finally, would the enqueing process run as part of the driver's context or as a Window's task?

The process in continuous (the ADC initiates the transaction, the data ready event) & it is important not to loose data or an the event itself.

[Marshall_B]

Hi PeterRQ,

The enqueuing part of the process happens as a Windows task and will enqueue as many elements as you need from the DAQmx Read function.  There should be no latency issues with this part of the code, so long as the DAQmx Read function grabs all 2048 elements from the hardware buffer.