SPI Digital Waveform Library

[David S.]

Hi tlee16 -

If you probe the wire coming out of your "Format to SPI" VI, you'll see this:

Since you provided an input parameter of "Slave address = 0" (when the control is disconnected, it takes its default value), we can look at this waveform and deduce the role of each line:

0 --> CS_1

1 --> CS_0

2 --> MISO

3 --> MOSI

4 --> SCLK

Since you're not using the HWC engine, you only need to split this signal up into input lines and output lines, then wire the output lines to the "Run Core Device" VI in the same order as they are mapped in the HSDIO hardware. Your HSDIO mapping order is [CS_0, CS_1, MOSI, SCLK]. So we need to extract lines (0, 1, 3, 4) and reorder them to [1, 0, 3, 4]. I think this is the array that should be input to the "Digital Signal Subset" VI, though I haven't tested it.

Regarding the initial and idle states of each output line, those define what the device does with its I/O drivers when it is in the initial state or the idle state. These states are defined in the Digital Waveform Generator/Analyzer Help file; you can read about them online here. "1101" means that your initial/idle states for each line will be:

CS_1 --> '1'

CS_0 --> '1'

MOSI --> '0'

SCLK --> '1'

[tlee16]

Hello David,

I've connected 2 slaves (CS_1 (pin 11), CS_0 (pin 9), MOSI (pin 7), MISO (pin 5), SCLK (pin 3)), it seems working only for 1 slave. When I select CS_0 or CS_1, it reads the output from 1 slave but when I toggle the slave, both CS lines stay high (no outputs read). I'm attaching a sample VIs, and really appreciate if you could help me figuring out what's wrong with my code. The waveform displays the correct state from software (one CS high and the other low) but when I probe it, both CS lines are high.

[David S.]

Hi tlee16 -

Unfortunately I'm not going to be able to set up hardware to debug this problem with you; I can only look at code and screenshots that you provide. It does look like you're generating the right digital waveform, and everything else looks good at first glance, too. The only thing I can think of is that you might be seeing the line during its idle or initial state. Right now you have that set to '1' (high) for both CS lines. Are you triggering your scope on the SCLK edge so you can view the actual packet?

[tlee16]

Hi David,

I put a scope on CS line and sees both CS_0 and CS_1 high (both slaves have correct SCLK in). In software, it seems triggering CS_0 low and CS_1 when slave 1 is selected, and viseversa. But it doesn't seem to toggling actual HSDIO CS lines when slave is toggled from software. Also, how do I make initial/idle state toggle with CS? And yes I'm triggering on the SCLK's edge to capture data. Thanks again!

[User002]

Hello,

I'm using the SPI-Library on a LV8.6-System and it's running very well. When I tried to move onto a LV2010-System the performance was only about 0.1%.

The VI runs 1000 times slower than before. You can test ist out by using the example coming with the library an putting an 100-times loop around the swap sub VI.

Does anybody knows a reason for that?

Walter

[David S.]

Wow, HF-Walter, I see the same thing. In LV2009 I get ~400 ms for 100 iterations, but in LV2010 it takes ~9600 ms. Let me talk with R&D about this; hopefully we can find a fix for this version of LV. I'm afraid, though, that the compiler may have changed with permanently deleterious effect.

[David S.]

Hi Walter -

The slowdown is probably caused by "Allow Debugging" and "Enable Run-Time Error Handling" being enabled in the shipping code. As a workaround, disable both those options in each of the VIs to return to good performance.

[User002]

Hi David,

I made the workaraound and I found the following execution times: in LV8.6  32ms and in LV 2010  1920ms.

When compiling the programm to a .exe you can't find any performance lost. So you will be right with

your assumption of the options.

Thanks

Walter

[RLD]

The polymorphic "Send.vi" of the SDW library handles byte, word, dword and qword inputs.  I have an SPI application that requires transmitting a 34-byte binary string.  Is there any reason that Send.vi can't be expanded to support an array of U8's?

Rich

[David S.]

It reasonably could, but I had to limit the scope of the reference design at some point and wanted to make it as user-friendly as possible. I provided low-level functions on the palette that you can use to build a 34-byte "Send" function of your own. Look at the block diagram of the existing high-level "Send" functions for reference.