LabVIEW
Passing two hex numbers as a byte variable in dll calls
Solved!
Since I2C is a binary communication interface, a string is really the wrong parameter for this. But a single byte passed as pointer is pretty wrong too!!
I2C allows to send up to 255 bytes in a single frame. Depending on the hardware that you talk to it can require anything from 1 to up to 255 bytes to send. So the right parameter is a byte array in this case.
Then you also want to do as much as possible in the function itself. It is pretty senseless to let the caller of this function have to set the nCnt value for a write operation. The number of bytes to send is already present in the buffer that you provide to the function. So make the VI determine this length itself and don't bother the caller with these details.
For the read apply the same ideas,: Use a byte array for the data, initialize the byte array buffer to the size requested and not to some arbitrary size of 8192 bytes. The import library wizard can't possibly do more than this as it can not know that the nCnt parameter is the relevant parameter for the buffer size nor that this is talking about the number of bytes and not for instance the number of lemons, or int32 or your heart rate.
An additional problem when using a string instead of a byte array would be that LabVIEW does for parameters passed as C string pointer do a scan for a NULL character (a byte with the value 0) after the function returns and considers this as the end of the string, truncating it there. Since I2C is binary in nature, NULL bytes in returned data are very possible and normal and you do not want this cut of from the returned data. By making it an array data pointer instead, this will not happen.
Of course adding proper error handling for all the functions with an error cluster is also a nice touch!
