NI-845x SPI Stream API

[mje]

Has anyone had any luck using the NI-845x SPI Stream API? I've been spinning my wheels in the mud for two days now.

The example that NI ships appears to be specific to the 8452 device, or at least it doesn't appear to work on the 8451, which is what I have. Getting even the most simple exchanges to work fail miserably.

"Error -301713 occurred at NI-845x SPI Stream Start.vi. Possible reason(s): NI-845x: An input parameter, or combination of parameters, is invalid."

Awesome, thanks for the info.

Does anyone have a functional example I can learn off of? I know this is a long shot, but I thought I'd try here first before heading over to the dark side. I've called NI support, and about all I got out of it is it "should" work. Well, I agree, but reality seems to be getting in the way of theory...

Note I can get the higher level APIs to work, but they won't work for my application. I need finer control over timing delays than the other API provides.

[mje]

I was contacted via PM about this thread, so I'll post a follow-up here.

The short answer is I was never successful getting the stream API to work on the 8451. It does work though on the 8452, however wasn't of much use to me either since it's limited to something like 24 or 32-bit data lengths and I had a 96-bit data frame.

So in the end, I fell back to the 8451 and use the higher level functions, reading 8-bits at a time. This introduced an irregular waveform in that I have a pause in my serial clock every 8-bits, but the device I was interfacing with was tolerant enough to not have a problem at the waveform.

Overall I'm not too impressed with the SPI devices, and would rather implement everything on an FPGA, but that wasn't an option for this project.

[asbo]

The stream API is not supported on the USB-8451 - I don't remember exactly where I read this, but I'll try and find it for documentation's sake.

I'm actually using the USB-8451 right now (and might be moving to the USB-8452 for the higher clock rate), but I'm happily using 8-bit transfer sizes. I haven't scoped my clock to see what it's doing, but I'm reading and writing 256 bytes arrays at the speed I expect. Perhaps if you use the scripting (it's on the advanced palette), you can control the clock better. I didn't see any immediately benefit to using scripting so I never looked into it - seemed a little heady to try and set up, though there may be examples.

The documentation they have on these devices and toolkit (NI-845x Hardware and Software Manual) is pretty meh - the hardware descriptions between the 8451 and 8452 are pretty inconsistent, for one (for example, the USB-8451 doesn't list a transfer size at all).

Any chance you have a stack of 8452's sitting around you can't use? I could use a few. If I had had more visibility into this project at the bid stage, I might have opted for the FPGA route as well, or maybe found a gang programmer before investing time in the NI-845x toolkit. My target device supported up to 75MHz, I'm stuck with masters that go up to 12 or 50MHz, and I have 8 devices to program. Ah well, we live, we learn.

Edit: A couple of relevant docs, but they're probably no longer useful for you.

Streaming 16 Bit Transfers Using the NI-USB-8451

Does the NI-8451 have SPI Stream API access?

[mje]

The stream API is not supported on the USB-8451 - I don't remember exactly where I read this, but I'll try and find it for documentation's sake.

The documentation they have on these devices and toolkit (NI-845x Hardware and Software Manual) is pretty meh - the hardware descriptions between the 8451 and 8452 are pretty inconsistent, for one (for example, the USB-8451 doesn't list a transfer size at all).

Yeah, the documentation is quite...well, let's just say unclear in some respects. I don't want to say it's bad, because it does have a lot of information. It's just also missing some important stuff. I don't think I ever did find any clue as to which of the devices formally support the different levels of the SPI API.

I did play with scripting as well, but in the end, none of the low level APIs worked simply because the device just seems inherently incapable of supporting the combination of timing and data frame size I had to deal with. Ultimately I have a really ugly solution using the high level API.

Basically I get a data-ready signal every ~5 ms or so, at which point I need to do my 96-bit data exchange on a 100 kHz clock. There are a few subtleties I won't go into, but that's the basic task and it ought to be very easy. I could probably bang out FPGA code to do this in no time at all, but I'm unfortunately stuck to a PC only environment.

Do you really want to hear this?

My solution (and I cringe at it even now) is basically a two-piece kludge. I have another NI device with DAQmx counter support. I put the data ready line on a counter, and that counter serves as a timing source for a timed loop with the highest level priority, placed in a VI with critical priority level which runs in a Windows PC. Every time the timed loop executes I just read my 96-bits from the SPI device using the high level API and hope the OS hasn't introduced enough jitter to make me have a reading frame error.

So yes, if you're following that's a software-based trigger with no hardware-based data buffer and is pretty much how you should never do data acquisition. However 5 ms is a very long time for a computer and it does work remarkably well considering there's no determinism built into any of it.

[asbo]

So yes, if you're following that's a software-based trigger with no hardware-based data buffer and is pretty much how you should never do data acquisition. However 5 ms is a very long time for a computer and it does work remarkably well considering there's no determinism built into any of it.

Yowza. May God have mercy on your soul. I have to give you kudos for adversity in the face of extreme pessimism, however. I would have just buried a PCI FPGA card in the PC and called it a day

[viSci]

How about something like this...

http://www.robotshop.com/devantec-usb-i2c-spi-serial-interface.html?utm_source=google&utm_medium=base&utm_campaign=jos

[mje]

Interesting!

[asbo]

How about something like this...

http://www.robotshop...tm_campaign=jos

Very cool! Way too slow for what I'm doing, but I'll keep it in mind, thanks for sharing.