I2C help needed

[klims]

I need a bit of help working out how to use my new 3 axis gyro that uses I2C.

The data sheet (pg 22) says that register 0x00 stores the device ID, but how am I supposed to configure the I2C bus to talk to the register without first knowing the device ID??? Don't I need to know the ID before I can go asking for register values?

I'm using the Axon with webbotlib.


thanks guys.

[voyager2]

I'm no I2C expert but if you read the coments on the Sparkfun page "Madprog" says that the defult address is 0x68, although his was set to the alternate 0x69, however the next post clears it up a bit:

The description above mentions that they pulled AD0 high, so 0x69 is the expected address.

In other-words you communicate with it on address 0x69 by defult.

Hope this helps

Voyager

[Asellith]

Page 8 of the data sheet lists the address with AD0 = 0 it is 1101000 and AD0 = 1 it is 1101001. AD0 looks like a pin so you can connect more then 1 and change the address with an external interface. You can probably change the defaults after you have it wired up but I didn't dig any deeper into the sheet to find out.

[klims]

Haha I can't believe I missed that!  Totally glossed over the comments section.I'll give it ago.

Thanks guys

[klims]

Still can't get this thing working. I'm out of ideas  
I'm using the Axon I, Webbotlib 1.27, 3 Axis gyro and a Logic Level Converter. I've tried both addresses 0x68 and 0x69 with no luck

Can anyone tell me if they have successfully got a I2C fast mode working at 400kHz with the Axon and Webbotlib? I don't see anything in the webbotlib documentation to say it won't work, but I also don't see anything in there to say it will.

I have looked up the datasheet on the mosfets used in the Logic Level Converter and the rise time is 2.5ns so I don't think that should be a problem at 400kHz.

Edit: Even tried using i2cStart() and still having no luck.

Webbot: what is the 'complete communications session' you mention in i2cMasterReadRegisters()? I would like to know so I can compare it to the gyro datasheet which is:
 
Burst Write Sequence
    Master  S  AD+W          RA          DATA        DATA       P
    Slave                 ACK         ACK           ACK          ACK  

Burst  Read Sequence
    Master  S  AD+W          RA          S AD+R                ACK          NACK  P
    Slave                 ACK         ACK             ACK  DATA        DATA    



I'm out of ideas at this point guys so if anyone had any advice to offer I'd really appreciate it.


thanks,
Andrew

[waltr]

First, try a slower data rate to get it working. You can increase the data rate later. Since I2C is synchronous any data rate will work so try 20,000 -100,000 Hz first. I did have trouble going to 100,000 with a PIC until I increased the XTAL frequency so there may be an upper speed limit.

I don't think the logic level converter will work with I2C. The lines are bi-directional and both the CLK and SDA lines may not be driven to a logic high. They may only go to a logic high with a pull-up resistor. In many cases you only need to pull the two lines up to 3.3V and it will work. 3.3V is usually a valid logic high for a 5V devices but do check the electrical specs.
What value pull-up are you using? 4.7k to 10k is recommended.
How long are the SDA and CLK lines? Shorter than a couple of meters is recommended.

I haven't used the Axon, Webbotlib or that gryo but have used I2C on other processors and devices. I2C can be tricky to get the correct sequence and delays for different devices. Have you looked at the CLK & SDA lines with an O'scope to confirm what is being sent and the the slave ACKs?

[klims]

Thanks for the reply waltr

Since I2C is synchronous any data rate will work so try 20,000 -100,000 Hz first

I did not know that. That cleared a few things up for me. +1!
Didn't work at any speed I tried. I have confirmed there are no broken or intermittent connections so nothing should be getting lost.

I don't think the logic level converter will work with I2C. The lines are bi-directional and both the CLK and SDA lines may not be driven to a logic high.

I'm not sure mate but there seem to be a few tutorials around of people getting them to work. Thats the only reason I bought one!

What value pull-up are you using?

I believe this is handled by the Webbotlib using internal pull ups on the microcontroller because it is a hardware I2C. That's what the manual says.

How long are the SDA and CLK lines? Shorter than a couple of meters is recommended.

Less than 30cm so should be no problems there.

Have you looked at the CLK & SDA lines with an O'scope to confirm what is being sent and the the slave ACKs?

This will have to be my next step. I'm really crap at using a scope so I try to avoid it at all costs! No getting out of it this time I think.

[klims]

When the device is removed from the circuit and I am testing only with leads I see the following happening:
    SDA and SCL are both high. I fiddle with the connections a little and SDA goes low and stays low, no matter how often a call is repeated. I see not jumps or pulses (may be my cro).

When the device is in the circuit and I am measuring at the device I see the following
    Both SDA and SCL stay high and pulse low periodically. SDA never stays low.

The pulses occur periodically, once every second, as this is how often I am retrying the 'grab data from I2C' command.
I can't confirm the timing of the pulses or even how they are related because my scope can barely see the pulses when running one channel and has no chance on two channels.

I have been reading up on I2C and from what I can see is for a start sequence both the clock and data line need to be high and the data line then needs to go low, like it does when I remove the device from the circuit and I fake some on/offs with my leads. My only problem with this is that I thought it should give the 'start sequence' every time a 'grab data' command is executed. Is this true?

Anyone got any suggestions/ideas?

[waltr]

Ok on the level shifting circuits. I re-examined them and they should work.

For using the scope:
Set the I2C speed way slow, like even 1000 Hz.
Have the code call the I2C function more frequently say 2-4 times a second.
This will make it easier to see the I2C SDA & CLK lines on the scope.

Do some more reading on I2C as you dig into this with the scope. It does sound very complicated at first but is not that bad.

I do hope someone with WebBotLib experience with I2C can help with the code side.

[Webbot]

Klims,

I've used the I2C code with lots of stuff, including other gyros. Email me your code and I'll take a look as soon as I can.

Webbot

[Webbot]

Sorry for the double post but...

There is a confusing thing with I2C device addresses. The LSB is set depending on whether you are reading from, or writing to, a device. The upper 7 bits therefore define the actual address of the slave device. Some manufactures shift these down to the lowest 7 bits whereas others keep them in-situ in the upper 7 bits. There doesn't seem to be a standard.

For this device the manufacturer shifts the bits to the lower 7 bits and hence quote an address of either 0x68 or 0x69 depending on AD0. However: WebbotLib assumes they are in the upper 7 bits ie addresses of either 0xD0 or 0xD2.

Have you tried using 0xD0 or 0xD2 in WebbotLib?
 

[waltr]

Thanks for the post Webbot. I hope that clears up the OP's problems.

[klims]

Have you tried using 0xD0 or 0xD2 in WebbotLib?

Webbot you are a champion! This fixed my problem immediately  
Maybe you can make a little addition to the webbotlib documentation about this little mix up. Any if you do maybe make an adjustment to the i2cBusSetBitRate() description about the multiplier. The math doesn't work out.

Waltr: Thanks for the help. Much appreciated.


Now I can finally get my robot walking with gyro compensation  



thanks again guys,
Andrew

[Webbot]

Glad it's sorted... I've added the device to the next release of WebbotLib.