eMGoz: Enlarge I²C Device Count with Chip Selects?

This is only a quick write up on my idea, and I haven't got the time to include a few illustrations / schematics to state my point. If it is too long for you to read, only focus on the last paragraph which describes the solution.

Introduction

I²C is great, probably the simplest way to hook up peripherals to a microcontroller. You only need two connect two wires to the device you want to interface with - clock and data. These two wires are shared between all the I²C devices. To select a specific device to talk to, the 7 bit address is sent to all the devices on bus, those compare this address to their own and only the one with the same address becomes active. This way, it is possible to interface with up to 112 (2^7 minus 16 reserved addresses) I²C devices on one bus. Sounds like that's a lot, but what when you cannot use them all?
While working on a new project, I stumbled upon a problem: I want to have a lot of the same I²C device on one bus. Well, usually the manufacturer of the peripheral ensures the possibility to select the address - or a part of the address - by offering one or more address select pins. There are a lot of different approaches on how to select the address:

Tie the pin to GND or VCC (-> one address Pin doubles the amount of possible devices)
Leave the pin open or use one of the above (-> one address Pin triples the amount of possible devices)
Tie the pin SDA, SCL, GND or VCC (-> one address Pin quadruples the amount of possible devices)
Tie the pin with a specific resistor to Ground (-> usually up to 4 or 5 possibilities)

In most cases, this is absolutely sufficient. However, I wanted to connect 5 MPR121 for a lot of capacitive sensors and this chip offers only one address select pin (using the third approach I described above) for up to 4 different addresses. I am sure that other people encountered a similar problem so I did some research. These are some of the options I found:

Use an I²C bus splitter / switch / multiplexer!

Ok, cool, that gives me two independent I²C busses, with 112 addresses each. Problem solved.
Well... not quite. What if you don't have enough space on the board to place another IC? Or what if you don't want a loss in speed (The configuration of the Multiplexer is usually also done with I²C)? Ok, I²C is slow anyway, no need to make it even slower.

Use a second microcontroller or one which has more than one I²C bus!

The result is probably the same like in the idea above.
But, come on! You probably have already done a lot of development on the other platform and you don't want to change it a this point. In addition to that, there are only few microcontrollers which support two I²C busses.
[ Edit: I'm speaking of hardware I²C support. I²C is such a simple protocoll that you can bit bang it in a few lines of code on any microcontroller, since there is no clock frequency or baud rate specified. It's still way slower and less elegant than the hardware port though. ]

Use SPI, it's faster anyway!

SPI solves the problem by not using a limited address space. It uses chip select lines from the controller to the peripheral. Unidirectional data lines also speed up the communication. Great.
However, you need 3 common wires and a for each device additionally a chip select line, which becomes quite nasty when interfacing a lot of peripherals.
Five devices are not many, so why not give it a try? The answer is simple: Most chips (in my case the MPR121) only come with I²C.

But there are other chips that do the same and support I²C and SPI!

Yeah, you can look for similar chips that also support SPI, in my case there is also the CAP1188 which supports both interfaces and has 5 I²C addresses! Ok, when this one offers 5 addresses, I don't even need to bother with SPI in the first place?! Wrong. This chip does basically the same as MPR121, however has only 8 capacitive touch inputs, in contrast to the MPR121 with 12 inputs. For 60 capacitive pads you would need 8 of the CAP1188 and use SPI with many digital wires - 11 to be exact. Also, the chip is larger since it has additional LED outputs I don't need. I'd also need to spent a lot of time changing the software to a new touch controller.
[ Edit: There is also the CAP1114 with 14 inputs, however you cannot buy any breakout boards (yet)
Edit 2: The CAP1114 has no address select pin. What a bummer.]

Okay, so to conclude, all of these "solutions" solve the problem one the one hand, however come with some major tradeoffs on the second hand. More and larger ICs or setbacks in development.

The solution

Suddenly, an idea came to my mind. Why not use I²C just like SPI - with a chip select? I²C devices don't have a chip select pin, but the address select pin. Why hardwire it to VCC or GND, just hook it up to a GPIO on your microcontroller. There, you select all of them with the same address, the address with the pin tied to ground - and the software controls which one that is. Only the one with the address pin pulled low will activate, the others have the address pin high and therefore listen to another address. Actually that means there are several chips with the same address, but as long as the controller only talks to the device with the address pin pulled low, there won't be any interference.

In case you have concerns regarding the address change while the device is running, I tested it and there were no problems with that. Apparently the address pin is read each time there is data transfer on the bus, not on power on and then saved in a register or something.

I absolutely did not find anything on the internet about this idea. Why?

Is it against the specification of I²C? Come one, we're hackers!
Is it two slow to be practical? The whole address byte is now redundant.
Are there better solutions?
Or am I the only one that thought of this?!

Let me know what you think!

Edit: Thanks Hackaday for featuring this article, which also led to an interesting debate about this topic. You might also want to check out the comment section there as well.
To sum up some of the thoughts:
Apparently Microchip designed some devices (e.g. the 24LC256 EEPROM) to also work like this and notes this in the datasheet. In contrast, it seems that some more complex devices - which are themselves MCU based - will not work, since they read the address pin once on power up and then store it in a register.

-Marv