How to program a SoM sbRIO-9651

[David-Baratheon]

Ok I will give that a go. So what does the pin do that I was using?

Looks like another 10+ minute wait for the code to deploy then 

Shame it takes so long to deploy code.

I have removed the LED for now and used a front panel boolean LED instead as I need to ensure the switch is working before trying to get the LED to work.

Any idea why I have three different pins (LED1 IN, OUT and ENABLE) for each LED? I thought an LED would only be connected to one FPGA pin.

[Sam_Sharp · Accepted solution]

You are wiring the reference to the I/O item into the reference-in of an I/O node which instead of the I/O node being linked to a specific input/output item, it is linked to the one on the wire reference.

Probably because the I/O pins are tri-state. You can use it as an input, output or high-impedence etc. 

[David-Baratheon]

But an LED can only be an output, so why would they give me the option of it being an input?

They haven't done the same thing with the two switches.

It's a bit confusing as to how I should utilise the LEDs. Got the switch working now. Tested it with a boolean LED on the front panel. But not sure on how to use the LEDs

[Sam_Sharp · Accepted solution]

Because the 'LED' is still a digital I/O pin on the SoM so it's treated the same as all of the other digital I/O pins on the SoM.

If you look at the SoM example projects (open NI example finder and type '9651' into the keywords) then it will show you a simple project using the SoM (it turns out I have the SoM drivers installed for 2014 so I can see the examples) and how to input/output on the I/O pins.

[David-Baratheon]

Ok I have downloaded the example and am having a little look at it now.

For some reason the LEDs are always on, on the reference carrier board. So I can't tell if I am successfully transmiting a boolean 'on' signal. Any idea why the LED might always be on?

[Hooovahh · Accepted solution]

Yup no probing in an FPGA, no step over, step into, wires retain values, breakpoint etc..  It is an FPGA and once it is deployed that's it.  You don't have much control over it and that's just due to the hardware needing absolute control over things, and adding probes or whatever can mess with that.  Not to mention the unnecessary gates it would take to have probing on all wires a possibility.  We get spoiled on Windows where we have tons of resources for things like debugging.

If you want a quick way to see a value, you have to have an indicator on the front panel, and recompile.  But don't go and make indicators for everything, again this takes up vital resources on the FPGA.  Front panel elements are fine, but if you start to hit a limit, or your compile time increases on the order of an hour or more, you might want to evaluate those indicators working as probes.

EDIT:  Oh do you have an SSP?  There is some free online training for FPGA and RT development that might help.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019SH7SAM&l=en-US

[David-Baratheon]

Any idea why the LEDs on the board might be parmanently on?

[David-Baratheon · Accepted solution]

I found out from the examples that I needed the LED enabled pins attached to true constantys outside the while loop in order for it to work.

That concludes my experimenting with the sbRIO board to learn how to use it.

I will now be looking at how to use it in real time, and also how to send serial communications with the FPGA modules, so if anyone is able to, please help me out on that thread.

Many thanks for all your help.