Mistake in I2C protocol?

[iampi31415]

Here the protocol is described: https://docs.rust-embedded.org/discovery-mb2/12-i2c/the-general-protocol.html

1. Should a single image be used? The same one is repeated.
2. Here is an image of what they say vs your description (text):

1. Controller: Broadcast START
2. C: Broadcast target address (7 bits) + the R/W (8th) bit set to WRITE
3. Target: Responds ACK (ACKnowledgement)
4. C: Send one byte
5. T: Responds ACK
6. Repeat steps 4 and 5 zero or more times
7. C: Broadcast STOP OR (broadcast RESTART and go back to (2))

It seems to me that the SUB-ACK is missing, and this would rather be:

1. Controller: Broadcast START
2. C: Broadcast target address (7 bits) + the R/W (8th) bit set to WRITE
3. Target: Responds ACK (ACKnowledgement)
4. C: Sends SUB
5. T: Responds ACK
6. C: Send one data-byte
7. T: Responds ACK
8. Repeat steps 6 and 7 zero or more times
9. C: Broadcast STOP OR (broadcast RESTART and go back to (2))

The "repeat" is not allowed unless SUB uses MSB=1. Something similar happens for read.

[BartMassey]

Thanks much for the careful read!

Don't know where the diagram came from? As far as I can tell after looking around a bit, general I2C doesn't have any special "SUB" or "MSB=1" stuff. Are you looking at documentation for a specific device? The "SUB" here is probably a device register address, which is the "normal" way to use I2C. I can believe that some devices do what you suggested. Looking at the embedded-hal traits, there is nothing that treats any byte in the transaction specially. The traits do support "transaction" mode, where a write can be followed by a "repeated start" to read back without STOP. We maybe should document that in the book, I think.

I am not a big expert on I2C: hopefully someone here can check me. But I think it's OK right now.

[iampi31415]

In the following pages the book refers to https://www.st.com/resource/en/datasheet/lsm303agr.pdf (Section 6.1)

[iampi31415]

This may be more accurate:

The I2C protocol and the description in the LSM303AGR are nearly compatible. Another description at fredscave.com matches the book, for example. PS: that page rephrases soldered.com

The LSM303AGR requires an extra byte named "SUB", after "start" and "addressing" steps. This could be understood as an extra data byte in the book description.

But I interpret the book as saying that we can send multiple bytes of data, whereas the LSM303AGR requires the extra byte named "SUB" to "allow multiple data read/writes."

[BartMassey]

Ah, I see the confusion here. tl;dr: LSM documentation is confusing, the Book doesn't help.

The SUB byte for the LSM is just the register address, as it says in the documentation. The MSB thing is so that you can write multiple adjacent registers with a single I2C write: the register address will be auto-incremented for each byte written. This way you don't have to do whole I2C write cycles for multiple-adjacent-register writes: you can just send the start register address and then the bytes for each register. For example, this lets you write all the CTRL registers starting at 20H with a single write operation. Note that some registers already have addresses with the MSB set; these can't be used with this mechanism, but it wouldn't make sense to for these registers anyhow, as they aren't adjacent to anything. This kind of thing is pretty common for I2C devices, but is below the I2C protocol: it is not incompatible with I2C, but is a way of using it.

We could definitely add a paragraph like the above to the Book: I'll take a look at it at some point unless I get a PR.

[iampi31415]

Thank you, I wouldn't understand that myself.

Another small issue I noticed is that the image here is from wikipedia https://docs.rust-embedded.org/discovery-mb2/12-i2c/the-general-protocol.html and Wikipedia explicitly requires attribution, plus the footer would be useful: https://en.wikipedia.org/wiki/I2C#/media/File:I2C_controller-target.svg

This last bit I can fix eventually.

[BartMassey]

The "Licenses and Attribution" appendix properly credits the image. I think this is sufficient here.