Reading LIS2DE12 FIFO I2C

[JFox.1]

LIS2DE12 (or those similar in range). Reading FIFO I2C. Questions:

1) I2C multiple byte read auto-increment. In order to continually read the FIFO with reg address auto incrementing from 0x28 to 0x2D then automatically wrapping around back to 0x28 again, must the MSbit of the SUB (register address) be 1? (Datasheet states that MSb needs to be 1 for auto increment of reg address for multiple byte read, but does not mention wrap around desired when reading FIFO).

2) Is it possible to just read one axis of the FIFO with a non incrementing SUB multiple byte read of e.g. 0x28 (i.e. with MSb of SUB = 0)? (Power and time are critical to me and I only need 32 bytes read from one axis, not 192 - half of which appear to need discarding with the 8-bit data LIS2DE12 device regardless. All datasheet talks about is reading all axes from FIFO.

3) Is the mention of '10-bit' FIFO in section 3.6 a typo and it should actually be 8-bit for LIS2DE12?

Thank you.

[JFox.1]

Sorry, I meant 0x29 (OUT_X_H), not 0x28 (FIFO_READ_START) above. Also, having trawled through all the responses by guru Miroslav (thank you), I have the answer for (3) and it looks like the answer is 'yes' for (1), but would be nice to have confirmation as the datasheet mentions nothing of the wrap around relationship with the MSb requirement for auto increment of reg address.

For (2) I guess I am asking if each axis' FIFO pop is triggered by its own individual read of the high byte (only byte in the case of this device), rather than a 6-byte read or, possibly, a read of just the highest reg address, 0x2D triggering all three axis data to then pop together.

[niccolò]

Hi @JFox.1​ ,

let me try to help you:

1) yes, I can confirm that, for having auto increment of the registers in i2c communication is mandatory to set the MSB of SUB to 1, otherwise you can't have sequential readings. if you need to read many registers that are distant from each other, it is recommended to set the MSB of SUB to 0 and perform multiple single readings, but in this case I think it is better to use sequential readings. So you are not using standard drivers to be more flexible, am I right?

2) If you directly read the register you need (being it X, Y or Z) they should all update to the next value in the FIFO, so in this case I think you can save some time with this method.

3) Good that Miroslav already addressed that problem, so did he confirm that it is a typo?

[JFox.1]

Thank you for your help, Niccolo. Correct, because of design constraints I am not using standard drivers. I am using a very slow processor running my assembly and my I2C interface is also in assembly, all highly refined to minimise power.

1) Thank you for confirming that with MSb set, a multiple I2C read of the data regs does cause a wrap around from 0x2D to 0x28 (and not, actually, a reg increment i.e. not a read of 0x2E).

2) So is it the termination of an I2C read of any of the data regs that causes all of them to update together to the next values in the FIFO? OR is it just the one you read that updates and that it is the termination of the I2C read for that one that triggers its update? I'm just trying to get my head around what actually triggers the FIFO to load the next value(s) into the output reg(s) as this is not clear from the datasheet. (What puzzles me a little is that if it is as you say, when we have a device type with 2-byte data, we would not want the highbyte data reg to update immediately after you have read the lowbyte datareg (lowbyte is read first with a sequential read), so such an update trigger must only come from reading the highbyte reg and not the lowbyte reg?) What I really want to do is, with MSb=0, a multiple I2C read of just one axis 'high' byte (there is no lowbyte with the LIS2DE12). I don't want to perform multiple single readings if I can avoid it because of the extra I2C overhead setting up a read.

3) It wasn't really a typo though it might avoid confusion by stating 8-bit. This range of accelerometers must share common hardware blocks and, from what I can tell, a 10-bit FIFO block is used but the 2 LSbs are not accessible.

4) I have another question, sorry. In case (2) does not work, I will want to access the FIFO before it fills (probably using FSS[4:0] of FIFO_SRC_REG to ensure unread data is present and a counter to ensure I only read 32bytes, which is all I want). In FIFO mode, the datasheet never mentions access of the FIFO until the FIFO is full. Is there any reason it cannot be accessed before it is full? I could possibly use Stream mode but if I am forced to read 6-bytes at a time, this may take longer than an ODR period. Not sure at the moment but it is certainly in the same ballpark.

Sorry this is quite complex.

[JFox.1]

In conclusion, I could only get repeated 2-byte reads of an axis in the FIFO to work (MSb=1) to function. A multiple byte read of one register (MSb=0) did not give sensible results. Consecutive multiple single byte reads of one register (MSb=0) also did not give sensible results. There is no great time saving performing multiple 2-byte reads so I may as well perform a 192 byte read (just for the 32 I need) or try a different manufacturer.

[niccolò]

Hi @JFox.1​ ,

sorry for the delay, I contacted the design team to be sure to answer you with the right information, and I'm afraid that the FIFO has to be read as the datasheet states, so reading all registers to let them refresh.

