Re: [avr-chat] AVR and accelerometers

[Bob Paddock]

On Friday 16 November 2007 09:49:08 am Clemens Koller wrote:
> nautilussoftware schrieb:
>  hello; I am interested in connecting several accelerometers to an atmel
>  and maybe using a processor that supports USB. I found an accelerometer
>  that uses SPI bus.... In my case it's a ST LIS3L02DQ.
> Which can speak SPI as well as I2C.


I have a lot of experience using the LIS3L02DQ and their
ilk with the AVR, most all of it *bad*.  DO NOT use the 302
on the AVR SPI bus, you won't like the results.

Take note of this section in the ST data sheet:

"Data transfer with acknowledge is mandatory. The transmitter
must release the SDA line during the acknowledge pulse. The
receiver [The 302] must then pull the data line LOW so that it
remains stable low during the HIGH period of the acknowledge
clock pulse.  A receiver [302] which has been addressed is
**obliged to generate an acknowledge** after each byte of data
has been received." -- Noting that the part is in I2C mode
when the "chip select" line is high, and SPI mode when it is low.

Now hook the 302, or similar Accelerometer, up to the AVR's SPI
bus.  The AVR uses the SPI port for In System Programming to load
its initial program.

Fire up AVRDUDE to load up the AVR connected to the 302. The
302 CS line is high, therefore the 302 is looking at the SCL
line (SPI SPC/SCK), it sees activity because SCK is clocking data
into the AVR from the programming software, and clocking out data
to verify that it was correctly received.

As the 302 CS line is still high, I2C mode, the 302 is also watching its
own SDA/SDI/SDO line, which the programming software is
using (MOSI/PDI) to send data to the AVR. The AVR is the Slave
when being programmed.

Now with that stage set we have the entrance of Mr. Murphy.

During the exchange between the programming software/hardware
communicating with the AVR to load its program, Mr. Murphy throws
in a some data bits on the MOSI (SDA/SDI/SDO) line, that are
properly clocked (SCL/SPC), from the perspective of the 302, so
that the 302 sees its own address.

As a now properly selected 302, from the view of the 302, it is
obligated to generate an ACK on the SDA/SDI/SDO line.

Remember the programming software is talking to the AVR using
this same line as MOSI. This ACK from the 302 does not belong on
the MOSI line at this time, creating contention on the MOSI
line. This causes the programming software to abort the transfer
because the AVR data was found to be corrupted during the
verification cycle (just as likely the verification cycle is what
is corrupted, but that you may be able to recover from).

You now have a AVR soldered to the board with no way to program
it, where you spend a couple of hours with the scope trying to
figure how why it won't program, then you start cussing when you
get that "A Ha!"  moment, then you get depressed because you
realize you have to explain to the boss that you need to spin an
other layout to fix this problem and the chip vendor is not going
to pay for it.

The problem is problematic as it depends on your programming data
stream. If you are lucking your SPI data stream will not contain
the apparent I2C address timing that wakes up the part; I never
have that kind of luck.

This whole class of parts, by several manufactures, have duplicated
the problem.  At least some of them give you a bit, or have the
bit programmed by default, to use either SPI or I2C, so you have
to order a specific subpart number to get the mode you want.
I'm told that VTI does this.  ST does not.  Freescale is working
on it.

If you don't want to use I2C to talk to the accelerometer then
hook it up to I/O lines and bit-bang it, do not put it on the SPI bus.

>  > this was the chip I
>  > found but I did not know where the price was.
>  > http://www.vti.fi/en/products-solutions/products/accelerometers/sca3000-
>  >accelerometers/

They are about $8 in price quote I had.  The 16-bit 3100 was the most
sensitive accelerometer that I evaluated, if you want to sense someone
breathing on your circuit board. ;-)

-- 
                http://www.wearablesmartsensors.com/
 http://www.softwaresafety.net/ http://www.designer-iii.com/
                 http://www.unusualresearch.com/