Can you produce arbitrary TX data with the USB-8452 in SPI Streaming mode?

[jskroch]

I am using an NI USB-8452 controller in SPI mode, controlled by a C program compiled in LabWindows/CVI 2013. In order to talk to the chip we've designed, I need to control the delay between the final deassertion of SPC and the deassertion of CS (timing parameter T11) to keep it very small. Therefore, I'm using streaming mode.

I've read the NI-845x Hardware and Software Manual and looked at the two projects that use SPI streaming mode in the NI-845x examples dir. The examples are both using SPI to talk to A/D converters. In other words, the time-varying data is coming from the SPI slave (ADC) to the SPI master (NI 8452 controller) via the SPI_MISO line.

Is it possible to use the USB-8452 to generate time-varying data that goes the other direction, from the SPI master to the SPI slave via the SPI_MOSI line? Can I do a burst write of arbitrary length using streaming mode?

For example, let's say I have 8 bytes of data to transmit:

WriteData[] = {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08};

If I try to send this as 4 16-bit samples:

ni845xSpiStreamConfigurationSetNumBits(StreamHandle, 16);
ni845xSpiStreamConfigurationSetNumSamples(StreamHandle, 4);
ni845xSpiStreamConfigurationWave1SetMosiData(StreamHandle, WriteData, 8);

ni845xSpiStreamStart(DeviceHandle, StreamHandle);

I would expect to see transmitted:

0x0102
0x0304
0x0506
0x0708

Instead, what I actually see is the first word repeated NumSamples times:

0x0102
0x0102
0x0102
0x0102

Is there any way to generate the first (non-repeating) pattern? Or is streaming mode really only capable of capturing input data?

I thank you for any help you can provide.

-jskroch

[jskroch]

I should add: I'm using NI 845x Device Driver version 2.1.2f.

This is one version back from the latest, but the newer version 14.0 does not have changes that I think would be relevant.  The release notes say only that version 14.0 adds support for a newer version of LabWindows and fixes two unrelated bugs.

-jskroch

[tcap · Accepted solution]

Hello jskroch,

I have looked through the documentation for the NI-845x and it does confirm that the streaming functionality outputs the same MOSI data for each SPI operation during streaming.

You can use the ni845xSpiWriteRead function to write an array of bytes sequentially using 1 function call.  These bytes can be configured to your specified waveform.

Regards,

[jskroch]

Hi Thomas,

Thanks for the info. Based on my experiments, that's the conclusion I had come to as well, but it's good to get confirmation.

My work around is to break every TX transaction into small pieces. The NI 8452 supports streaming sample sizes of up to 64 bits (8 bytes). I can make a transaction that is one sample long with "samples" of 4, 6, or 8 bytes, as needed. Continuing my original example, I can do this:

NumBytes = 8; 
ni845xSpiStreamConfigurationSetNumBits(StreamHandle, 8 * NumBytes);
ni845xSpiStreamConfigurationSetNumSamples(StreamHandle, 1);
ni845xSpiStreamConfigurationWave1SetMosiData(StreamHandle, WriteData, NumBytes);

ni845xSpiStreamStart(DeviceHandle, StreamHandle);

And I see this transmitted:

0x0102030405060708

You can repeat the SetMosiData and StreamStart steps for each additional block of TX bytes.

I would like to use the ni845xSpiWriteRead() function (that would be much easier), but that doesn't work with the broken pre-production SPI slave I need to talk to. (We will fix it, but I need to work around the problems for today). I need to generate a very small delay at the end of the transaction between when the serial clock stops and when CS deasserts, or else my transaction is ignored. I measured the delay between SPC deassertion and CS deassertion produced by ni845xSpiWriteRead() at 1.19 us. In order to talk to my broken SPI slave, I need a much shorter delay, on the order of one SPI clock period.

So yes, I hope to upgrade to the basic SpiWriteRead function in the future, but I can't use it today.

Thanks for your help.

-jskroch

[tcap]

Hello,

So from what I understand you are looking to reduce the time between the end of the clock pulse train and the deassertion of the CS?

How much time are you looking for?  The delay you measured is a hardcode property of the device and cannot be altered.

You might be able to implement your desired waveforms on DIO pins of the device, but the clock speed would be greatly reduced.  This can be done using the SPI scripting API.

Regards,

[jskroch]

---

@tcap wrote:

So from what I understand you are looking to reduce the time between the end of the clock pulse train and the deassertion of the CS?

---

Yes, exactly.

---

@tcap wrote:

How much time are you looking for?  The delay you measured is a hardcode property of the device and cannot be altered.

---

I'm looking for a delay on the order of 100 ns or less.  I measured this T11 delay at 4.78 us with the scripting API and at 1.19 us with the basic API, both of which are too slow.  I am able to produce an acceptable 60 ns or less with streaming mode.

The shortest period I could produce while toggling a GPIO was 630 us, which is way too slow.  Although admittedly, that was using the basic ni845xDioWriteLine() function not the scripting ni845xSpiScriptDioWriteLine() function.

So the only case that works for me is streaming mode.  I know I'm using it in a way it was not designed to work, but at least I do have a functional solution now.

Thanks again.

-jskroch

[tcap]

You're welcome.

I am glad I could help.

Regards,