I don't have an answer for you Joe, but this thread has a link to I2C material that might help:
http://www.picbasic.co.uk/forum/showthread.php?t=16067
Robert
I don't have an answer for you Joe, but this thread has a link to I2C material that might help:
http://www.picbasic.co.uk/forum/showthread.php?t=16067
Robert
Hi Demon,
I read the material at the link and used the info to create I2C communication using SHIFTIN and SHIFTOUT. This method transmits all the required info and can be seen on the 'scope. The sensor in use, still NACKs each byte. This method allows you to ignore the NACKs but the info received is not meaningful. I'm still at a loss to communicate with the sensor. My project is not going well. Hope someonecan help.
Joe Rapoza
If the first byte is always nack'ed, then there is definetely something wrong. The first byte should always be ACKed if the slave part is functioning and the address is correct. Do you have pullups on the two I2C lines?
Also the PIC Basic Pro manual recommends not using a constant for the address byte. So either skip the address or use a byte variable.
i.e. I2CWRITE PORTA.1, PORTC.1, $4E, , [$A0, $00, $00]
Tim Barr
Hi Tim,
I tried the variable byte for the command. ie skipping the command byte and putting it in the data fields. (I2CWRITE PORTA.1, PORTC.1, $4E, [$A0, $00, $00] )
It does transmit the $4e , the $A0 and one $00. It does however, NACK all bytes. It does not go into command mode. Only status data when trying to retrieve alarm info is returned with a 0x02 meaning it was NACKed.
Still at a loss.
Joe Rapoza
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
Last edited by Demon; - 9th February 2012 at 18:09. Reason: merged post from below, added Melanie's thread
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.
Last edited by falingtrea; - 17th February 2012 at 19:58.
Tim Barr
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
Bookmarks