I2C not working as expected

I was using address 0x77, when I try and use 0xEE the system does not work. I should also mention that I am using 10K pull-up resisters, somewhere I read a recommendation for 4.7K. Maybe that is giving me the communication error?

OK, just curious because the adafruit sample library you referenced uses them and I took them out of my implementation.

Yeah just edited my above post.

That’s strange about the address since https://github.com/spark/core-common-lib/pull/3 does not look to be merged with compile-server2 yet. I’ll sure be happy after this is fixed so we can stop talking about mucking with addresses!

I really wish Adafruit made PDF’s of their schematics… and now github’s repo search is broken partially… you have to type the full first part of the repo name. Anyhoo… doesn’t look like adding stronger pull ups are going to help you if you have one of these:

3Vo is an internal node, hooked to the 3.3V regulator, don’t hook this up. Just hook up Vin to Vin on the Core.

OK, I failed to mention that I build locally so I am working from the ‘master’ that was pulled a few days ago.

I am not using the Adafruit board, I got mine elsewhere and it does not look the same. I can see a pair of ‘472’ SMT resisters on the traces for SCL and SDA so I assume they are 4,7K pull-ups. I guess I can take my 10K pull-ups out.

Interesting thought - if each ‘device’ has their own pull-ups on the I2C then the pull-up resisters will be in parallel and that reduces the resistance to the + rail and effectively doubles the current on the I2C lines :frowning:

Guess I will have to pay attention to each I2C device I chain together.

I am going to refactor the library. I don’t like the Adafruit lib as it recaptures the temp and pressure for each call to altitude, pressure, temp, … So if you want to print out the Altitude, Pressure, and Temperature you are making 7 different queries to the device. You only need 1 and the rest can be calculated from that sample. Also since I am still getting blocking on my reads, I may play around with the EOC pin and use an interrupt for when the device is ready to be read instead of using the ‘delays’.

Thanks for your help. I’m not sure if there is still something funny with the Spark firmware on the I2C implementation. My application uses interrupts for the DHT11, I2C for the BMP and a lot of Serial IO for debugging. The fact that my serial goes away indicates to me there is still something not right in the firmware.

Yup, it's still buggy. I should really make a "master" I2C thread to keep track of everyone's issues.

Tim’s I2C pull request to handle shifting the address has been deployed.

So this will be part of the next firmware flash we do?

Ken

Yup! Appears so! :smiley:

Let me give it a shot.

Yup, just change your addresses back to the regular 7-bit variety and flash the code from Sparkulator. It seems to be working just fine! @zachary Maybe I should make a post and we can have it stickied for a few days so people will have a heads up of why their code might suddenly stop working? :wink:

If you write a clear post, we can definitely sticky it for a few days. Great idea! Thank you!

@zachary Here you go!

https://community.particle.io/t/important-7-bit-i2c-addresses-are-now-working-01-24-2014/?redirected=true
1 Like

Advanced I2C Implementation/Rework Pull Request for those interested:

1 Like