I2C + Call library function node

[CatherineBrown]

Hi, 

I am using labview to control I2C commands for a UM232H module.

I have been able to get the some modules working: Open and Close the channel, Initialise, Get Description. 

However I am unable to execute the read and write commands. 

I have set these up using the Call library function node and mimicking the setup used for SPI and adjusting it to I2C. 

The read and write VI is currently set up to turn an LED on and off that is connected to PCA9535 that is connected to um232h. I am however unable to understand why it wont work and wonder if its a Labview issue. 

I have attached the VI for the read and write. 

Thanks,

Catherine 

[rolfk]

It would seem you are trying to run that on LabVIEW 64-bit. (I have the 32-bit version installed and LabVIEW claims that the VI was converted from a different platform.)

In that case making the FT_HANDLE parameter an uint32 is an error! It should be an uint64. However to make your code work on both platforms you best configure it as unsigned pointer sized integer (uintptr_t) in the Call Library Node and an uint64 for any front panel control in which you pass it around.

I would also write a specific VI for the Read and Write and reuse that instead of having it each as separate Call Library Node. In that case you can make the code also smarter. Currently you match the sizeToTransfer parameter manually with the length of the array. Better is to use for the write an Array Size node on the array and pass its result to that parameter. That way your separate write VI can handle that under the hood and the user of that VI doesn't have to worry about this detail. For the read you pass in the number of bytes to read, initialize an array of that size with Initialize Array and pass that to the according parameter. Again the user of your VI should not be bothered with C programming trouble about having to provide a large enough buffer for the read function to return the requested data in.

[CatherineBrown]

Hi, 

I've had a look at this but still no success. 

I have attached another sub-vi. This one uses the I2C_OpenChannel command and the I2C_InitChannel command. 

The I2C_OpenChannel works however the I2C_InitChannel does not. These are both setup using Unit32. This is also following the PDF in my first message. 

The example code has worked on this device, using C, therefore we know the wiring and hardware are correctly setup. 

Thanks,

Catherine

[rolfk · Accepted solution]

You still haven't changed the FT_HANDLE to a pointer sized integer!

And of course does I2C_Init_Channel() go wrong.

The config parameter structure does not match the definition in the API!!

This is the definition of that structure:

typedef struct ChannelConfig_t
{
	I2C_CLOCKRATE	ClockRate; 
	UCHAR			LatencyTimer; 
	DWORD			Options;	
	DWORD		Pin;
	USHORT		currentPinState;
} ChannelConfig;

This is what you configured for the cluster:

Do you see any difference in the order of the parameters??

And since Windows DLLs by default use default aligning and LabVIEW 32-bit doesn't you should also stuff the cluster with extra fill bytes to make it align with the Windows representation.

typedef struct ChannelConfig_t
{
	I2C_CLOCKRATE   ClockRate; 
	UCHAR           LatencyTimer;
	UCHAR           Fill1;
	UCHAR           Fill2;
	UCHAR           Fill3;
	DWORD           Options;	
	DWORD           Pin;
	USHORT          currentPinState;
} ChannelConfig;

[CatherineBrown]

Brilliant! My I2C_InitChannel is now working ! 

I have made the same changes to my read / write VI nodes. 

However I'm still getting an return of 1 = FT_DEVICE_NOT_FOUND, I have been able to confirm that the address is correct, using the same buffer for the 'Set as an Output Block' 

(The formatting still needs to be made tidy) 

Thank you ! 

Catherine 

[CatherineBrown]

Hi, 

When i run this VI I am able to see the I2C command byte in the scope, however not the data being sent. 

I have attached the VI and the image below is the command structure. I have the start and stop working, and it sends the address but it dosen't send the buffer data. 

Edit to add image of scope: