I'm learning about I2C, and I read that an I2C device can have one of 128 different adresses, numbered 0 .. 127. Right? But just now I saw the well-known I2C-scanner on Arduino Playground - I2cScanner , and there's something that confuses me: it seems to only scan adresses 1 to 126!
for(address = 1; address < 127; address++ )
{
Wire.beginTransmission(address);
error = Wire.endTransmission();
...
My question is: are 0 and 127 valid addresses or not?
numbered 0 .. 127. Right?
No, there are reserved I2C addresses. See this page.
For years I've been trying to stamp all the i2c scanner sketches/examples that start scanning at i2c address 1 since 0 to 7 are not valid i2c addresses so they are reserved and are not to be used for slave addressing.
So far, I've not had very good success getting people to fix their code.
Sometimes people update the code, and some times it even reverts back.
In the AVR platform, I finally got them to fix the slave the master examples in the Wire library to use 8 instead of address 1 but it looks like the i2c_scanner is still broken (wrong) by starting at i2c address 1 which is not a valid i2c slave address.
Nick fixed his I2C scanner on his page: https://gammon.com.au/i2c
But it is still incorrect on the playground page and in the i2c_scanner example that comes with the AVR platform Wire library.
The bottom line is a scan for slaves should start at i2c address 8 not 1.
If you start at 1, it can cause a lockup on some platforms that support some of the additional functions.
Note:
I created an issue for the i2c_scanner in the AVR platform Wire library:
--- bill
So an I2C scanner should not be used to identify I2C devices that have been setup with incorrect addresses ?
srnet:
So an I2C scanner should not be used to identify I2C devices that have been setup with incorrect addresses ?
I'm not quite sure what you mean by that.
According to the i2c spec, slave i2c addresses 0 to 7 don't exist - they can't
The electrical patterns created on the bus for those "addresses" have special meaning which is why they don't exist.
(See the page that GroundFungus provided for details)
Certain implementations like the AVR platform Wire code are incomplete and non conformant and allow using those addresses, which they shouldn't.
But if you attempt to use those addresses on other platforms, it can confuse the master h/w, s/w, and/or slaves and cause a lockup condition.
Any implementation that allows using slaves addresses 0 to 7 is non conformant with the i2c specification.
The best thing is to conform to the i2c spec and that means staying away from those reserved addresses because they are not valid to use for a slave address.
Since attempting to use slave addresses of 0 to 7 by the master creates bit/timing patterns on the bus that have special meaning and do not represent a slave address, the master should never do a scan for addresses below 8.
--- bill
The bottom line is a scan for slaves should start at i2c address 8 not 1.
Even if the lowest given slave i2c address should be 8, I find it quite interesting to have a scanner which might identify lower addresses in the bus. Either because someone has incidentally used a lower address, or because a device is responding on one on these addresses.
noiasca:
Even if the lowest given slave i2c address should be 8, I find it quite interesting to have a scanner which might identify lower addresses in the bus. Either because someone has incidentally used a lower address, or because a device is responding on one on these addresses.
Again, according to the spec, addresses 0 to 7 don't exist. They can't because they create bit/signal patterns on the bus that have meaning.
They can't be used for slave addresses because any attempt to do so, creates a pattern that has special meaning vs addressing a slave.
Addresses 1 to 7 do happen to work on the AVR platform but only because the AVR code is not properly interpreting the SDA signal correctly.
This is not the case for other implementations that are more complete/complaint with the spec.
So while you may be able to get away with an "address" between 1 and 7 on the AVR, they are not valid i2c slave addresses and only work because the AVR code is incomplete/non compliant and not behaving properly.
If there are real slave devices based on commercial chips on the bus they will never have an address below 8.
The only way to have a slave with an address below 8 on the bus is if you have a master and slave that do not handle/interpret the SDA signals properly.
For example you can use addresses 1-7 on the AVR platform because the master and slave code are non compliant and don't properly handle the SDA signal so they can misinterpret the signal to see slave addresses 1 to 7.
Had the AVR Wire h/w and s/w library been handling SDA correctly, those addresses can't exist because their bit patterns have special meaning.
--- bill
bperrybap:
So while you may be able to get away with an "address" between 1 and 7 on the AVR, they are not valid i2c slave addresses and only work because the AVR code is incomplete/non compliant and not behaving properly.
And so it can be useful (in the Arduino environment) to have a scanner that will report devices that are setup 'incorrectly'
Again, according to the spec, addresses 0 to 7 don't exist.
to be precise: it's not compliant.
I can't prevent someone to set up a non compliant slave.
Can you?
The only way to have a slave with an address below 8 on the bus is if you have a master and slave that do not handle/interpret the SDA signals properly.
For example you can use addresses 1-7 on the AVR platform because the master and slave code are non compliant and don't properly handle the SDA signal so they can misinterpret the signal to see slave addresses 1 to 7.
And this gives me reason why I want a scanner which identifies these non compliant slaves also.
Encourage the people to adopt the wire.cpp to reject addresses below 8, a compiler warning, an exit... whatever. Fight the root cause!
Let them add comments to the slave examples never to use something below 8,
Let them add a comment in the scanner, but leave the loop as it is.
srnet:
And so it can be useful to have a scanner that will report devices that are setup 'incorrectly'
Not really.
For example, if you run that code that starts at address 1 on a pic32 platform, it will lock up the system.
I'm sure that there are also many slave devices that can get confused and may also have issues, especially ones that support 10 bit addressing.
Again, it isn't just that the addresses in the slave are set up incorrectly, you have to have a system that has incorrect h/w and/or s/w on both the master and the slave which misinterprets the SDA signal to even allow it because i2c slave addresses 1 to 7 don't exist - they can't.
For the most part the only way you can have a slave with an address under 8 is if you use an AVR with your own code that set the slave address to one of these non existent addresses.
And in that case, you will already know the address.
--- bill
bperrybap:
For the most part the only way you can have a slave with an address under 8 is if you use an AVR with your own code that set the slave address to one of these non existent addresses.
Well this is the Arduino forum and some Arduinos use AVRs.
noiasca:
to be precise: it's not compliant.
Addresses 1 to 7 don't exist. They can't according to the i2c spec.
Look at the spec and timing and wave form created by attempting to use slave address 1 to 7.
The timing patterns on SDA for those "addresses" have special meaning and because of that, they can not be used to address a slave at those addresses.
That is how it is defined in the i2c spec.
If you are saying that addresses 1 to 7 exist, then you are saying that the SDA signals should be interpreted differently than what is in the i2c spec.
I can't prevent someone to set up a non compliant slave.
Can you?
Nobody can stop people from trying to violate the spec.
But that still doesn't make those addresses exist according to the I2C spec.
They can't exist according to the spec.
They only way they can "exist" is if both the master and the slave choose to interpret the SDA signal differently than how it is specified by the i2c spec.
No commercial product will use an address below 8. They just won't because those addresses don't exist according to the i2c spec. All the i2c slave addresses for devices are assigned and none are or will ever be assigned to 1-7
And this gives me reason why I want a scanner which identifies these non compliant slaves also.
But in order for it to work, you need more than a sketch that starts a scan loop at address 1
You also need a Wire h/w and s/w implementation that misbehaves on both the master and slave side that ignores the special functions created on SDA by the bit/timing patterns created by attempting to use these address
i.e. both master and slave must interpret the SDA signal differently than what the spec says to use and "see" these slave addresses.
Not all Wire h/w and s/w implementations choose to interpret the SDA signals differently than as defined by the spec in a way that allows using these lower slave addresses.
If you attempt to use these slave addresses, it can cause issues, including a lockup in certain environments since according the i2c spec, using these "addresses" creates special conditions on the bus rather than addressing a slave.
Yes, I believe the Wire library should be dealing with this and should have been from day 1.
The Wire library should immediately error off any attempt to use these low addresses since they don't exist and any attempt to use them ends up generating i2c special conditions on the bus.
It is only when the slave misinterprets SDA that these special conditions will be instead interpreted as slave addresses.
To start the loop at 1 is expecting that all the devices on the bus are misinterpreting the SDA signal the same way and in a way that ignores the special functions defined by the i2c spec and allows using the bit pattern as a slave address.
Not all implementations do this and any implementation that follows the spec will not do this.
--- bill
srnet:
Well this is the Arduino forum and some Arduinos use AVRs.
Sure.
But keep in mind that just because you build the i2c scanner sketch on the AVR platform and start scanning at address 1 instead of 8, it does not ensure that it will work.
If you have more advanced slaves on the bus that do support these additional i2c bus functions/conditions created by attempting to use addresses 1-7, there may be issues, since they will see a master that is babbling garbage and on the bus, specifying some special functions/conditions as those first 7 addresses are being probed.
It is best to stick to what the i2c spec says and not intentionally violate it.
--- bill
Addresses 1 to 7 don't exist. They can't according to the i2c spec.
i2c addresses below 8 exist.
NXP calls that range: reserved addresses.
3.1.12 Reserved addresses
UM10204I2C-bus specification and user manualRev. 6 — 4 April 2014
There is a big difference if someone says that the address exists or if a slave can/should/must not have that address.
noiasca:
i2c addresses below 8 exist.NXP calls that range: reserved addresses.
3.1.12 Reserved addresses
UM10204I2C-bus specification and user manualRev. 6 — 4 April 2014
There is a big difference if someone says that the address exists or if a slave can/should/must not have that address since those are not valid i2c addresses.
No, they don't exist as slave addresses.
You are not understanding the spec.
The reason that they call them "reserved addresses" in the spec is that those bit patterns for those slave addresses during the address phase on the bus have special meaning.
As such they should never be used for slave addresses and THAT is why they are "reserved"
Slave addresses 1 to 7 can't exist according to the i2c spec because those bit patterns have special meaning and are not to be interpreted as slave addresses.
Yes, look at table 3 in 3.1.12 but dig deeper than just looking at the heading of "Reserved Addresses".
That table represents the slave addresses that can never be used since those bit patterns during the address phase are reserved for other functions.
Look at the foot notes.
Like I keep saying in order to use them as addresses, you need to have all masters and slaves that are connected to the bus, ignore the specs definition of what these bit patterns mean and simply interpret these addresses as slave addresses.
While the AVR platform Wire code does this, other implementations do not and so starting a scan below address 8 can cause problems.
What is the point of starting below 8?
There isn't going to be any slaves down there and it can cause issues.
--- bill
This debate can be summed up in two sentences
they don't exist as slave addresses
vs
they can't exist as slave addresses
CAN'T implies some arbitrary rule imposed (maybe by man) preventing something
DON'T implies laws of nature or physics preventing something
hzrnbgy:
This debate can be summed up in two sentences
they don't exist as slave addresses
vs
they can't exist as slave addresses
CAN'T implies some arbitrary rule imposed (maybe by man) preventing something
DON'T implies laws of nature or physics preventing something
This isn't a debate.
According to the i2c spec, slave addresses start at 8. Period, end of story.
According to the i2c spec, if you attempt to use slave addresses 0 to 7, they create a bit pattern that is supposed to be interpreted as a special function/condition and are not to be interpreted as a slave address.
Therefore, if your implementation follows the spec, there is no such thing as slave addresses 0-7
They can't exist, (a slave with those addresses can't exist on the bus) since the bit patterns created by attempting to use those addresses are to be interpreted as something other than a slave address.
Bottom line, according to the i2c spec, there is no way to address a slave with an address of less than 8.
Can an implementation not follow the i2c spec and do things differently. Absolutely.
What I have been saying over and over again, is that slave addresses 0-7 don't exist according the i2c spec.
They can't if the implementation follows the spec.
However, some implementations like the AVR platform Wire library do not process the SDA signal according to the spec and incorrectly treat them as ordinary slave addresses.
There can be problems attempting to use slave address 0-7 since not every implementation violates the i2c spec the same way the AVR Wire library does.
For example,
take that i2c scanner which starts the scan at 1 and run it on a pic32 platform. It will not work - it locks up.
Use the the i2c_scanner on an AVR platform with certain slaves (I have an i2c LCD which demonstrates this) and it won't work - it locks up.
But start the scanning at 8 which is where the valid slave addresses start according to the i2c spec, and the code runs fine in both environments.
My main point is that is that it is not a good thing to intentionally violate a specification and that is what attempting to use slave addresses below 8 is doing.
When violating a spec, you can expect to have issues.
--- bill
And it seemed such a simple question at the time... 
Anyway, thank you all, it's clear to me now.
NB.: I also found that, according to RobTillaart, addresses 120 .. 127 are also reserved!
Erik_Baas:
And it seemed such a simple question at the time...Anyway, thank you all, it's clear to me now.
NB.: I also found that, according to RobTillaart, addresses 120 .. 127 are also reserved!
Yes, it was a fairly simple question. Sorry to get you in the middle of all this craziness.
Basically, GroundFungus answered it right off the bat in the first response in this thread by providing a link to a table that shows the 7 bit addresses that are not to be used for slave addresses: Addressing – I2C Bus
If you look at that table you can see that address 0 to 7 and address 0x78 to 0x7f (120 to 127) are not to be used for slave addresses since those bit patterns are reserved for other functions and attempting to use those addresses can trigger those functions.
Because these bit patterns are reserved for special purposes and not for slave addresses, it is best to not intentionally violate the spec by attempting to use slave addresses 0-7 and 120-127 as it can cause issues like a lockup in certain environments or with certain slaves.
I guess the term "reserved addresses" was not good since to some people it may imply that these are valid slave addresses that are simply reserved for some special use. But in reality the addresses are "reserved" because attempting to use those addresses creates a bit pattern on bus that means something other than a slave address.
i.e. according to the i2c spec, there is no way to address a slave in those ranges since using those addresses creates a bit pattern on the bus that can trigger other functionality.
--- bill