Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support for Start/Stop (non Repeated Start) reads? #14
I'm not familiar with the I2C conventions but it seems that some implementations (notably the Raspberry Pi, see this answer http://raspberrypi.stackexchange.com/a/7142/12232) use a STOP/START sequence rather than a START sequence when performing a I2C read e.g.
[ 3 0 ] [ 2 r r r r r ]
[ 3 0 [ 2 r r r r r ]
Is this something that the TinyWire library can be made resilient to? Is this something that should be supported?
Tinywire does not care, neither should any of my examples (in fact the star/stop events are not even exposed to the user code). BUT Raspberry Pi has a I2C master that cannot deal with a slave that does clock-stretching and on attiny85 @8MHz the slave will always stretch the clock.
Hmm if that is the case then I am at a loss - I have tried reducing the Baud rate of the I2C bus down to much lower rates progressively from 100kbps, to 32kpbs, 10kbps 1kbps and even 500bps and the results are progressively improved but always break down after enough block reads.
The code I am using is https://github.com/rambo/TinyWire/blob/master/TinyWireS/examples/attiny85_i2c_slave/attiny85_i2c_slave.ino and so should not be using too many cycles to process each read - is it really the case that clock stretching is always used?
The ATTiny85 is running at 8MHz on an internal clock at 3.3V. The Raspberry Pi code is Python using the
The streching happens already at when tinywire (on the library level) checks if this is our slave address or not. In theory on low enough clock speeds the streching should not matter any more but for practical speeds you will hit http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html often enough for things to be unreliable.
You can use this sketch on an ATMega328 based Arduino (Uno, Duemilanove etc) to verify that things work correctly with a properly working I2C master: https://github.com/rambo/I2C/blob/master/examples/i2crepl/i2crepl.ino
I found a few things that might be of interest
I tried out the code you posted here https://github.com/rambo/I2C/blob/master/examples/HMC5883L/HMC5883L.ino on an UNO and using the
Generally I found about 5 to 20 read errors in every 10,000 reads. I took out the Wire.endTransmission() and it worked perfectly (presumably this gives true repeated start rather than the stop-start). This was similar behaviour to what I was finding on the Raspberry Pi after lowering the Baud rate to 32,000. Final code snippet below (for device at address 0x05)
I think the problem is the ATTiny code occasionally not hitting the Stop check in time even though it was the only bit of logic in the
So it seems Raspberry Pi with the out-of-the-box
Most libraries for RPi just wrap the SMBUS commands but the PiGPIO library provides a deamon that you can call in Python to 'bit bang' at the level of the bus-pirate notation and it support clock stratching. To read using repeated-start, try the following
This worked without error for as long as I tested (100,000 reads)
Sorry for long comment but I wanted to make sure that user of my device could use the ATTiny85 with out-of-the-box components as much as possible.