Time to revive this old thread because I notice this problem appears to be a common one and nobody has a satisfactory reason or solution for it.
The BMP180 returns 0xFF.
So yes, I am bit banging the I2C and no I do not wish to use hardware to do it.
This does not solve the issue, it ignores it. As does using libraries.
So to describe the problem in more detail. My I2C code works fine. I use it with other devices.
I can poll the BMP180. Naturally I have my own bit banging scanner which returns a valid I2C address of 0x77 (which translates to 0xEE/EF)
No suprises there. The BMP responds to being addressed correctly with an ACK.
If we write EE and then a sequential bytes, the BMP180 responds to each byte with an ACK. So it is receiving data.
IF we read EF the BMP180 does not respond. It doesn't pull the SDA line low.
So, if I send the following sequence to the BMP180.
S EE D0 S EF .. I expect to see 0x55 from the chip ID
The problem is with the BMP180 datasheet.
If we look at the READ operation
['S] [WRITE 0xEE] {ACKS} [Register address 0xF6] {ACKS} [Restart] [READ 0xEF] {ACKS} {ADC result 0x5C} [ACKM] {ADC result 0x96} [NACKM] ['P]
And we notice that this appears to be correct as per the IC2 standards.
http://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/166/82111.Capture.PNGThis doesn't work.The restart bit is not a restart, but an ordinary start bit.
If we look closely at the level diagram for the BMP180 we can see there is a ['P] stop bit in the stream
The sequence which works is...
['S] [WRITE 0xEE] {ACKS} [Register address 0xF6] {ACKS}
['P] ['S] [READ 0xEF] {ACKS} {ADC result 0x5C} [ACKM] {ADC result 0x96} [NACKM] ['P]
So if you're get an 0xFF response from a BMP180, then check the I2C is a START bit and not a RESTART.