Issues with the SPI modules.

[Philbot]

Hi

I'm trying to get an SPI interface working on my cRIO.

I started with a custom program we built using the SPI Accelerometer example.

The program seems to run (I can highlight execution and see numbers being sent to the SPI Write VI), but I don't get any activity on the Digital outputs.

I'm enabling the robot, and I'm using a scope to monitor the clock and data outputs.

I'm using DIO 3 and 4 as the data and clock.

I then switched back to the pure SPI example code (but with DIO 3 and 4) and I still don't see any activity.

If I drop right back to the basic Digital output examples, I can see the DIO 3 and 4 outputs change when I toggle the screen controls, so I know I'm wired up and running correctly..

Any reason why I would only see low levels on these outputs?

Do I need pullups on the DSC outputs for SPI?

(I didn't post code as the pure SPI example doesn't generate outputs for me.)

Phil.

[Simon-P]

Greetings;

Just to double check, when running the base example with no modifications, do you see nothing as output in the default lines?

I am curious as to whether the ADXL 345 Open.VI is throwing an error that is not being caught; could you add some sort of indicator or probe the output to see if that would be the case? The same thing would go for the output from the Write, would you happen to be getting any error that is not being handled?

If you set the Configure Active Low input to the Advanced Configuration VI to False instead of True, do you see any difference in output?

Cordially;

Simon P.

[sciencewhiz]

I might be seeing the same thing.

I was trying to get SPI working in java. Everything looked good, except that the chip select was not staying active for the full length of the transfer. I decided to try SPI in LabVIEW to see if I could get it working.

I see a similar result to Phil, I do not get any output on any of the DIO pins. I verified that there are no errors from any of the SPI. I tried it with the Clock Active Low set to false also, same result.

Here is another person that seem to have similar issues: http://www.chiefdelphi.com/forums/showthread.php?t=111719&highlight=spi

[Philbot]

Hi

I don't have an ADXL to test with, but I did not see any erros on the open.

I did not use the default DIO pins ohn the base example, as they were in-use on my robot.

I just shifted ports to 3, 4 and higher.  No other changes.   No outputs were observed.

Once again, should I need pullups?

Phil.

[DAQjr]

Hi Phil,

You do not need pull-ups.  They are built into the digital sidecar on all DIO pins.

I'll try to reproduce your problem here and get back to you.

-Joe

[tr6scott]

Hi, juct checking in, I am the mentor that posted on the CD website, we have the same issue. Code hangs with no output,

Scott.

[DAQjr]

Hi Phil,

I found the issue.  The wrong module is getting selected when opening SPI.  We will include the fix in the next update.

In the mean time, all you need to do to fix it is to edit the WPI_SPIOpen.vi to remove the four "-1" VIs that are subtracting the module number.

Cheers,

-Joe

[Philbot]

That's great.  I'll test this out tomorrow.

Phil.

[Philbot]

The patch to the SPI open worked just great.

Now I have questions as to it's operation.

It looks like the Write operation is not blocking...   and if I write too much too fast the data gets corrupted.

So.. is the SPI interface into the cRIO something like a FIFO or stack that can be overrun?  How big is the queue?

One fact here is how fast the cRIO can clock out SPI data.  What is the upper speed limit?  Does it default to the max rate?

I want to pump out a lot of bytes as fast as I can... is there anything I can use to detect when I'm going too fast?

If I can split the data into two or more SPI streams can I get more throughput that way, or is there a shared queue

Phil.

Thanks for any insight....

[DAQjr]

Philbot wrote:

The patch to the SPI open worked just great.

Glad to hear it!

It looks like the Write operation is not blocking...   and if I write too much too fast the data gets corrupted.

Corrupted how?  Just missing words?

So.. is the SPI interface into the cRIO something like a FIFO or stack that can be overrun?  How big is the queue

There is a buffer in the FPGA that will take your write commands and queue them up.  The buffer is 512 words long.  It doesn't matter how many bits (up to 32) are in your word (configured on Open).

One fact here is how fast the cRIO can clock out SPI data.  What is the upper speed limit?  Does it default to the max rate?

It does default to the max rate.  The max rate is 76.6 kHz.  Take a look at the context help for WPI_SPIConfigureAdvancedOptions.vi.

I want to pump out a lot of bytes as fast as I can... is there anything I can use to detect when I'm going too fast?

There are some low level VIs that allow you access to the FPGA status if you are trying to max out the bandwidth.  Look for <vi.lib>\Rock Robotics\SystemInterfaces\SPI\FPGA_SPIReadAvailableToLoad.vi to get the number of available words in the write memory.  If you write when that VI returns 0, expect to lose data.

If I can split the data into two or more SPI streams can I get more throughput that way, or is there a shared queue

There is only one SPI engine, so there is no option for splitting streams.

Cheers,

-Joe