I2C polling: Propeller vs Arduino

hylee101001

I have noticed that some I2C boards do not respond to Propeller's polling codes( some others do). But these set of chips all respond to Arduino's polling. What could be the difference? Data transmit speed matters to some I2C sensors?

kwinn

Yes, clock (data transmit) speed matters. Some chips cannot handle the higher speeds the propeller is capable of.

hylee101001

Then is there a way to lower the Propeller's speed?

kwinn

Yes, you can reduce the propeller clock speed, but that is not the best way to do it. Better to reduce the speed of whatever I2C object you are using. If you need help with that just post the name of the object you are using.

Tracy Allen

Which i2c object for the Propeller are you using? If it is one written in Spin, problems are unlikely to be speed related. If it is written in pasm (such as Chris Gadd's) you program will need to supply a speed parameter.

More likely causes have to do with pullup resistors or address assignments (7 bit vs 8 bit).

ChrisGadd

If this is about the MPU9150 you asked about yesterday, that module is capable of operating up to at least 769Kbps - max speed of my I2C object.... at least on a breadboard.

Here's an I2C poller that'll tell you the 7-bit address of everything on the bus, and here're some MPU9150 objects that display the outputs of the accelerometer, gyroscope, and magnetometer.

Chris

hylee101001

Chris: Thanks, yeah that's the one i'm using.

Kwinn: This is the one I was working on https://www.sparkfun.com/products/11084
It respons to arduino while not responding to my propeller. FYI, https://www.sparkfun.com/products/11486 is the one responding for both arduino and propeller.

And http://obex.parallax.com/object/700 is the object.

Thanks!

hylee101001

Tracy: I'm using the object that I just posted above. Since I used the polling, the address must be in one of the data bits sent. Then, last issue can be only pull-up resister. But I think https://www.sparkfun.com/products/11084 has pullup in it. But they might have different pullup resister?

Dave Hein

The first customer comment says:

If you plan to use this with a Raspberry Pi, be warned that this chip doesn’t play nice with Raspberry Pi’s I2C bus. This is due to it’s use of “repeated start” in the I2C protocol (which Raspberry Pi can’t handle without bit-banging).

You may have to create a modified I2C driver to talk to this chip. Look at the I2C specs for the chip and make sure the driver conforms to it. It sounds like it may repeat the start in some unusual way.

EDIT: I looked at the specs some more, and I don't think the repeated start is any different than other devices use. You just need to make sure you read and write the way the spec says. I would use the sample code provided in the spec, and port it to Spin based on an existing Spin I2C driver.

ChrisGadd

Well shoot, I thought I'd made that poller bullet-proof.

I've never used an ASC board, but it looks like P14 and P15 are intended for use with I2C, but they're also shared with a couple inputs on the MCP3208. Are those the pins you're using, and are you also using the 3208? Have you tried using any other pins? The MPU9150 does have built in pullups, but does the poller detect them and use the open-drain driver? Have you tried forcing the poller to use the push-pull driver? Are you testing the 9150s one at a time? Mike Green had some good suggestions in the other thread regarding input power: are you powering the MPU9150 with 3.3V and not 5V? Have you tried bypassing the 2.2K resistors when using 3.3V?

Mike Green

P14 and P15 are used for the Arduino's I2C pins for compatibility purposes. As far as the Propeller is concerned, any pair of I/O pins can be used for I2C and you can have multiple I2C busses. The "Basic I2C Driver" from the ObEx can use multiple I2C busses with the even I/O pin as SCL and the odd I/O pin as SDA. Neither SCL nor SDA has to have a pullup since it actively drives both I/O pins both high and low.