AnsweredAssumed Answered

Reading nbr of rows in LIS2DH FIFO buffer

Question asked by bjerkborn.simon on Oct 21, 2016
Latest reply on Oct 23, 2016 by bjerkborn.simon

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

From what I understand, this means that we're retrieving FFS4 to FFS0 according to 10.2.3 in this documentation? 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!