Hi Priyatham -
Are you still working with the SDW library, or is this the custom SPI implementation you've been developing in other posts? I set up this board to support the SDW library and its applications specifically; you will probably find it more helpful to post in the Digital IO or LabVIEW forums for more general programming.
In general, I can say that the kind of bus arbitration you're describing is not easily managed with a waveform device like HSDIO and DAQ. Being able to emulate a serial protocol bus with one of these devices relies on a very important assumption: that the waveform device gets to control all timing of bus interactions. Tasks like arbitration, clock recovery, slave-mode operation, etc. do not permit this assumption, and so they can be difficult or impossible to implement.
1. I am using the PCI-6229. I have not dug into the HW specs too deeply. I was more looking into the LabVIEW side. I will look at the HW to try and find more info on HW trigger.
2. For the MISO line, I am able to modify your "Correlated DIO" example to get the MISO digital subset. However, this leaves me with a large binary array with a size based on my number of samples. I will need to figure out a way to convert this to a byte format. I am OK to try and work on this, but I just want to make sure I am not doing a lot of extra work for something that is already taken care of by the SDW library.
When I am sedning a byte, the SDW library will take my byte and add the timing etc to create the waveform. Isn't there a way this can be done in reverse?
Hi Jamie -
1. Again, LabVIEW is just a programming language. What you're doing is building a set of data using the SDW library, then controlling how the 6229 operates on that data set using the NI-DAQmx driver. Configuring the device properly and managing its tasks at runtime is part of the task of emulating a SPI bus master.
2. Look inside the SDW VIs. When you wire a byte of message data into the high-level VI, it takes that byte and builds an array of bit values from it. That array is then parsed, and each of its elements is interleaved other arrays, which are subsequently stacked together in a much larger array that represents the entire waveform. That array is then wrapped into a DWDT and exported to the calling function. Doing this in reverse (extracting the byte of slave data from the waveform) is exactly the task of:
SPI HSDIO Examples Wanted:
I have used USB-8451's to collect SPI data from gyroscopes using Labview. Presently no hardware timing is available for the 8451 and the software (timed loop) timing errors (sigma=0.4ms) are inadequate for our signal processing.
Hardware timing with SPI emulation in HSDIO seems to be the fix; I can choose the (field installation probably needs to be USB) hardware and I have the SPI, JTAG, I2C 'Dig Wav Ref Libraries', and the "SPI Serial Protocol Communications .... Tutorial" downloads installed in a test machine. I have thirteen years experience with Labview but not with complex Labview digital stuff.
Are there any complete examples of (continuously running) SPI command Out and data Returns in HSDIO using the SPI Digital Waveform Library? I have found many pieces but want a complete example to learn from, and for modifying. My simple need is two gyros, each (Chip Select successively) with 4 bytes (1 byte get-data command and 3 bytes return data). A 1 MHz SPI clock is adequate.
Check out the examples that David referred to in an earlier post on this thread (page 5), where a link will take you to the "Serial Protocol Communication Reference Design for Digital Waveform Devices". These should get you started. If there is not something that fits your exact application, you might be able to modify the examples. Also, you can check out the HSDIO examples that ship with the driver to show you what a continuous generation looks like, both scripted and non-scripted. For details about using the HSDIO devices, definitely check out the NI Digital Waveform Generator/Analyzer Help either in html form or you can download your own version if you didn't install it when you installed the HSDIO driver.
Hope this helps.
I have a similar situation to Guyanalog, except I want to use a TB-2715 (with a very detailed soldered connection to an SPI sensor) on a PXI-6608 board.
I've read through many of these forums but I'm still not sure how to set which ports on the device to act as MISO, MOSI, the clock, etc.
Thanks for any help,
The SDW Library is intended to be used with a clocked digital I/O device--unfortunately, the 6608 does not support buffered digital output (only static Digital I/O and Counters).
For a starting point for doing software-timed SPI, I recommend that you check out the following forum post: Implementing I2C or SPI with PXI 6508 in LabVIEW. Different hardware, but the idea should be the same.
To answer your immediate question, you may select which lines are to be used for input and output when you create your task. The above link can show you how to do this.
For other general questions about programming the 6608, I would try posting to the Counter/Timer forum. We'd like to keep this one clear for questions about the SDW Library specifically. Thanks for posting!
Is there a way to customize an SPI transaction using SPI Digital Waveform Library?
I would like to create a custom SPI waveform for the PXI-6551, where chip select (CS) is asserted in a pulse only after data is clocked out completely. When the data is being clocked out from the master, CS should be inactive high.
I've looked into the SPI Digital Waveform Library but from what I understand it has a default behavior for Chip Select(CS), in which CS is asserted during clocking of data.
Hi Su Gin -
It should be easy to modify your copy of SDW to change the CS behavior the way you want. If you look inside the high-level VI called "Swap", you'll find that the Slave Address input -- which is used to toggle the proper CS signal -- is wired to two low-level VI: Add First Bit and Add Last Bit. (These are both on the SDW palette, on the bottom row.)
Inside these VIs, you can see the code I use to change the CS signal. In Add First Bit, asserting CS is the very first operation performed:
Inside Add Last Bit, deasserting CS is the last operation performed:
My recommendation, according to the description you gave, is to cut the code shown in the Add First Bit VI and paste it in front of the code shown in the Add Last Bit VI. This will move the CS-assert operation from the beginning of the transmission to the end of it, and it'll be immediately followed by the deassert-CS operation. This, along with a delay in between the toggling operations, creates a CS pulse at the end of the transmission.