Accelerometer Trouble

[wdburk3160]

I am trying to program the ADXL345 accelerometer in labview using I2C. I open it up and it needs an address, which I believe needs to be 0x3A. I try to write that address in there and it won't let me type any letters. Any theories as to whats going wrong?

[Mark McLeod]

If you can give a snapshot of the code you are working with we might be of better assistance.

This section (ADXL345 I2C Open.vi) from the Accelerometer I2C example has the 0x3A address.

[Sparks333]

I2C does an addressing scheme with the first transmitted byte consisting of 7 bits address and one bit read/write_not flag. According to the datasheet, the ADXL345 technically has an address of 0x1D (which, you may notice, is 0x3A bit-shifted to the right), and to read you transmit 0x3B and to write you transmit 0x3A. Depending on the software library/implementation used, it may or may not do this address bit shift on its own - I've seen and written it both ways. Mark McLeod is right, posting your code would be massively useful, but if you're using a library call with the address as a parameter, try the address as 0x1D.

Barring that, the ADXL345 (along with most other I2C devices) has a pin that can be grounded or dragged high to change a bit of its address, lest you want multiple identical sensors on the same I2C bus. According to the datasheet, if the ALT_ADDRESS pin is grounded, the I2C address becomes 0x53 (0xA6 with the R/W_N bit cleared, 0xA7 with the R/W_N bit set). So, check to see if that pin is grounded - if so, try the alternative address.

Also checking the datasheet - the sensor can be operated in I2C or SPI mode. Since SPI uses a chip-select scheme, it may be important that when you're using the I2C mode that the /CS pin be pulled high. This usually isn't an issue, but Figure 40 in the datasheet shows it pulled high, and usually they don't show connections unless they need to.

Lastly (electrical) - I2C is an open-drain bus. Unlike serial or pulse-width modulation, neither the sensor nor the device doing the addressing pull the line high - only low. This is massively useful when you don't want to deal with level translation, but means that you have to put a weak pull-up on both the clock and the data line. The exact value of the resistor isn't terribly important, but if it's too strong the chip or the controller won't be able to pull it down to a logic zero, and if it's too weak the voltage will not jump straight to logic high after being held low (it will gently meander, which may spill into the next bit, making for a metastable condition). The value of the resistor depends on how many devices you have on the bus, and how long of a conductor your bus uses. If you can get your hands on an o-scope, probe the bus and make sure the pulses look nice and crisp - they can have a bit of overshoot or rolloff, but if they don't reach their final (high) value within about a quarter of shortest pulse width, you need a stronger pullup.

Hope this is useful, and not going over obvious territory.

Sparks