If you happen to be thinking of hooking up some of the new MEMS Accelerometers, like the LIS302DL or MMA7455L , or similar device, to a Atmel AVR, as a SPI slave, don't do it!
I had to explains the problem of AVR to MEMS Accelerometer that I ran into, in excruciating detail, below for the manufacture to "get it".
Replace "Accelerometer" with LIS302DL, which was the part that I had the problem with initially, but I wrote the message below to one of the competitive manufactures, when they announced a new part was about to come out. This message is written like this because as a non-released part, at the time, confidentiality had to be upheld. The figure numbers refer to chip select wave forms, in a data sheet you can not get now. You do see similar wave forms in the available data sheets, with new figure numbers today.
====================
The Accelerometer data sheet states that it will always be a slave. This means that from the Masters perspective the Master will send out the data on the MOSI line, and receive data on the MISO line. The master will generate a clock on the SPC, more commonly called SCK, line, which typically is connected to all SPI parts that the Master wishes to communicate with.
The Master uses one or more Chip Select (CS) Lines to select which Slave it wants to communicate with. *ONLY* the Slave with its Chip Select line asserted should place data on the MISO line, and respond to data on the MOSI line. A Slave *NEVER* asserts the SCK line, as that is solely the Masters domain. A non-selected Slave *NEVER* asserts the MISO line.
Now with the Accelerometer CS line high, a CPU using SPI expects no interference from a none-selected Slave. With CS high (SPI chip select deasserted) the Accelerometer is now in I2C mode.
Look at figures 7 through 10. They clearly show that the Slave [The Accelerometer] generates an "ACK", which is on the SDA pin in I2C mode (CS is high). **The SDA pin in I2C is also the SPI mode MOSI line (SDI), in four wire SPI mode!**
The ST LIS302DL data sheet states it clear than I could have:
"Data transfer with acknowledge is mandatory. The transmitter must release the SDA line during the acknowledge pulse. The receiver [The Accelerometer] must then pull the data line LOW so that it remains stable low during the HIGH period of the acknowledge clock pulse. A receiver [Accelerometer] which has been addressed is **obliged to generate an acknowledge** after each byte of data has been received."
Lets say I want to use the Accelerometer in SPI mode, and I hook it up to a AVR's SPI *bus*. The AVR uses the SPI port for In System Programming (ISP) to load its initial program. There is no program that can be run, because I have to load the programing using the SPI bus first, to change the state of the I2CDIS bit. [One of the parts was to have a bit to disable the I2C interface, but it does you no good because you can not load the program via ISP to run the program to disable the bit!]
Now I start my AVR programming software, typically AVRDude, to load up my AVR connected to the Accelerometer. The Accelerometer CS line is high, therefore the Accelerometer 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 Accelerometer CS line is still high, the Accelerometer 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 some data bits on the MOSI (SDA/SDI/SDO) line, that are properly clocked (SCL/SPC), from the perspective of the Accelerometer, so that the Accelerometer sees its own address.
As a now properly selected Accelerometer, from the view of the Accelerometer, 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 Accelerometer 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).
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, because they tried to save a pin by using CS as both SPI and I2C select.
====================
"I've never seen this problem with my setup?"
Then your lucky that your data never contained the pattern that looked like the I2C Address of the Accelerometer while programming the AVR via ISP.
====================
"You are supposed to isolated the AVR ISP pins with 1k resistors, as the Atmel documentation shows".
This is true. However that takes four resistors per board, on a board that already did not have enough space. Also at 50,000 units per year, with an design lifetime of five years, that is 10,000,000 resistors. After a while these resistors start to add up to real money, for what is a single event at manufacturing time. Design for Manufacturing always should be given consideration.
