Reading nbr of rows in LIS2DH FIFO buffer

simonbjerkborn9 · ‎2016-10-21

Posted on October 21, 2016 at 14:30

Hello,

Recently I've been tasked with modifying existing code running on a system which contains a LIS2DH accelerometer. It should be pointed out that I'm used to high-level programming languages and this is my first venture into embedded development, so please forgive me if some of my questions are a bit... Dumb. I'm trying to access the FIFO buffer in order to look for a sustained period of low-g measurements. The existing code to find the number of lines in the buffer is:

// Finding out the number of rows in the FIFO buffer
GPIO_DRV_ClearPinOutput(LIS2DH_CS_PIN); // SPI enable, i.e. I2C disable
FIFO_src_reg=acc_read_byte_blocking(LIS2DH_FIFO_SRC_REG);
GPIO_DRV_SetPinOutput(LIS2DH_CS_PIN);
FIFO_nbr_rows=(FIFO_src_reg&0b00011111);
FIFO_nbr_rows+=((FIFO_src_reg&0b01000000)>>6);

From what I understand, this means that we're retrieving FFS4 to FFS0 according to 2.3 in

http://www.st.com/content/ccc/resource/technical/document/application_note/a6/78/86/f9/88/c0/49/9b/DM000267pdf/files/DM000267pdf/jcr:content/translations/en.DM000267pdf

? I realize that the documentation isn't for exactly the same device, but the LIS2DH documentation that I've been able to find doesn't go into equally deep detail on this matter, and judging by the code it seems that they operate in a similar manner. For each row in the buffer, we then read 6 8-bit values and concatenate them into 3 16-bit values. This makes a reasonable amount of sense to me.

acc_read_bytes_blocking(LIS2DH_OUT_X_L,FIFO_nbr_rows*6, accelerometer_FIFO_data);

void acc_read_bytes_blocking(uint8_t address, uint8_t nbr_of_bytes, uint8_t* read)
{
uint8_t first_byte;
first_byte = (ACC_ADDRESS_MASK & address) | ACC_RW_BIT_MASK | ACC_MS_BIT_MASK;
spi0_write_bytes_blocking(&first_byte, 1);
spi0_read_bytes_blocking(read, nbr_of_bytes);
}

My current main problem is that FIFO_nbr_rows always ends up with a value of 16, even though I would expect a full buffer to contain the 32 latest samplings. Is the size of the FIFO-buffer user-settable, or is there something wrong with the code I have been given? I'd be very grateful for any help or advise, right now I'm very confused about how it all works! #lis2dh

Miroslav BATEK · ‎2016-10-21

Posted on October 21, 2016 at 17:10

You can find the datasheet for this device here

/content/my_st_com/en/products/mems-and-sensors/accelerometers/lis2dh.html

A timing is not mentioned in your description. I mean when do you read the data.

There is a possibility to set FIFO threshold in FIFO_CTRL_REG (2Eh). Then an interrupt is generated when the number of data in FIFO reach the threshold.

So if you would have set the FIFO threshold to 16 and read the data when interrupt occurs, then it would behave as you describe.

You would see 32 samples in the FIFO only at time when the FIFO is full.

Best regards

Miroslav

simonbjerkborn9 · ‎2016-10-23

Posted on October 23, 2016 at 23:22

Hi,

From the code and from what I've been told, we have an interrupt looking for peaks above 90 m/s2 in any axis. The idea is to detect impact events. Anytime this occurs, we read the available FIFO data in order to find low-g events prior to impact.

Am I correct in thinking that it's FTH4:0 that specifies the threshold value in FIFO_CTRL_REG? Our current setting is 0b10000000, meaning that the accelerometer is in stream mode, and the threshold value is set to 0, right?

According to the documentation, the overrun interrupt can be toggled via the second to last bit in CTRL_REG3 (22h). Our value for CTRL_REG3 is 0b00010000, so it should be disabled.

I'm not sure how to interpret stream mode. Does this mean that anytime we read the FIFO data (due to int2 caused by an impact) we should expect 32 values, or does it mean that we should expect a completely random number of values each time we read it?

I appreciate your patience. As I mentioned, this is rocket science to me, but I'm learning!

All the best,

Simon

Please disregard everything above, I figured out where we activate the overrun interrupt! I believe it works the way it should. Thank you for your help!

Simon