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/ _______________________________________________ AVR-chat mailing list AVR-chat@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-chat
