I started playing with i2c (or two-wire) on the Rpi. I quickly found problems when talking to i2c slaves that are usually some sort of embedded processor (mostly AVR’s). The problem is that the current i2c driver in Raspbian “wheezy” has a hard coded timeout flag. I2C is facilitated by a Broadcom 2835 chip that has multiple types of I/O. There is a drive for this chip that maps the different types of I/O to /dev/ devices.
I’ve had this problem with blinkm’s and Sparkfun’s 7 segment serial/i2c board (both use AVR’s). I also tried smbus and quick2wire. What makes this problem maddening is that the timeout is problem very close to the actual timing and will fail sometimes but not others.
Back to the problem: if the i2c slave does not ACK a command within a certain number of rpi clock cycles, then the driver returns errno 5. On the i2c slave side, the AVR (or other processor) may be do work in response to a command. If the slaves waits to long, the timeout gets exceeded and the Linux driver returns that pesky error. Until this is fixed at the driver level, people are going to have to live this annoyance. Edit: Reading from smarter people: this is a really a chip set issue. The best solution is to use an I2C chip set that handles this in hardware. Fixing it in software (at the driver) level is just kludge.
To me this is more than an annoyance, it’s pesky and makes the i2c nearly unusable. There are a few work arounds:
- Reduce (or changed) the i2c bus frequency
- Rewrite the firmware on the i2c slave to immediately return the ACK
- Catch the errno 5 and repeat until success