davekorpi wrote:
"Not sure how to put the right values to the parameters of IowKitWrite(devHandle: IOWKIT_HANDLE; numPipe: ULONG;buffer: PChar; length: ULONG): ULONG; stdcall;"
Ok, so, first of all here ishow I declared the function within Labview:
uint32_t IowKitWrite(uint32_t devHandle, uint32_t numPipe, uint8_t *buffer, uint32_t length);
* The first argument is the dongle handle which is the output of the function IowKitOpenDevice(void)
* The second argument is the pipe number : "The IO-Warriors have two communication channels. In USB terminology this is called an interface or pipe. Pipe 0 is used to directly access the I/O pins, whereas pipe 1 allows access to the special functions of the IO-Warrior". So you should set it to 1.
* The third argument is the write request to be sent to the IIC. It has to be formatted as a Report. A report is a USB thing, always of 8 bytes long.
* The last argument is the length of the report, i.e. length=8
According to IOWarrior's datasheet, page 15, this write request Report is made of the following bytes:
0 ReportID=$03
1 count
2 command
3 0
4 0
5 0
6 0
7 0
"command" holds the command byte to be send to
the IIC. "count" is the number of bytes that should
be read off the IIC after sending the command
byte, values 1 to 255 are valid (Multiple reports
may be returned in reaction to a read request).
Data is returned in input reports with ID=3. The
data is returned in chunks of up to six bytes each
with an error flag and byte count.
=> The command would be hF3 in your case.
=> You have to check with your specific device, but in my case I set count=4, because in the data report sent back by the device I expect :
* ReportID (1 byte)
* flags (1 byte)
* up to 2 data bytes
I suppose you can set count=8 to be safe. On the contrary, I think that if you set this value too low, something goes wrong.
In terms of Labview programming, you have to build an array with all these bytes in the right order and wire it to "buffer".
"YES... It might be a 12 bit value? But how so for 65,535? That is a 16 bit value... 2^16=65,535..."
I dunno. You can try assuming 12bit and 16bit and comparing with what the software says. Pressure should not change rapidly if the device is left unperturbed.
"I am not sure what to pass to this parameter? I say this because I do not get the expected value at the 0 flow as this value is near 32,767 and the high value, at full scale, is 65,535... Works BEAUTIFULLY with their Sensirion application but they do not tell me how to grab this value."
First of all, here is how I declared the function:
uint32_t IowKitRead(uint32_t devHandle, uint32_t numPipe, uint8_t *buffer, uint32_t length);
This time, the buffer is to be received, not sent, hence you have to wire an empty array control to it, to store the incoming values. If you expect more than 1 USB Report, you will have to store the successive 8 bytes buffers, but that should not be the case.
After that, you will have to chunk the report into pieces. According to IOWarrior's datasheet, page 15, this report is made of the following bytes:
* 0 ReportID=3 (you can discard this byte, or check it is equal to 3 as expected for error handling)
* 1 flags (see below)
* 2-7 data
flags contains the following bits:
7 - error, set if slave does not ack command byte
6 - unused, zero
5 - unused, zero
4 - unused, zero
3 - unused, zero
2 - data count MSB
1 - data count
0 - data count LSB
You can discard the flags or check the values of the bits for error handling (this is why I created a "byte to binary" sub-VI).
Whatever your value is 12 or 16 bits, it should be contained in the first 2 data bytes, i.e. in byte #2 and #3. Then you can try to interpret it as 12 bit and 16bit and check which one makes sense.
"I will ask Cade to help here if you can give me your LV version."
I am using Labview 8.6.1
"Since I can talk to it and see values coming out I would assume I am but I do not know and I do not think Sensirion has people who know the answer to that question. Do you think that since I can get SOMETHING out that I am using the right protocol?"
Yes, I think so.
According to the SDPXXX datasheet, the protocol is IIC (I²C) and not Sensibus.
Hence, you should initialize communication using the IowKitWrite function as follows:
uint32_t IowKitWrite(uint32_t devHandle, uint32_t numPipe, uint8_t *buffer, uint32_t length);
* devHandle
* numpipe = 1
* buffer = (report, see below)
* length=8
Report bytes:
* ID=1
* enable=1
* flags=(see below)
* timeout=0 (writing a zero sets timeout to 256x500µsec)
* 0
* 0
* 0
* 0
flags is used to deactivate the internal pull up
resistors for SDA and SCL (only on IOW24) and/
or select the use of the Sensirion protocol:
7 - Disable Pull Ups (1 = disable) - IOW24 only
6 - Use Sensibus Protocol (1 = enable)
5 - unused, write zero
4 - unused, write zero
3 - unused, write zero
2 - unused, write zero
1 - unused, write zero
0 - unused, write zero
Bit 7 - "Disable Pull Up" is available only on
IOW24. When this bit is set the internal pull up
resistors of the IIC pins are disabled. The status of
the pull up resistors can not be changed while the
IIC function is active. Disabling and again
enabling the IIC function is necessary to change
the status of the pull-up resistors.
Bit 6 - "Use Sensibus Protocol"
So in your case, flags=00000000
I think that the pull up transistor of the dongle should be left enabled (first bit=0) because your device needs it but has none included ("The recommended pull-up resistor value depends on the system setup (capacitance of the circuit or cable and bus clock frequency). In most cases, 10 kO is a reasonable choice.")
In my SHT75 device (as in the SHT2X) a pull up transistor has been added internally so the one of the dongle must be disabled, it seems.
Good luck.