Regarding 2): the LIS2DE12 updates the output regs when the High_out reg is read, because it does not have the Low_out regs. but when it comes to FIFO they should be read all together, otherwise the ASIC can go to unrecognized states.

While regarding 4): I think the FIFO can be read even before it is full, but the option of using stream mode could be the best one. In fact, if you just need 1 byte (OUT_X_H reg), you can disable the other axis and read only that one when the data ready interrupt is triggered. This should not be a problem regarding speed. (I think that even a 6 register read can be performed quite easily by a microcontroller)

Would you like to share which micro you are using, which ODR and maybe some more specific of your project so I can try to help you find a solution?

Maybe I did not understand completely what you are aiming for.

[JFox.1]

Thank you for confirming that there is no variation allowed reading the FIFO and that it must be 6n bytes at a time to be sure of correct operation. Re your answer to (4), stream uses the FIFO, I believe, and because the FIFO must be read 6-bytes at a time, we cannot just read one axis. If the FIFO is not used and data is read upon the data ready flag, the byte read and data handling cycle must be performed quicker than one ODR period. This is borderline for me. Thank you for presenting this alternative, but I also do not have the option of using the interrupts; data ready polling is a 1-byte read and data read is a 1-byte read, which total 8-bytes I2C (assuming 1-poll, of which there would invariably be more) which is more than the 6-bytes that the equivalent FIFO read would use (as part of a 192-byte multibyte read). I think I have exhausted the options now and the best one is to spend time reading 192 bytes of FIFO data to get the 32bytes I want. It is a shame but it is the lowest power solution for me if I am to use this device. Thank you for your help.

As a follow on question, what is the point of being able to disable any unused axes through CTRL_REG1? Is there some undocumented power or time saving? If not, perhaps this is why the datasheet never mentions using less than all three axes.

[niccolò]

Let me suggest a last option:

disabling the BDU bit (reg CTRL_REG4 (23h)) the output registers are continuously updated. this way you don't have to read all registers to get to the next sample. This would be a single read of a single reg (4 bytes) every 1/ODR seconds, so 16 bytes for 4 samples.

The problem should arise in the timing of the read: from what you wrote " (assuming 1-poll, of which there would invariably be more)" I think that the problem could be reading two times the same sample.

Are you working in static condition? If so, you just have to increase your ODR and take the risk of undersampling (if you are not already using the highest ODR available. (there is a tradeoff between static power consumption of the sensor and speed of i2c communication)

If you are interested in vibration monitoring the data ready polling is needed to have a high precision, so this method is not doable.

When you put the data ready polling in the equation, you must add a reading (4 bytes communication) for every sample for every poll with negative result plus 1 for the positive result.

Reading the FIFO with 4 samples (I understood you are trying this) needs 1 multiple read of 6 registers (9 bytes communication) ==> 36 bytes communication (you said 192, but with multiple reading you don't have to take into account the SAD+W,SUB,SAD+R for all the single registers)

From my calculations, if you perform less than 7 (average) data ready pollings with negative result, the bytes to be read are less than a multiple read of the FIFO (36 bytes communication, plus the polling to know when the FIFO is full)

Do you think you can get the timing for the readings right enough to make less than 7 negative data ready poll? (if I did not mess something up)

Regarding your follow up question: yes, by disabling one or more axis you can save power, so I suggest you to disable the axis you do not use.

[JFox.1]

Niccolo, thanks ever so much for thinking hard about this for me. (Another limitation is, though, that I have a very poorly specified system clock (not crystal) so I cannot do any accurate timing of when to poll/read data.) Clearing the BDU bit is interesting but I can't see how, or if, this relates to when one is using the FIFO and without accurate timing, I can't really read data as it arrives without wasting lots of negative polls if I neither want to miss data nor read the same data more than once.

With the ability to sample at accurate time intervals, there is the way you suggest. But I cannot; so I have to use the FIFO and I need 32 samples. I do not want to go into more detail of the application in an open forum but it is not static and is data logging rather than event detection.

Thank you for confirming that power is saved by disabling unused axes. It might be a good additional note for the datasheet even if mentioned qualitatively. In conclusion, in order to use the FIFO, one should read 6n bytes at a time. I have yet to experiment with reading the FIFO before full in FIFO mode but I may not bother as conclusions formed from experimentation with a single DUT is not the same as datasheet spec and I have limited time. Thanks again.

[niccolò]

You are very welcome, I'm sorry I couldn't help you in the end.

I also checked if we have in the portfolio some sensor whose FIFO can be read as you want, but it seems that when working with FIFO, the ASICs are optimized to work with multiple reads, this way for normal applications the speed is the maximum achievable, but in your specific case it is a drawback.

I hope that you can accomplish your goal, and feel free to ask for further advice, if you ever need it.