Since the ADXL345 has got an I2C-interface (I am not a friend of SPI), why don't you use this? With the basic APIs of I2C-master (start, restart read etc) you can setup your connection byte-by-byte easily.
In your routine task() you initialize your device and get data, better is to separate initialization and reading off data.
You do not tell us where your program runs into troubles. Debugging the code will reveill that.
Best is to upload a complete project archive here (use Creator -> File -> Create Workspace Bundle (minimal) and upload the resulting .zip here), so we can check not only the code but all the settings.
A complete project helps to see where your hardware might be configured wrong.
Things to look for:
- SPI clock too fast (then the slave select output might go high inbetween the bytes)
- each write to the SPI also does a read - and this will fill up the buffer, so you might read wrong values afterwards. So clear the read buffer after each write
- wrong SPI mode (must be 1/1)
- when reading the registers, *1 must be shifted, as its the higher byte, and *0 is the lower byte
You should attach a logic analyzer and see whats going over the wire, and see whether it is what you expect. Then you can look at the software...
I think the code is very well written, here is some suggestions
The easy way to convert data to formatted data is sprintf(), basically printf() that
outputs to a character buffer for printing on LCD.
Attached the format specifications useful for sprintf(). If you are using character
LCD there is an API f() call in datasheet for printing a character buffer/array to the
LCD, as well as f()'s for moving the cursor to the position where you want the
formatted data to be written on LCD.
1. You have a while loop in your task() function. it will never come out so it won't run the Updatedisplay function().
2. You should be able to step and break within creator to debug your project.
3. For some simply test. I would suggest to added a 1second delay inside the main loop and also increment and x and y counter every loop and shown it on the LCD. So you can see the change of the counters updated on the LCD.
4. One step a time is actually quicker to the finish line.
First thing to note is that the SPI master is configured wrong. Its set to CPOL=0/CPHA=0, but the data sheet says it needs to be 1/1.
Can you attach a scope or logic analyzer to the SPI bus and check what goes over the wire, and whether the ADXL345 actually responds to the commands? Only if you can make sure that it answers it makes sense to look for other problems.
Also, your read logic is wrong. You only send the address byte to the ADXL345, but you never receive any data. For that, you need to send a second (dummy) byte, during which the ADXL345 will send your data back (see data sheet, page 16). Don't forget to skip the first byte you get from the read buffer, and you also need to wait for the transmission to finish (readRxStatus / readTXStatus).
I suggest you start reading the SPI master component data sheet, at least the API and the functional descriptions, and the ADXL345 data sheet, the part about SPI. Look at especially at the timing diagrams in both data sheets.
Btw: you still mix high and low bytes (DATAX0 is low, DATAX1 is high).
1. ADXL345 use the CS pin to switch between I2C and SPI mode, did you follow suggestion from the data sheet "Preventing bus traffic errors"?
2. SPI uses the CS pin to restart. It was mentioned by others that the line switches to high if the TX buffer is not filled up fast enough.
I would suggest to control the CS line via a control register. Or use I2C mode as other suggested.
3. Try to read the ID register( which is a constant) first to make sure the SPI and the related circuit is working correctly.
4. There are different setting for all the registers, make sure the default reset value is what your wants.
if not you need to set it up for your application.
5. I would suggest to read the values (6 bytes in one go).
The SPI clock is set to 150kHz, so I suppose that the PSoC is fast enough to fill the transmit buffer. The real problem is that only a single byte is send, so the ADXL345 never gets a chance to send its data back.
Hi friends.could u runing adxl345 with spi or i2c?because i cant solved this problem!!!
If you solved this problem please give me your project to understanding how i can to do?
So you switched from I2C (the easier interface) to SPI.
For every bit (byte) the SPI interface gets one bit (byte) is returned immediately. When the very first byte is sent, the interface does not "know" yet what to answer, so a dummy byte is returned which must be skipped.
SPI has no read command, so you must send dummy bytes to retrieve the information wanted.
A pitfall is the select line which is automatically taken low when a byte is sent. When the buffer is empty it is taken high again. This can lead to interface errors when the byte sequence is not provided fast enough resulting in ss-line glitches.
As I said: I2C is easier to handle.