Here I'm attaching the TCP/IP write and read application which is interacting with Customized FPGA board.
The code i developed in LabVIEW is seems to be ok but other side FPGA code is developed in embedded C. In this case FPGA act as a Server and it will give the response for the appropriate command. The response coming from FPGA consists of length and data. In which format length data to be appended in FPGA side to receive the data in attached VI?
Thanks & Regards,
From LabVIEW I'm sending "07020404000000000000000000080000DC1100DC00000008" data to FPGA board.
While sending initially LabVIEW sends the length and next data. The length of the data is "48" after type cast its changing to " 0" ASCII format. Upto this is very clear. Other side FPGA should respond for the above command and it will send the result to LabVIEW. The result will be "0704800000000000000004040004000011000108". In Embedded C code also follow same sequence length and data. But Embedded C developer is confusing in which formt (data type) length field to be sent to LabVIEW.
Kindly let me know what data type to be set for data length in FPGA code.
Well, it's still not entirely clear what you want to do, but I assume that you ask about the automatically prepended int32 value that LabVIEW adds by default to the flattened string. Since your string consists of 48 characters and you say that the length you see is 48 it seems the string you showed is interperted in straight ASCII and not binary.
So LabVIEW adds a 32 bit binary value in front of the string. This value is by default in the Big Endian format, but if you use the Flatten to String primitive you can also specify a different Endianess if that makes life for your Embedded C programmer easier. (We don't know what CPU architecture your embedded C programmer is working on, so we have no idea what its native byte order could be).
The 32 bit binary value consists of 4 bytes and if in Big Endian format that is 0x00, 0x00, 0x00, 0x30. So just tell your embedded C programmer to read 4 Byte, typecast that into an int32, possibly adjust for the byte order (or make sure to flatten to the byte order the embedded C target uses) and then he can work from there.