Note: The specified accelerometer operates up to 3.6 Volts, so it will require level translation to work with one of the classic (5 Volts) Arduinos. If the Arduino you are using is one of the newer 3.3 Volt boards, then this level translation is not required.
For level translation information, you will find many related questions in this site, so this answer does not cover it.
For pin to pin connecting up, using SPI mode:
- Sensor pin 07 to Arduino SS Slave pin (slave select, drive low to communicate)
- Sensor pin 12 to Arduino MISO pin
- Sensor pin 13 to Arduino MOSI pin
- Sensor pin 14 to Arduino SCK pin
- Sensor pin 08 to any free Arduino interrupt enabled pin, use digital pin 2
- Sensor pin 09 to any other Arduino interrupt enabled pin, use digital pin 3
The MISO/MISO/SCK/SS default pins for various Arduino boards, from the Arduino SPI reference, are given below:
Some of the SPI pins are available on the ICSP header on all Arduino boards, for consistency:
For the SS and interrupt pins, any free digital IO pins on the Arduino may be used, no specific standards need to be followed.
The I2C method of connection is best avoided for this part, as the I2C bus speed limitation will give marginal results.
Your best solution will depend on which mode you are operating the ADXL345 in.
If you are operating it in SPI mode, then pin 12 is being used for the same role on both boards, and they should be able to share simply by taking turns - only the one which has (had) its slave select activated should be driving return data.
If you are operating it in I2C mode, then you can cut the trace or remove the pin from the shield and permanently wire it high or low depending on which address you want to select. It's also possible that you could reconfigure pin 12 as an ouput and drive it high or low whenever you want to talk to the ADXL345, then make it an input again when talking to the SD. Even putting a pullup resistor on it would be likely to work - that would let the ADXL345 see it as a high (just a reliable value to control the address) and still let the SD card override it to send data.
If you don't know which mode is being used, look through the code (for the library) you are using to interact with it. (As a guess, it's probably I2C mode, because if it were SPI it would probably want to use most of the same pins the SD shield were using, instead of just one). Or check the /CS pin - if it's wired high you have I2C mode, if it's connected to an Arduino pin you might have SPI.
Best Answer
TL;DR Basically, no, for most situations.
Since acceleration is the derivative of velocity, integrating the output of an accelerometer should give you the velocity, however there are several flaws in that ointment(sic).
Firstly, if you remember your calculus, integration leaves an arbitrary constant so you must know the initial velocity in order to determine a new velocity. To put it another way, an object moving at constant velocity has no acceleration.
Secondly, the MEMS accelerometers used in typical consumer accelerometers have a lot of offset and drift. The offset gets integrated as well, and thus tends to increase without bound over time. Other errors such as hysteresis and scale errors will also affect the calculation results.
Thirdly, the accelerometer will respond to the 1g force of gravity. From the accelerometer's point of view, an accelerometer sitting on the table appears to be accelerating Edit: UPward at around 10m/s^2. Even if you attempt to ignore that axis, g can creep into the other axes. An object in free fall will appear to have no acceleration- whether it's falling towards the ground, in orbit or somewhere off in space. For normal applications, that means that the orientation of the accelerometer must be known to high accuracy- an error of only a degree or two will cause a large error in the velocity estimation in seconds.
So, an inexpensive accelerometer is only useful in a very limited subset of velocity estimation applications- 'dead reckoning' is not very useful with low-cost accelerometers. However, if the accelerometer signal could be somehow combined with some kind of accurate but slow measurement of position (eg. GNSS such as GPS or GLONASS) then you could have a fast-responding estimate of velocity that does not drift. This can be done with an algorithm that takes into account the errors of the two measurements and weights them appropriately (typically with a Kalman filter).
It is possible to use very accurate accelerometers in combination with accurate and very expensive gyros to determine velocity and position fairly well for relatively short periods of time. This is useful in case you wanted to deliver something, say an important 'package' of some kind, to the folks on a distant part of the earth very quickly (minutes) and could not depend on an absolute position measurement (say viewing a bright star or GNSS) for the entire trip (you probably know the initial position). The combination of accelerometers and gyros is called an IMU (inertial measurement unit). When combined with GNSS they're called something like GNSS-aided inertial navigation systems).