FTDI FT4222.DLL calling

Question

I am attempting to use the FTDI FT42222 usb to SPI/I2C/GPIO chip with LabVIEW.
FTDI provides two dll's that talk to the chip. After some trial and error, it appears that one dll uses the C calling convention, the other uses winapi convention. FTd2xx.dll and FT4222.dll are provided by FTDI. FTD2xx.dll are the generic USB open device calls and FT4222.dll are the FT4222 specific support.
With that figured out, I was able to successfully communicate via I2C.
Having that, I now would like to use the remaining GPIO pins, one for input, one for output.
So I started and can initialize the port with no errors returned. But, reading or writing to the pins returns an error.
I think it might be the way I'm calling the following:
LIBFT4222_API FT4222_STATUS FT4222_GPIO_Init(FT_HANDLE ftHandle, GPIO_Dir gpioDir[4]);
LIBFT4222_API FT4222_STATUS FT4222_GPIO_Write(FT_HANDLE ftHandle, GPIO_Port portNum, BOOL bValue);
Their docs show:
xx_STATUS       DWORD
FT_HANDLE    DWORD
GPIO_DIR        enum
GPIO_Port        enum
BOOL                unsigned char
So, I used the following in my library function node:
xx_STATUS        Numeric, Unsigned 32-bit Integer
FT_HANDLE     Numeric, Unsigned 32-bit Integer, Pass:Value
gpioDir[4]           Array, Unsigned 32-bit Integer, Array Data Pointer
                              (Here I pass in a 4 element U32)
portNum            Numeric, Unsigned 32-bit Integer, Pass:Value
bValue                Numeric, Unsigned 8-bit Integer, Pass:Value
I'm thinking since all works well for the I2C communication, that I've gotten the STATUS and HANDLE definitions correct.
Am I right in assuming the bools end up 8 bit integers and enums will end up being unsigned 32-bit?
Do I need to use the old trick using a cluster with the first element the array size to pass the gpioDir array?

Answer 1

I guess it's not clear from what I posted, but their docs show gpioDir as an array:
I have since got it working and each of the 4 elements of the array controls the direction of one of the 4 I/O pins.
It turns out to get the GPIO pins to work as GPIO in Mode 0 of the chip, you need to de-assign the default functions of the pins. In Mode 0, pins 0 & 1 are I2C SDA & SCL and pins 2 & 3 are wake and suspend. De-assigning wake and suspend allows GPIO control of pins 2 & 3, while I2C is still functional on pins 0 & 1.
Regards,
Mac