I2C with several masters

[electroRF]

Hi Eric,

I think you're missing an important thing -
When the Master is transmitting, it doesn't ACK or NACK,
Therefore the following is wrong:

The NACK is sent by the Master

 

[ikalogic]

The NACK is not an error. It just means that the slave didn't pull that bit LOW. Interpreting that as an error, or as and of transmission or what ever depends on the design of the higher, "application" layer.

 

[electroRF]

If the Master sent a byte and the Slave did not ACK it (while it did ACK its Slave Address), than that means there's a communication error.
The Slave should ACK every byte sent by the Master, shouldn't it?

I can't imagine a situation where the Master sends the slave a data byte and excpects a NACK.

 

[ikalogic]

I can't imagine a situation where the Master sends the slave a data byte and excpects a NACK.

Actually, as it have been said before, it's the master that sends the NACK.

Here is how it goes:
1- master (M) says to the slave (S) he wants to read @ a certain address
2- Slave acknowledge that
3- Slave start sending the needed data, byte by byte, and with each byte sent from the slave, the master acknowledges it.
4- This continue until the master have enough data, so it does not acknowledge data sent from slave. That means in plain English : "shut up!"
5- only then the master can regain control of the bus

any clearer?

 

[geko]

Actually, as it have been said before, it's the master that sends the NACK.

Here is how it goes:
1- master (M) says to the slave (S) he wants to read @ a certain address
2- Slave acknowledge that
3- Slave start sending the needed data, byte by byte, and with each byte sent from the slave, the master acknowledges it.
4- This continue until the master have enough data, so it does not acknowledge data sent from slave. That means in plain English : "shut up!"
5- only then the master can regain control of the bus

any clearer?

No because in the Microchip timing diagram electroRF posted the master is writing (the R/W bit is low) not reading, so why would the slave device NACK unless the write failed, which is a possibility but confusing because if it's illustrating a 'good' transfer of data on the I2C bus it should show as an ACK (that is the SDA line is held low) as it did when the slave address was sent.

 

[ikalogic]

hmmm.. my bad, didn't look carefully at the graph..

electroRF In that case, i don't have any explanation...

 

[electroRF]

Thats OK, thank you IKA and Geko

Perhaps its an error by microchip.

 

[geko]

Thats OK, thank you IKA and Geko

Perhaps its an error by microchip.

I think it probably is an 'error', and for what it's worth that same timing diagram appears across a number of datasheets including 16F1823 from which I quote

24.6.6.3 ACKSTAT Status Flag
In Transmit mode, the ACKSTAT bit of the SSPxCON2 register is cleared when the slave has sent an Acknowledge
(ACK=0) and is set when the slave does not Acknowledge (ACK= 1). A slave sends an Acknowledge when it has recognized
its address (including a general call), or when the slave has properly received its data.

 

[electroRF]

thanks Geko!

Its cool to recognize datasheet errors

 

[geko]

An error? In a Microchip datasheet? That'd be a !first

Strictly speaking it's not an a error since the slave could generate that signal but I'd say it was confusing in that illustation

 

[ericgibbs]

hi RF,
I thought you were saying that the NACK was a protocol error, not a datasheet error.!
Contact Microchip and bring the suspected d/s error to their attention.
geko,
Microchip often print Errata sheets to correct their datasheet errors, so its not a first.

E

 

[geko]

Microchip often print Errata sheets to correct their datasheet errors, so its not a first.

Indeed and well worth checking for the details of issues in the silicon revisions. I had some of the A6 silicon 12F1822 that didn't signal the end of an ADC conversion and offered less than practical workarounds.