I2C Communication, PIC 16F616 to Honeywell humiditysensor HIH6131

[Demon]

EDIT: I finally found Melanie's thread:
http://www.picbasic.co.uk/forum/showthread.php?t=587

Use variables instead of constants.


Typical start-up time is 50 ms by the way.

(sample code from PBP v2.60 manual, bottom p.96)


Referring to datasheet from here:
http://tinyurl.com/7d8jwk9

PBP manual says 4K7 pull-up resistors on both I2C lines. The datasheet says 2K2 pull-up resistors.

PBP supports 100kHz I2C devices up to 8MHz. You need DEFINE I2C_SLOW 1 to run above that.

Robert

[falingtrea]

I was worried reading this thread because I am planning to design in the HIH-6131 for a new product. So I prototyped a HIH-6130 sensor into my design and modified the I2C code. I was able to successfully address the part and get a ACK back. So I have at least verified that the part responds properly, since this is the method used to wake up the part and trigger a measurement. I did make the initial mistake of wiring pins 1 and 2 wrong, (grounding pin 1 instead of pin 2) which gave me the same symptoms you saw. I am using an MSP430 and bit-banging the I2C interface, which gives me a little bit > 100 kHZ clocking.

One thing I did notice is that the documentation implies that you can special order the part with a custom address. Maybe the HIH-6131 has a different address from the HIH-6130? I will need to look into that.

[joerap]

Hello Falngtrea,

I finally got to talk with the design engineer for the HIH6131. He verified that what I have done is valid. He had several suggestions for me to try. None worked and all NACKed every byte. I tried bit banging. I was able to send all bytes attempted. All were NACKed.

After a discussion, it being that I received my samples in August of 2011, it appears that I received preproduction prototypes. And it is also possible that I may have received dummy units intended for a trade show. Honeywell is sending me fresh samples to try. Hopefully, these will work.

You say that you achieved 100 kHZ clock rate. I tried bit banging and still only got 25 kHz. I doubled the processor clock rate and still only got 25kHZ clock rate. Perhaps it is a idiosyncrasy of the processor.

Were you able to get a humidity count from the sensor?

Thanks for the response. Please keep in touch. I may need your advice when I get the new samples.

Joe Rapoza

[joerap]

Hi Tim ,

Just to let you know that I tried another new sample and it worked fine. The first 2 may have been defective or were dummies as the design engineer suggested. ( the mix-up with trade show dummy units). I am able to enter command mode and am now debugging the rest of the program.

Don't worry about the humidity sensors. If you have problems contact Honeywell support and ask to talk with Gordon, the principal engineer for this product. Insist on a conference call. He will have the answers you need.

Joe Rapoza (joerap)

[falingtrea]

Yup, I got my samples to work fine also. In fact, I found an error in my original design that uses the HIH5031 because the values read back from the HIH6131 was so much lower than I read back from the analog part.

[joerap]

Hi Tim,

I noted in my last post that the new samples were working fine. That is, I was able to enter command mode with no problems.

Another situation popped up: When attempting to set an Atarm_low_on limit, It appears to write to the sensor normally. When I attempted to read back what I had written, I received a different value.

Do you have the application note, Entering and Using Command Mode on .....? If so on page 5, configuration steps. Step 8 it shows a read (read bit set) and a $5A (write) to the EEPROM location. Do you think this is proper? When I do this, I see on the 'scopeThat the address is changed ( by the processor,I think) from $4F to $4E. Do you think this should be an I2CWRITE? or a I2CREAD as it appears is suggested?

Just when I thought all was well. Nothing is easy. Let me know if you have the app note. If not I will scan and send the page to which I referred .

Thanks for your help.


Joe Rapoza

[falingtrea]

FYI my copy of the doc shows step 8 with the R/W bit set to Write (0).

It looks like they don't follow a standard EEPROM process for reading and writing.
Writing is pretty straightforward. Write the slave address, then the register address, and then the data to be written using one start/stop.
Now, a typical I2C EEPROM read function writes the starting address, then uses a restart to change the R/W bit, and then reads data. But the Honeywell part, in command mode, looks like it requires a command to be sent to set the address to be read as one I2C transaction, and then a basic read transaction without an address byte to read the register content.
So you would need to do a I2CWRITE to set the register address, and then a I2CREAD with a blank address byte to read the data. It looks like the data read back is the command/status/response byte and 16 bits of register data.