I modified the SPI example protocol that David made to make it a 8bit half duplex transmission. I want to configure registers serially using this SPI. So this 8 bit SPI should execute sequentially with a different data on MOSI each time. How do I do this? I have tried using For loop, but not much success there. I'm sure this is a standard practice, so was wondering about the best way to implement this.
Hi Priyatham -
This code will construct a variable-length waveform of immediately sequential byte transfers to the slave. It will output a single waveform with all the bytes encoded as one stream, so the entire message is written out of your DAQmx/HSDIO device at once.
Alternatively, you can build multiple waveforms, each of which has a single byte transfer inside. These will have to be written out one at a time.
(See the Serial Protocol Communication Reference Design for Digital Waveform Devices for information on how to configure and run your DAQmx/HSDIO device with these waveforms.)
Thankyou David, that was a great help. I got it working with one Data byte but Im not sure how to replace it with a array of Data Bytes and make it take one byte per transfer sequentially as you have done in the indicated snap shots. It would be great if you can inform me on those and attaching those VIs you created would also help a lot.
Hi David or other Engineers!
I was happy to find this document and the DAQmx examples for SPI. Tried it out but unfortunately LAbview generates an failure: ERROR 200452 (see attached file)
The difference to your HW is that I am using a DAQ6534 (which has probably no DATA ACTIVE EVENT???). But I changed the PFI1 to ACK1 and still have the same error (see attached jpg).
Is there a solution to let the vi's run on my DAQ card?
I have one other question. In my application I configure the DUT using SPI mentioned here until a stage after that the DUT takes over as the SPI Master and I have to act as the slave. So I have to start acquiring the SPICLK, CS and MOSI sent by the DUT and respond through MISO. I was wondering if its possible to modify the SPI Reference library to do this?
I literally JUST had the same exact problem with the 6534. If you look at the Serial Protocol Communication Reference Design for Digital Waveform Devices (http://zone.ni.com/devzone/cda/epd/p/id/6200), you'll notice that it has been updated to exclude the 6533 and 6534. Also the VI's have been modified to change the oreder of the event trigger and first write task. The 6534 does not support the data active. Another problem that you would probably run into is that usage of the ports are unidirectional. By that I mean each port can be input or output, but all 8 or 16 pins need be the same direction. ALSO, all 8 or 16 pins need to be used, which means they need to be tied to the task with dummy data. I had a couple NI guys helping me out to figure this out for my application, and the solution was to purchase a 6535/6/7 board.
If this is not an option for you, then the main problem that I could not solve was a way to synch the input and output tasks. In the "Init IntClk Device.vi", you'll notice that the Active Data event is used to trigger the input task FROM the output. We were not able to replicate this trigger with any event available on the 6534. An option was to trigger BOTH input and output tasks on a signal from a second DAQ board. We were having trouble doing this through the software or RTSI cable, but I don't believe we tried wiring an actual wire between 2 boards.
Time is a critiacl factor in my application, so the price of the 6535 is less than the risk of development time involved. I was able to get the VI's working perfectly on a 6537 though.
As I asked previously .... im also trying to use 6551 as a SPI slave. I was reading literature and I found this paragraph:
"For the same reason, waveform devices are not suited to acting as a slave on most serial buses. Slave devices normally listen to the bus and respond immediately to the master device when addressed. The low throughput of a host-side bit banging emulation makes it difficult to configure waveform-based devices to respond to serial addressing mechanisms immediately."
My SPI runs at only 7.5MHz and the 6551 clock can oversample upto 50 MHz. Do you think I still wont be able to use this efficiently as a SPI Slave?
Hi Priyatham -
Though I didn't go into detail in the whitepaper, there are several reasons why this Reference Design isn't well-suited to implementing a serial bus slave node. I'll name the ones I can think of immediately:
First, HSDIO-based devices require a continuous sample clock to work properly. They use a pipelined architecture to generate data, and so the generation engine must be provided a continuous sample clock. The SPI bus (and almost all serial buses in general) uses a non-continuous sample clock (SCLK). If you try to use SCLK as an external Sample Clock for a Generation task, you'll see a latency of 32 clock cycles on the output data. And for SCLK frequencies of 25 MHz or higher, the driver will report a PLL lock failure error when you commit the task.
You might try to run the HSDIO generation using the Onboard Clock, but that requires synchronizing that clock to the SCLK signal so the data is generated at the right times. There is no method for doing this with HSDIO devices.
Moreover, any time you import the SCLK signal as your sample clock, you won't be oversampling anymore and cannot use the SDW library to generate your data.
You could try to use the scripting engine to generate a series of single-bit waveforms in response to a repeated falling-edge (or rising-edge, for SPI modes 1 and 3) trigger. I don't know whether the trigger holdoff time or other device limitations would play into the performance of the system. Now the DAQmx devices can be used with a non-continuous sample clock. And you could again use a falling-edge digital trigger on the SCLK signal for the Digital Output task. But, as above, you can't use the SDW library anymore.
Second, your "slave device" will have to be psychic, because its response latency will be much higher than tolerated in most use cases. In order to provide output data immediately when requested by the bus master, that data will have to be preloaded in the device's output buffer and the Generation/DO task will have to be intialized.
For example, in many systems a register-based scheme is used to retrieve data from a slave device. So the response to send the master depends on the register address received from it. And the master may want to clock that reponse back out of the slave within a few hundred microseconds of clockin in the register address. But with an HSDIO or DAQmx device, your application will have to receive the register address, pass it up to the host CPU, decode it, fetch data from that register, write the data back to the device's onboard memory, and commit/initialize the task before the next SCLK pulse comes from the bus master. The jitter of the Windows OS alone is ~10 ms; that could be orders of magnitude greater than the maximum delay tolerated by the bus master.
What makes the SDW feasible is the assumption that the HSDIO/DAQmx device has control of the bus timing. When timing control is given to an outside agent (another master device), many of the assumptions made in designing it are no longer true.
My recommendation for implementing a serial bus slave is to use an FPGA-based device, like the sbRIO, cRIO, or R-series DAQ devices.
Thankyou very much for the explanation. However in my application I dont need to act as a true SPI Slave .... I mean, I need to send predetermined bytes of data in predetermined sequence when the DUT asks for them. In some other thread, I read that to mock such slave behaviour we can probably use HSDIO devices. Can you please clarify if this is true.