MPR121 Requires Repeated Starts
The MPR121 uses I2C to communicate with its host. There are over a hundred registers in the MPR121 that can be read. From a functional standpoint, it would look something like:
uint8 value = read_register(uint7 addr, uint8 which_reg)
On the I2C bus, the bits/frames look something like:
| Start | addr/W | which | R-Start | addr/R | data | Stop |The Repeated Start allows the host to hold the bus during this "write which register we want, now read it" transaction. If a normal Stop-then-Start sequence was performed, then you have a time where the bus was released, allowing another I2C master to take control. That race condition could allow the other master to change the register-to-read. The original I2C master would then get bad data.
The requirement for a Repeated Start is eminently sensible in a multi-master environment, although the MPR121 documentation does not call out this requirement. My own experimentation and a bit of Google action confirms this. Sensible, yes, but poorly documented. (Though I have to say: the MPR121 doc and application notes are overall very outstanding! Usually, I use their I2C timing diagrams rather than the formal I2C specification)
It is also important to note that most environments are single-master, so a Repeated Start wouldn't be necessary, and the requirement is a potential burden upon the I2C master (compared to a standard write/read pair of operations).
BCM2835 Lack of Repeated Starts
My test code was using the Python "smbus" module to speak I2C to the MPR121 breakout. Everything was quite straight forward, and there are several tutorials and pages on the web to show you how to set up I2C on an RPi, and to use Python to control it.
But when I tried to read the "touched" results for the 10 pads (two bytes), I kept getting the same byte values. The first byte (in register 0x00) has the first eight pads, and the second byte (at 0x01) has the next four. But that second byte was always the same, and changed right along with the first byte as I touched various pads.
After thorough digging through code, trying alternative approaches, oscilloscope review of the I2C bus, etc, it became apparent that upon receiving a Stop condition, the MPR121 would reset the which-register value to 0x00. Thus, I'd tell the MPR121 "read from 0x01. Stop. give me the byte.", and it would always return the value from register 0x00.
After further investigation and reading: the BCM2835 does not implement Repeated Starts. There is no way for it to read from arbitrary registers of the MPR121. Some people have attempted gimmicks around the BCM2835's 10-bit addressing feature, but I'll avoid that.
However, you can read all the sensor data by reading two bytes, starting at register 0x00. I2C supports a block data transfer, so this is quite straightforward. In fact, the host doesn't ever have to say "start reading from 0x00" since that is the default. It can just issue a read for two bytes.
In order for an RPi to read arbitrary registers, it would be necessary to use "bit-banging" on the GPIO pins to manually run through the I2C protocol. Code out there exists, if this feature is needed.
Summary
In my research, I found there are a number of I2C peripherals that require a Repeated Start. Presumably for transaction purposes (as noted above). Most work just fine with a Stop/Start pair, which will work in the typical single master environment.
In my home automation scenario, the host will (always?) be a PIC16F688 microcontroller running my own I2C master code. Needless to say, it will incorporate the Repeated Start capability.
Hopefully, my research will help your own use of an MPR121, or the I2C bus on a Raspberry Pi.
