H3LIS331DL 16bit and overhead?

Sensors IMU & Motion
1

On the H3LIS331DL sale page, someone left the comment: "I really appreciate the breakout/hookup guides you provide. They provide a huge help and enable incorporating your components quickly. Thank you!

Just a heads up… the library (SparkFun_LIS331_Arduino_Library-master) has some (minor) issues. People using it should review what it is doing and modify as appropriate. Two examples: (1) the current library (as of 2021-01-27) truncates the result to 12 bits instead of giving you the full 16 bits of precision. To get the full 16 bits, you need to edit multiple functions. This code was likely leveraged from some other 12-bit accelerometer. (2) When using I2C, the current library does each (register) byte read as an individual operation; this means to read X, Y, Z six different read I2C wire.begin() sequences are performed (two bytes for each dimension; each byte retrieval is done separately). Extending the library to do multibyte transfers is easy and eliminates much overhead… read the datasheet and you’ll see multibyte reads and writes are possible by setting the msb in the address register (which indicates a multibyte read/write operation for I2C); this technique results in one I2C wire.begin() sequence.

There are likely other minor issues, but once again, starting with the library and code examples is HUGE. Thank you."

I checked the github, and apparently the library seems to take a 12 bit value, and output a 16 bit number. Will the library be modified to output a true 16 bit value? Additionally, like the comment says, are there any plans to do multibyte transfers? Thank you

2

Thanks for reaching out to us on this.

The code we provide as examples of utilizing the hardware; we do not provide code that necessarily demonstrates the hardware’s features to their full extent.

The code is only meant to be a general starting point for projects, sometimes covering multiple models/boards/etc.

We do not currently have plan to implement the function changes to alter the code from 12-bit to 16-bit, though this may present an opportunity:

if someone were to update the example with these changes, we could certainly forward those along to our engineering department.

Hope this helps, and happy sparking!