Hi Jean, > > The I2C standard reserves addresses 0x03-0x07. Adapt our tools to that. > > I have a different interpretation of the specification. Addresses > 0x04-0x07 are marked as "Hs-mode master code". They are not explicitly > marked as "reserved" (although admittedly the table is named "Reserved > addresses"). My understanding is that HS-mode will "use" these Yes, my understanding is that the table lists all reserved addresses. > addresses, which means that you can't use HS-mode _and_ slaves at > addresses 0x04-0x07 on the same I²C bus segment. I do not read this as > "non-HS-mode slaves can't use these addresses". But maybe this is just > me, and also I don't know that much about HS-mode really. From the spec, section 5.3.2: "Hs-mode master codes are reserved 8-bit codes, which are not used for slave addressing or other purposes." > Address 0x03 is indeed reserved, so obviously that this really makes me > wonder how the original range of 0x03-0x77 was decided. Unfortunately > the git history doesn't go that far (this range was already used in > i2cget and i2cdetect at the time i2c-tools was split to its own > repository). My theory (only guessing, I didn't check): When introducing Hs-mode, the I2C designers wanted to have the possibility for 8 Hs-masters. So, they took addresses 0x04-0x07 (and the R/W bit) which allows for easy logic in HW. And 0x03 was marked "reserved for future use" because it was in the middle of those two reserved blocks. That would mean that before Hs-mode, addresses 0x03-0x77 was in deed possible. > That being said... In the end it doesn't really matter if addresses > 0x03-0x07 are considered reserved but "should not", as long as the user > has an option to override that limitation. Now that such an option is > consistently available for all i2c tools, I have no objection to being > more conservative by default. Cool, I read this as an ack. Thanks! Wolfram
Attachment:
signature.asc
Description: PGP signature
