whatever I did, as you have mentioned, the result is still faulty operation. Please get attached file "cfpga.zip" where is stored my original bitfile and then two test of "old" vs "new" C Interface to LabVIEW FPGA. To simplify investigation, I have used GCC distribution from NI FTP (ftp://ftp.ni.com/pub/devzone/tut/vxworks63gccdist.zip). Goal of the both tests is to load bitfile with success. "Old" test is working fine, but "new" test fails. Source code is equal. There is bug either in "capigen.exe" or in "NiFpga.out" library. NOTE that I am able to build C Interface to LabVIEW FPGA examples, but they are very simple, so it does not mean the C Interface to LabVIEW FPGA is working correctly.
In addition search for included file "console.txt" where is LOG of execution of both test samples ("new" vs "old"). There you can se what is going on in debug console. My test system is sbRIO-9612.
Thanx for help in advance.
Thanks for the ZIP file. I found the problem. You're using controls/indicators that are type defs, but NiFpga.out does not yet have proper support for them.
As a work around, please try changing your "Instruction" control to be a simple type. You should be able to right-click on it and select "Disconnect from Type Def".
We do have some programmers in-house that prefers to use C#/.net, and not C/C++. What are our options with regards to using a cRIO unit(e.g. 9012)? Our application involves high speed synchronised sampling of ~17 channels, performing FFT, cross correlation calculations amongst all channels, filtering and signal processing. Any programming of the FPGA would be through Labview FPGA. However, will it e.g. be possible to make a main program structure in Labview RT, and then include/call algorithms made in C#? (The paralell to Labview would be to include DLL's or C-code node in the labview main program).
If I understand you correctly, you want to run .NET code written in C# on your 9012? I don't think that is possible, as I know of know .NET Framework that runs on LabVIEW Real-Time (VxWorks in this case).
You could, however, have a host application running in Windows using the FPGA Interface (either LabVIEW or C) which could probably call into .NET code. Is this maybe what you wanted?
I am playing with the "NiFpga_ReadArrayU8" / "NiFpga_WriteArrayU8" functions and seems to me, U8 data is treated as 4 Byte integers. I have stored data stream in byte order like this:
EB3E 9056 5844 4F53 3132 0000 0201 0100
but function "NiFpga_ReadArrayU8" is swapping byte orde this way:
5690 3EEB 534F 4458 0000 3231 0001 0102
I have identical code writen purely in LabVIEW and then under VxWorks C. I did the cross check using byte per byte approchch and I am pretty sure that problem is not in my code. If you generally handle arrays as U32, then "NiFpga.out" should handle it independently from used platform...
Could you please check it?
Thanx in advance.
playing around the C Interface to LabVIEW FPGA I found following behavior of "U8 Host to Target Fifo" operations. I did the following:
I have U8 FIFO buffer (host to target) of size 515 Bytes. I tried to write to this FIFO buffer data "per parts". First written block is 1 Byte, second block is 512 Bytes an last block is 2 Bytes. For each block is checked number of Empty Elements Remaining in the FIFO buffer. Writing 1 Byte I assume that remaining empty elements is 514. Then writing 512 Bytes I assume that remaining empty elements is 2. And finally writing last 2 Bytes there should be zero empty elements... but it does not. Result is, that every write takes the FIFO buffer as it was previously empty. The same I did in "C" under VxWorks and the same I did in LabVIEW. It behaves same way. My test system is sbRIO-9612, LabVIEW 8.6.
Please check attached project where is possible to see what is going on.
Thanks for the updated library. So far, all seems to work fine. Now I am more focused to the FIFOs. Arrays are not efficient for bigger amounts of data (it takes more FPGA resources and also compilation takes longer). As concerning speed of operations, it looks good for now. Good work. I am going to keep you informed if I find any unexpected behavior.
BTW do you expect to implement also Clusters soon?