I have been trying to write some Labview code to use the SDRAM on the OK XEM3010. When I run the CCP executable provided in examples, I get the following successful image:
Now, when I try to a very similar execution in labview I am receiving no errors, but also no valid data:
Essentially my programmatic flow is shown below:
Initialize Opal Kelly (Load Bitfile)
Write 0x04 to EP00 (Reset the RAM)
Write 0x00 to EP00 (Remove Reset state)
Write 0x02 to EP00 (Enable Write Mode)
Generate random number and flatten to Char*
Transmit Data on PipeIn (EPx80)
Wait 1s
Write 0x04 to EP00 (Reset the RAM)
Write 0x00 to EP00 (Remove Reset state)
Write 0x01 to EP00 (Enable Read Mode)
Recieve Data on PipeOut (EPxA0)
Unflatten data
Close Opal Kelly reference
The main puzzling thing to me is, regardless of what data is written to the memory, when I read the data back i receive the same 0x2672 back. The DLL call is also giving a valid return (equal to the Transmit size) so I don’t think there is an error in the pipe. I also see no error flags on the LEDs, which are assigned in the RTL by default in the example.
As for the labview code, I currently am using the OKPipeIn, OKWireIn, and OKWireOut successfully in another application. The OKPipeout is the only uncertainty, but it seems I am receiving data from the Pipe…
Any help is appreciated; I am not an RTL expert, so most of my coding was a result of reverse engineering the ccp files in the example code.
Turns out it was a labview side error, as I suspected, with the PipeOut function. The labview VI requires both an input char* and an output char* to operate properly. I had assumed leaving the input char* would just pass a default value into the function, but it did not. By simply adding a blank string to the input char*, my reads began to make sense. Can’t post the actual code, but I can post a picture of how it looks.
For reference:
Open Confg FPGA: General Opal Kelly initialization similar to C++ example
WriteToPipe: Direct DLL wrapper for the PipeIn
ReadFromPipe: Direct DLL wrapper for the PipeOut
Write Wire: Combines SetWireIn and UpdateWireIn
OK Close: Closes the Serial connection with the Opal Kelly
Turns out it was a labview side error, as I suspected, with the PipeOut function. The labview VI requires both an input char* and an output char* to operate properly. I had assumed leaving the input char* would just pass a default value into the function, but it did not. By simply adding a blank string to the input char*, my reads began to make sense. Can’t post the actual code, but I can post a picture of how it looks.
For reference:
Open Confg FPGA: General Opal Kelly initialization similar to C++ example
WriteToPipe: Direct DLL wrapper for the PipeIn
ReadFromPipe: Direct DLL wrapper for the PipeOut
Write Wire: Combines SetWireIn and UpdateWireIn
OK Close: Closes the Serial connection with the Opal Kelly
Hope this helps someone![/QUOTE]
I also have the problem when i test the pipeout function with labview. The problem is really from labview side. I tried to use the same solution you mentioned to get the pipe out data, unfortunately it’s not successful. Only the first data is shown by labview. XEM board works correctly. I will appreciate that if you can provide further information that solve this problem. Thanks.
By the way, i use labview 2012, API version is 4.3.0.