LabVIEW
LabVIEW-FPGA and TCP/IP Communication with Matlab/Simulink
Hi lara,
@Iara_S wrote:
Hi, quick question: I am wondering if TCP/IP communication is possible with LabVIEW-FPGA?
Based on assumptions on your LabVIEW skill level (made from your message text) the answer is "No!".
The FPGA has no access to any Ethernet port of your computer!
(Technically you may write a FPGA routine to mimic the Ethernet protocols to drive some DIOs with some additional amplifiers attached to drive the usual voltage levels used on LAN cables. But that would be beyond your skills - and mine…)
LabVIEW FPGA runs directly on the FPGA chip. It looks like LabVIEW but is under the hood simply a VHDL script that gets compiled into a bitfile to run directly on the bare metal. Theoretically one could implement Ethernet in the FPGA and add some external Phy to the digital IOs of the FPGA, but your myRIO FPGA hardware is likely not large enough to do that.
But that is only part of the application running on the myRIO. The myRIO also has a NI Linux Realtime OS executing on the embedded ARM CPU. And it needs a LabVIEW realtime (or alternatively a C programmed executable) which loads the FPGA bitfile into the FPGA chip and interacts with it somehow. While it is also possible to just run install the FPGA bitfile residently so it is always initialized on power up and just does its thing controlling the IOs, this is very seldom used in such a way. You do usually somehow want to control how the FPGA actually behaves, based on user input, or some other events that are not all just digital IO directly to the FPGA.
This LabVIEW realtime application can do TCP communication as it is for the most part similar to what you can do on your Windows computer. In addition it loads the FPGA bitfile and communicates with the FPGA program through FIFO's, or Registers.
In addition if you have a finished Matlab model you could also consider to create a shared library from that with the additional Matlab Coder App.
The resulting C code could be compiled into a shared library for the myRIO Linux OS using the standard gcc compiler and could then be called from your LabVIEW real-time application. As your myRIO uses an ARM CPU, you have to compile your shared library for that architecture. Your standard gcc installation on your PC does not compile to ARM but to Intel x86/x64 instead. You can however install gcc directly on your myRIO from the NI opk repository and then run the compile on there and then you do get the right shared library architecture.
If you want to get very fancy and complicated you could also develop your entire control app in C using the NI-RIO C API. You still need to develop the FPGA part in LabVIEW however, if you need any FPGA functionality.
@Bob_Schor wrote:
The nice thing about the myRIO, its FPGA, and LabVIEW Real-Time is that you have three processors running in parallel (the FPGA, the Atom processor inside the myRIO, and the Intel Chip inside the Host PC).
Little correction here. Atom CPUs are also Intel x86/x64 architecture. Not sure how prevalent they still are but between 2008 and 2015 they were THE variant of Intel Core architecture CPUs meant for low power and low cost applications. They were very popular for embedded systems and small mini systems such as used for set top boxes and media servers because they could operate without active cooling and still perform pretty well. They also often included many peripherals on chip so that the manufacturers could pretty much slap some memory and connectors on the board and be done with it.
The myRIO (both versions 1900 and 1950 that I know of) contain a Zilinx Zync-7010 FPGA with integrated ARM Cortex A9 x2 cores CPU on it, running at .667 MHz. Binary code, including built executables and shared libraries that need to run on this, need to be compiled accordingly for the ARM Cortex A CPU architecture. And while it should support the NEON SIMD VFPv3 standard according to the datasheet, NI choose for some reason the softfp mode for the ABI, so the binary code needs to be compiled accordingly to use software floating point emulation.
