SPI data transfer issue

[Bocdan]

Hello again,

I have been working on the SUB-20 for a while now with an accelerometer ADXL345 (bought from sparkfun) through SPI the port. Now, the ADXL345 supports a data output of 3200Hz which I require for my project (actually my director wanted 5kHz but he settled for 3.2kHz). To contain the data, it has a built in FIFO buffer of 32 entries. So to fill that buffer it takes 10ms. Here comes my problem. To read each entry (1 address byte and 6 data bytes) the CS must start High, go low for all 7 bytes then go high. It takes on average 1.5ms to use the sub_spi_transfer fonction. So 1.5 ms x 32 entries = 48ms, add to that 2 extra access for control. The problem becomes obvious, it takes more time to empty the buffer than to fill. I could do one SPI access with the sub_spi_transfer fonction with a buffer the size of 224 bytes that takes about 3ms, but that doesnt work since the CS stays LO during the whole transfer. Is there a way for me to make the CS pulse for 5us every 7 bytes during one use of sub_spi_transfer ? as per the data sheet my options are limited, can the sub-20.dll by taylored for my needs ? Or do I have to scrap 2 months of work and use something else to communicate with the accelerometer.

Dan

[xol]

Don't worry it is not a big deal to make required customization. We did similar things before. (for example: viewtopic.php?f=2&t=120&start=0&hilit=pulse)
I would like first to see data sheet of ADXL345 to make sure we do not miss something.
Is it correct one?
www.analog.com/static/imported-files/data_sheets/ADXL345.pdf

[Bocdan]

Yes it is the right device !

So basically have the CS pulse every 2 bytes or 7 bytes (For single read/write commands and Multiple Byte read commands for data reading).

Thanks,
Dan

[xol]

OK,
I knew they are not stupid in Analog Devices and they took care about SUB-20 being connected to their IC .
Here is what you have to do. It is taken from page 14 of the manual

To read or write multiple bytes in a single transmission, the multiple-byte bit, located after the R/W bit in the first byte transfer (MB in to ), must be set. After the register addressing and the first byte of data, each subsequent set of clock pulses (eight clock pulses) causes the ADXL345 to point to the next register for a read or write. This shifting continues until the clock pulses cease and CS is deasserted.

Is it good for you?

[Bocdan]

I already knew that, but it works for consecutive registers only. If the registers are not consecutive, you have to pulse it yourself.

So here is how it is used:
1- send the read command for the INT Source register (2 bytes)
2- pulse the CS (sub_spi_transfer with SS_LO for 1 and 2)
3- send the read command for the FIFO status register (not consecutive with INT Source) (2 bytes)
4- pulse the CS (sub_spi_transfer with SS_LO for 3 and 4)
5- send 7 other bytes without deasserting the CS to read register X0 to Z1 (registers are consecutive) (1 command byte + 6 data bytes)
6- pulse the CS
7- repeat 5 to 6 for all entries

Doing 1 to 7 must not exceed 3.5ms (well 10ms but I need a safety factor, it'll be ok with 4 to 5ms).

I was doing a sub_spi_transfer for each 1, 3 and 6 but it takes 1.5ms + 1.5ms + 1.5ms * 32 Entries. So it's way too long.

I then did a sub_spi_transfer fo 1 and 3, then one for the whole 5 to 7 actions. It takes roughly 4.5ms, but the data is garbage since the CS is not deasserted inbetween non consecutive registers.

So I require a pulse every 2 bytes for 1 and 3, and a pulse every 7 bytes for 5 to 7.

Dan

[xol]

HI,
Something that I do not understand.

You say:
> 5- send 7 other bytes without deasserting the CS to read register X0 to Z1 (registers are consecutive) (1 command byte + 6 data bytes)
and
> then one for the whole 5 to 7 actions. It takes roughly 4.5ms, but the data is garbage since the CS is not deasserted inbetween non consecutive registers.

Are registers read in 5-7 consecutive or not?
Can you list register addresses you are reading at each spi_transfer.
I'm just trying to figure out how to make required rework on SUB-20 to suite your needs.

[Bocdan]

Register 0x30 - Interrupt Source (To validate Overruns or Not)
Register 0x39 - FIFO Status (To get the number of entries in the FIFO buffer)
Register 0x32 - Data X0
Register 0x33 - Data X1
Register 0x34 - Data Y0
Register 0x35 - Data Y1
Register 0x36 - Data Z0
Register 0x37 - Data Z1

Reading 0x32 to 0x37 pops an entry in the FIFO buffer, so you have to repeat the process of reading 0x32 to 0x37 to pop (and read) all entries in the FIFO buffer to empty it. The pop is made only when the CS has gone high (ie data in 0x32 to 0x37 is updated to the next value in the buffer) for at least 5us. There are no ways to read all the data contained in the buffer in one shot. You can only do multiple reads of data X0 to data Z1 to empty it.



This is an application note on how to use the FIFO buffer:
http://www.analog.com/static/imported-f ... N-1025.pdf

[Bocdan]

So basically, I need 1 call of sub_spi_transfer to read Register 0x30 and Register 0x39 (4 bytes with a CS pulse between the first 2 bytes and the last 2) and 1 call of sub_spi_transfer to get all the data in the buffer to read [Register 0x32 to Register 0x37] * [the number read in register 0x39] (ie: 7bytes * number from 0x39 with a pulse after every 7 bytes).

I hope I made it easier to understand lol ! I know it's confusing.

Dan

[xol]

Yes.
It's clear now.

I think we will implement following function
sub_spi_transfer_ess( sub_handle hndl, char* out_buf, char* in_buf, int sz, char* ss_config ),

where ss_config will be a string definig SS activity during transfer.
For example ss_config="0LL^++LL"

0 - Use SS0
L - transfer byte with SS low
H - transfer byte with SS low
^ - SS high without byte transfer
v - SS low without byte transfer
+ - small delay (20-30us)

What you think?

[Bocdan]

Looks perfect ! Can't wait to use it

Dan