Industrial Communications

Showing results for 
Search instead for 
Did you mean: 

LabVIEW FPGA SPI with NI 9651 dev board

Seems like the SPI API for labVIEW FPGA needs to get updated for use with the new NI-9651 SOM dev board. The API does not recognize IO pins of the NI-9651.

0 Kudos
Message 1 of 30

Hey Rood,

I have done some intial work porting the SPI engine and had resonable success but it never became a release because I2C was a more complex code base. You can get the SPI engine to work on your own by following these steps. For each of the pin controls you need to update the resource type so it can see the raw digital IO.  This can be done by creating a FPGA IO Reference and right clicking to Configure I/O Type…. This will allow you to select which type of IO you want to interface with, you should be able to select either the DI or DO or both pins and that will change the definition so you can select them from the drop down.


We are working on an additional implementation for SPI for SOM. I'll need to check with one of system engineers to see where the status of it is. 


Kyle Hartley
Senior Embedded Software Engineer

0 Kudos
Message 2 of 30

Hi Kyle, Thank you for the quick response. I will try this and let you know.




0 Kudos
Message 3 of 30

Hi Kyle,


So I tried to chenge the definitions on the dropdowns but I am having problems with the way the SOM defined the IO. In the project explorer after defining your clip LabVIEW seperaes pins by direction, forexample there is a SCLK IN and a SCLK OUT and they are separet IO pins on the project tree! the SPI API requires one SCLK pins that is bidirectional but I can not generate that!

0 Kudos
Message 4 of 30

Hi Rood


It is my understanding that SPI requires a single SCLK provided by the master and going to the slaves, so I do not completely understand why you would need this signal to be a bidirectional pin. Could you please help us to clarify this?





0 Kudos
Message 5 of 30

So when I try to reconfigure the IO based on Kyle's suggestion I get to this window



as you can see the IO name control type requires a resource with both read and write capability, where as my resources on the left are either read or write not both, so when I overwrite the IO item type i get a conflict error as shown here

reconfigure 2.JPG


reconfigure 3.JPG


0 Kudos
Message 6 of 30


I think I remember what happened now basically the pinout saved in each vi is a seperate control rather than a typedef that inherits from the same definition. 


If you can back up your changes and make a type def of the control and link all the controls of the subvis to it. Then go in and change the pins. 


There are 3 elemental IOs you need to worry about with each pin. in, out and en.


To output a value to you need set the en IO to true (this acts like a max for the output pins) Then set the out value to true. You can always read from a channel but if you've output a 0 or 1 while the pin is enabled chances are you will just read that value. You have to disable the output connection by turning off the en line.


Hope that helps. 


Wen is right you shouldn't need a SCLK in line for the clock. The nice thing about SPI is all the line directions are defined so you can set MOSI, CS, and SCLK to outputs or and MISO as an input. 

Kyle Hartley
Senior Embedded Software Engineer

0 Kudos
Message 7 of 30

Hi Kyle,


So i did all of this amd now i can compile my code but the compiler gives me this error when it goes thorugh checking my code



which is refering to these "CS" pins


error 2.JPG

0 Kudos
Message 8 of 30

It looks like you are compiling the SPI engine as a top-level VI.  In this scenario, the IO Node name controls are on the front panel. Therefore, when the VI is running, you or an operator could theoretically click the drop down box for one of the IO names and select a different pin.  That capability can't be dynamic at run-time, so LabVIEW parses the application to flag and remove these scenarios that could cause unexpected behavior.  


Normally this engine is a sub-VI on a larger application.  If you want/need to compile this VI, you have two primary approaches.


1. Right click on the SPI FPGA IO control on the block diagram and click "Change to constant".  This should enable your code to compile, but the downside is you have changed your source code to enable this compile.


2. Create a new top-level VI and use the SPI engine as a sub-VI.  On the top-level VI, you will need to wire a SPI FPGA IO name control CONSTANT into the sub-VI.  The benefit with this method is you can now test your source code without modifying it.



National Instruments

To the pessimist, the glass is half empty; to the optimist, the glass is half full; to the engineer, the glass is twice as big as it needs to be has a 2x safety factor...
0 Kudos
Message 9 of 30

Also, I want to emphasize Kyle's earlier point that all digital output pins must be explicitly enabled or the physical pins will not toggle when the FPGA DIOx_write signal is written in LabVIEW.  In the same top-level VI I recommended creating in my previous post, you should create an initialize frame where you assign TRUE to the DIOx_en pins that will be used as outputs.  If these outputs are not enabled, the SPI engine will run, but you will not see any data toggling at the output pins.



National Instruments

To the pessimist, the glass is half empty; to the optimist, the glass is half full; to the engineer, the glass is twice as big as it needs to be has a 2x safety factor...
0 Kudos
Message 10 of 30