interfacing with LIS3LV02DQ
demaki
Posts: 3
Ok, so I got this bs2p chip working now and I have been trying to interface with·a sensor that I have. The sensor is a 3-axis acclerometer.·It can be interfaced with either the serial, or I2C functions.·I can give a link to the data sheet on this·moster... but it`s· pretty tough read.
http://www.sparkfun.com/commerce/product_info.php?products_id=758
That link gives the schematics to the actual breakout board that I am using, as well as the datasheets. Notice that the nominal voltage is 3.6 volts. I am using a voltage regulator to produce this on the board. For the I2C SCL/SDA lines, running between the BS2 (1 and·0 pin respectively) to the device, I am pulling them up using 2K resistors (between the 1K and 4.7K that PBASIC manual recomends) - though I am pulling them up to the 3.6 Vdd line instead of the 5 Vdd line (reason why I chose the 2K instead of 4.7K). I also tied the CS line on the accelerometer to high - to enable I2C communication.·So that is the hardware... now the sorftware:
The·subaddress for·the device·, as per the datasheet, is %0011101, and the two registers that I am trying to read from are: $28 and $29 (hex). These registers represent the high and low bytes for a word size data representing an acceleration. Here is the code I am running:
' {$STAMP BS2p}
' {$PBASIC 2.5}
' Some variable definitions·
xlow VAR Byte
xhigh VAR Byte
x VAR Word
' A little intialization
xlow·=·0
xhigh·= 0·
x = 0
··
DO
· ` Get sensor values, one byte at a time, and store them in word variable
· I2CIN 0, %0011101, $28, [noparse][[/noparse]x.LOWBYTE]
· I2CIN 0, %0011101, $29, [noparse][[/noparse]x.HIGHBYTE]
·
· ' Get the sensor values one byte at a time and store in byte variables
· ' Ok... the reason I am doing this, is to see if there is anything in the byte size data
· I2CIN 0, %0011101, $28, [noparse][[/noparse]xlow]
· I2CIN 0, %0011101, $29, [noparse][[/noparse]xhigh]
·
· DEBUG CLS, ?x, ? xlow, ? xhigh
LOOP
So, here is what I am getting in the debug window:
x = 65535
xlow = 255
xhigh = 255
These values never change, telling me that either the SDA line is always high, or the device is sending me all 1`s. First, I went into the control registers of the device to be sure that I have enabled the x-axis for the accelerometer. I added the following code, before the loop, to be sure that the LIS3LV02DQ is initialized properly (the control register, and what each bit means can be found in the datasheet linked in the link above).
I2COUT 0, %0011101, $20, [noparse][[/noparse]%11110111]
This didn`t do anything, so I went back to my originally theory - that the SDA line was being held high. I tested it out by pulling the SDA line while the device·was running... and x, xlow, and xhigh all went to 0. I am pretty sure that the SDA line is just staying high, or the bits that are being sent are being sent at the wrong speed and the basic stamp is reading them as high.·I am not sure what is going on... is this hardware, or·is there·a difference between speeds between the device and the basic stamp??
Forever learning....·
http://www.sparkfun.com/commerce/product_info.php?products_id=758
That link gives the schematics to the actual breakout board that I am using, as well as the datasheets. Notice that the nominal voltage is 3.6 volts. I am using a voltage regulator to produce this on the board. For the I2C SCL/SDA lines, running between the BS2 (1 and·0 pin respectively) to the device, I am pulling them up using 2K resistors (between the 1K and 4.7K that PBASIC manual recomends) - though I am pulling them up to the 3.6 Vdd line instead of the 5 Vdd line (reason why I chose the 2K instead of 4.7K). I also tied the CS line on the accelerometer to high - to enable I2C communication.·So that is the hardware... now the sorftware:
The·subaddress for·the device·, as per the datasheet, is %0011101, and the two registers that I am trying to read from are: $28 and $29 (hex). These registers represent the high and low bytes for a word size data representing an acceleration. Here is the code I am running:
' {$STAMP BS2p}
' {$PBASIC 2.5}
' Some variable definitions·
xlow VAR Byte
xhigh VAR Byte
x VAR Word
' A little intialization
xlow·=·0
xhigh·= 0·
x = 0
··
DO
· ` Get sensor values, one byte at a time, and store them in word variable
· I2CIN 0, %0011101, $28, [noparse][[/noparse]x.LOWBYTE]
· I2CIN 0, %0011101, $29, [noparse][[/noparse]x.HIGHBYTE]
·
· ' Get the sensor values one byte at a time and store in byte variables
· ' Ok... the reason I am doing this, is to see if there is anything in the byte size data
· I2CIN 0, %0011101, $28, [noparse][[/noparse]xlow]
· I2CIN 0, %0011101, $29, [noparse][[/noparse]xhigh]
·
· DEBUG CLS, ?x, ? xlow, ? xhigh
LOOP
So, here is what I am getting in the debug window:
x = 65535
xlow = 255
xhigh = 255
These values never change, telling me that either the SDA line is always high, or the device is sending me all 1`s. First, I went into the control registers of the device to be sure that I have enabled the x-axis for the accelerometer. I added the following code, before the loop, to be sure that the LIS3LV02DQ is initialized properly (the control register, and what each bit means can be found in the datasheet linked in the link above).
I2COUT 0, %0011101, $20, [noparse][[/noparse]%11110111]
This didn`t do anything, so I went back to my originally theory - that the SDA line was being held high. I tested it out by pulling the SDA line while the device·was running... and x, xlow, and xhigh all went to 0. I am pretty sure that the SDA line is just staying high, or the bits that are being sent are being sent at the wrong speed and the basic stamp is reading them as high.·I am not sure what is going on... is this hardware, or·is there·a difference between speeds between the device and the basic stamp??
Forever learning....·
Comments
There's a whole "sticky" thread in the Propeller forum about combining 5V and 3.3V parts. Quite a few postings are specifically about I2C busses. The techniques work both ways (3.3V Propeller to 5V peripheral and 5V Stamp to 3.3V peripheral). Have a look (http://forums.parallax.com/showthread.php?p=585920).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support