stmicroelectronics / lsm6dsox-pid Goto Github PK

I use LSM6DSOX and LIS3MDL components, nrf52 board and I have achieved reading raw data seperately.

What I haven't been able to make work are the functions lsm6dsox_sh_fifo_lis2mdl or lsm6dsox_sh_lis2mdl from the examples examples/lsm6dsox_sh_fifo_lis2mdl.c and examples/lsm6dsox_sh_lis2mdl.c accordingly, in the attempt of using FIFO and reading data simultaneously.

I have made the appropriate adjustments for LIS2MDL to LIS3MDL functions.

The result is that I get data for accelerometer and gyro but never from magnetometer.
For the first code, it never enters the case LSM6DSOX_SENSORHUB_SLAVE0_TAG where it will read magnetometer data
and in the other code it prints 0 for magnetic data.

I have called lis3mdl_operating_mode_get() function to make sure that the component is not powered down.

Any ideas why this happens? Is the code tested that it works?
If it is better I can share my code too my_code_for_nrf52

Device part numbers

lsm6dsox, not sure about other sensors

Type of bug

Build error.

Describe the bug

Project does not build if compiler optimization level is O2.

Additional context

I integrated the driver into an ESP-IDF project of mine. The project builds fine if optimization level is Og, but fails to build when trying to build at level O2.

The values used to convert the gyroscope readings from int16 to float have inexplicable values.

When calculating the conversion values myself, I get the correct values for the accelerometer, but not so for the gyroscope.

For example:

float_t lsm6dsox_from_fs16_to_mg(int16_t lsb)
{
  return ((float_t)lsb) * 0.488f;
}

Corresponds nicely to 16/32767 * 1000.

But:

float_t lsm6dsox_from_fs1000_to_mdps(int16_t lsb)
{
  return ((float_t)lsb) * 35.0f;
}

Doesn't correspond to 1000/32767 * 1000 , which yields ~30.5.

Why is this so?
Is it a bug or some kind of special conversion factor I'm not aware of?

The values provided in the Code seem to match the examples from the application note though.
e.g. for 250dps like in the application note example, it would result in a range up to 286dps for that scale (which obviously doesn't make much sense from an outside viewpoint).

The function lsm6dsox_all_sources_get() seems incorrect wrt the LSM6dSOX datasheet (DS12814 Rev 3 Jan 2019).
It does a block register read of 12 bytes; the bytecpy() assignment of return values is correct for the first 5 (0x1A-0x1E), but the remaining registers should be copied from 0x35-0x3B.