iic question
tholberton
Posts: 41
I'm writing an assembly routine for iic, and I realize that the other device is suppose to send an acknowledgement bit.
I'm just not really sure how the pin on the prop is suppose to sense that acknowledge bit, because the pin gets set to
an output right beforehand in order to set the voltage high on the other device. Can anyone explain this to me?
I'm just not really sure how the pin on the prop is suppose to sense that acknowledge bit, because the pin gets set to
an output right beforehand in order to set the voltage high on the other device. Can anyone explain this to me?
Comments
To send a low signal (or clock) the Prop pin is set to an output (it always stays low). For a high bit (or clock) the pin is switched to an input. The pull-up resistors should bring the line high while the pin is in an input state. In the input state you should be able to read the incoming ack.
A pull-up doesn't drive a line high as fast as if the Prop were setting it high. I think it's possible this delay can contribute to making I2C communication slower than other alternatives (though I think the addressing required in I2C is the main speed killer).
Not all the I2C objects obey this rule (of using an open drain) and drive the pins high (which is against the rules) so you'll need to check the object you're using to make sure it's not driving pins high.
Then I don't understand what you mean here:
An I2C "transaction" consists of 9 clock cycles of which 8 cycles contain data sent to the 'slave' device. The 9th cycle is for the acknowledge from the slave device. Key item: the acknowledge is a LOW, not a high.
So during that 9th cycle, the Prop pin used as the I2C SDA must be set as input and the state tested to see if the slave pulled the input low - indicating that it received/undestood the previous 8 bits of data. If the slave did not understand, then it just allows the SDA line to be pulled high by the pull-up resistors.
Did that make sense?
Go here for all you would ever want to know about the I2C bus:
http://www.i2c-bus.org/
I'm still trying find an explanation of how that works from a circuit perspective, but at least I can keep writing code now.
..welcome - happy to help!
:thumb: