In the following code What does the 2 HI2CSend ( 0) accomplish ????
I have also seen a HI2CSend (9) in other code
I've looked at the I2c spec and havn't found any ref to
0-0 or 9. Its seems like I did see 0-6 but can't find it now....
for DeviceID = 0 to 255
DisplayNewLine = DeviceID % 16
if DisplayNewLine = 0 Then
HSerPrintCRLF
HserPrint hex(DeviceID)
HSerPrint ": "
end if
HSerPrint " "
HI2CStart
if HI2CWaitMSSPTimeout <> True then
HI2CSend ( deviceID )
if HI2CAckPollState = false then
HSerPrint hex(deviceID)
Else
HSerPrint "--"
end if
HI2CSend ( 0)*****
HI2CSend ( 0)*****
end if
HI2CStop
next
HSerPrintCRLF 2
HSerPrint "End of Search"
HSerPrintCRLF 2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
google chatt---- below , you never really answered..... The previous code is from I2c Discovery and it clearly shows HI2CSend (0) which conflicts with the google statement !!!!!
I need to know explicitly where.
You do not need to set tab first
it equates to 9 spaces
in i2c discovery makes sense for (9) and (7) but not (0). So, I need to see to explain.
this is a lot of code to remember. ☺
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a discovery protocol. The 0s are part of the discovery. To restate these are nothing to do with a protocol conversation with a specific device.
So, rather than prolonged posting ping me on Google chat.
The question I will be asking. .. what outcome are you trying to achieve?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The discovery protocol was determined by imperial testing leveraging the defined I2C protocol.
The discovery protocol is:
StartSend8bitaddressSendZeroSendZeroStop
What are the details of the protocol?
The initial start command is required to commence the protocol. The Data and Clock lines should be set appropriately by the hardware or software methods.
The DeviceID send 8 bit address (0-255) sending an address onto the I2C bus. This therefore sends READ and WRITE addresses alternately. Where the next two commands below ensure the i2c protocol is followed.
Send Zero. There are two cases.
Case #1: Where the 8 bit address is a read address the i2c device will move to device address and the i2c device will respond with a value. This returned value is not use - as this is not an important response.
Case #2: Where the 8 bit address is a write address the i2c device will move to device address and await the data to write. See the next command.
Send Zero. Again, there are two cases.
Case #1: Where the previous 8 bit address was a read address this force the i2c device to send the next byte of data. Again, this is not important with respect to i2c discover.
Case #2: Where the previous 8 bit address was an write address - the i2c device will write a zero to device.
Send a stop. The Data and Clock lines should be set appropriately by the hardware or software methods.
Note: At stage 3 is the I2c device is present then the I test the clock line. Testing the clock line is part of the i2c protocol. If the line is High then we know the i2c device is present = result.
So, why do we need to send two bytes? To cater for the read and the write addresses. We could adapt to send one zero byte but empirical testing proved that if I send one byte some EEPROM and Clock devices locked the I2C bus.
I hope this explains the discovery protocol.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the following code What does the 2 HI2CSend ( 0) accomplish ????
I have also seen a HI2CSend (9) in other code
I've looked at the I2c spec and havn't found any ref to
0-0 or 9. Its seems like I did see 0-6 but can't find it now....
for DeviceID = 0 to 255
DisplayNewLine = DeviceID % 16
if DisplayNewLine = 0 Then
HSerPrintCRLF
HserPrint hex(DeviceID)
HSerPrint ": "
end if
HSerPrint " "
HI2CStart
if HI2CWaitMSSPTimeout <> True then
HI2CSend ( deviceID )
if HI2CAckPollState = false then
HSerPrint hex(deviceID)
Else
HSerPrint "--"
end if
HI2CSend ( 0)*****
HI2CSend ( 0)*****
end if
HI2CStop
next
HSerPrintCRLF 2
HSerPrint "End of Search"
HSerPrintCRLF 2
We discussed this in our Google Chat. Please check the transcript of our very long conversations.
google chatt---- below , you never really answered..... The previous code is from I2c Discovery and it clearly shows HI2CSend (0) which conflicts with the google statement !!!!!
I need to know explicitly where.
You do not need to set tab first
it equates to 9 spaces
in i2c discovery makes sense for (9) and (7) but not (0). So, I need to see to explain.
this is a lot of code to remember. ☺
This is a discovery protocol. The 0s are part of the discovery. To restate these are nothing to do with a protocol conversation with a specific device.
So, rather than prolonged posting ping me on Google chat.
The question I will be asking. .. what outcome are you trying to achieve?
Where do we find this chat you speak of????
The discovery protocol was determined by imperial testing leveraging the defined I2C protocol.
The discovery protocol is:
What are the details of the protocol?
Case #1: Where the 8 bit address is a read address the i2c device will move to device address and the i2c device will respond with a value. This returned value is not use - as this is not an important response.
Case #2: Where the 8 bit address is a write address the i2c device will move to device address and await the data to write. See the next command.
Case #1: Where the previous 8 bit address was a read address this force the i2c device to send the next byte of data. Again, this is not important with respect to i2c discover.
Case #2: Where the previous 8 bit address was an write address - the i2c device will write a zero to device.
Note: At stage 3 is the I2c device is present then the I test the clock line. Testing the clock line is part of the i2c protocol. If the line is High then we know the i2c device is present = result.
So, why do we need to send two bytes? To cater for the read and the write addresses. We could adapt to send one zero byte but empirical testing proved that if I send one byte some EEPROM and Clock devices locked the I2C bus.
I hope this explains the discovery protocol.