Hi view -
I've been meaning to explain this formally. Give me a week, and I'll have a new document up that explains how to use this library with DAQmx and HSDIO hardware.
National Instruments offers a number of products that can be used for first silicon validation, and characterization testing in PXI with LabVIEW, or other programming languages. We have more information at ni.com/semiconductor, including a reference architecture for common DC measurements on chips.
I'd be happy to help get you more information, and get you in touch with one of our local field engineers to help you out. You can reach me at email@example.com.
Market Development Manager - Semiconductor Test
Hi all -
I've published a new Reference Application that should prove useful when working with the IDW, JDW, and SDW libraries: Serial Protocol Communication with Digital Waveform Devices. It explains how to configure an NI-HSDIO or NI-DAQmx based device to work with one of these libraries. Check it out, and please rate it!
I'm still thinking of using the PXI-6723 for my SPI communication but with a HW clock. The 6723 has a 20MHz and 100kHz timebase used for the counters (a part of DAQ-STC). In the Analog Output Series User Manual (370735e.pdf) Page 1-2 it says "The DAQ-STC offers PFI lines to import external timing and trigger signals or to export internally generated clocks and triggers. The DAQ-STC also supports buffered operations, such as buffered waveform acquisition, buffered waveform generation, and buffered period measurement".
So I guess it would be possible to use the PFI0 and PFI1 pins as SCLK and DOUT for SPI writes, if the signal output of the pins are in sync. Is that the case?
Hi Su Gin -
That quote is discussing the capabilities of the Analog Input and Analog Output functions on the device. The DAQ-STC chipset does not support Correlated DIO. (The DAQ-STC II does, and M-series devices, 62xx, are based on this chipset.) You cannot use the 6723 for hardware-timed digital I/O operations.
Im a newbie to the Labview and Im trying to use 6551 for SPI. So the reference application you posted there and the example were of a great help. Especially the example helped me speed up in the learning curve. Although I have noticed a small bug in the example and wanted to inform you of that. I think in the front panel of the SPI example, under the category SPI channels, the text of CS and SCLK are swapped. ie the input field adjacent to CS corresponds to SCLK and vice versa.
Hi Priyatham -
Thanks for the feedback. The names assigned to signals in a digital waveform are actually stored in the graph object (as Plot Names), not in the waveform cluster. As such, they aren't necessarily updated properly when the waveform data changes. To do this, I would have had to add a lot of ancillary code to the example programs to manage the channel names in the graph object and update them based on how channels were assigned to the waveform cluster. I wanted to keep the examples simple and straightforward, so I chose not to do this. Of course, you can manage those names however you like in your own applications.
I am using the M series 6229 card for emulating SPI.
We are using the concept of using counter and try to generate/acquire through SPI lines>it is working to some extent except problems like getting one extra bit at the start., sometimes not able to receive the valid data,or getting valid data after two three reads etc are happening . But basic operations like Master/Slave communication is fine.But no reliability.How can i make this software a reliable and a consistant one.I did not try using SPI library yet.I am directly writing/Reading bit array of the necessary data into DAQmx read/Write functions.
One more question,can i use the same card for I2C operation because as you mentioned tristating is required for the SDA line of the I2C protocol for getting the acknowledgement.Is this card having that capability?
Hi JeyZ -
In the past, I've worked with microprocessor-based slave devices that have nondeterministic response times to a given query from the master. For example, I would send a data query in the first byte, then expect to clock out the data from the slave in the next byte. If the slave device wasn't done with its search/retrieve routine, it had no data in the output register so all I clocked in was x"00". Could something like this be happening to you? Do you have a datasheet for the slave device you're communicating with that you can link publicly?
You may also try using the SDW library to build the waveform. It will guarantee that timing parameters for the bus are met and all edges in the waveform conform to protocol requirements. Alternatively, I can only ask that you post more information about your application software and the device you're communicating with, so we can help you debug it.
In response to your question about using the 6229 for I2C, that device does not have a per-cycle tristate feature. At present, only the 655x devices support that capability. Without it, you would have to do a lot of work to get this device communicating over I2C, and I can't guarantee it'll be possible in the end.
Hi all -
SDW v1.0.1 has been released. This version addresses a bug in the preallocation of a waveform with multiple CS lines, as well as some minor issues with consistent connector panes across polymorphic instances. You can get it on the SDW page.