DMP_FEATURE_SEND_RAW_GYRO is not catered for in dmp_read

[btsimonh]

Version

latest?

Describe the bug

ok, odd one, because I reporting this based on a javascript port that I am doing. So please test to see if you can reproduce.

If you set DMP_FEATURE_SEND_RAW_GYRO without DMP_FEATURE_SEND_CAL_GYRO, the dmp sends 8 + 6 bytes rather than 6 bytes of gyro data. Then dmp_read has a incorrect packet length and data postions.

e.g. data out for

        MPU6050.DMP_FEATURE_TAP | MPU6050.DMP_FEATURE_PEDOMETER | MPU6050.DMP_FEATURE_ORIENT |
        MPU6050.DMP_FEATURE_SEND_RAW_GYRO | MPU6050.DMP_FEATURE_GYRO_CAL

is 20 00 00 00 12 ec ef 17 + ff af 00 0d ff d6 + 00 00 00 02

If you add DMP_FEATURE_SEND_CAL_GYRO, then it reverts to 6 bytes only ff af 00 0d ff d6 + 00 00 00 02.

Suggest:

    if ((this.mask & MPU6050.DMP_FEATURE_SEND_ANY_GYRO) != 0)                                                          /* check the gyro */ {
        if ((this.mask & MPU6050.DMP_FEATURE_SEND_RAW_GYRO && !(this.mask & MPU6050.DMP_FEATURE_SEND_CAL_GYRO)))                                                          /* check the gyro */ {
            len += 8;                                                                                                         /* size += 8 */
        }
        len += 6;                                                                                                         /* size += 6 */
    }

and reading the 8 bytes first.

I do not know the nature of the 8 bytes..... and I do not know if this is an issue in the C driver.

Reproduce

run the dmp example, and ask for DMP_FEATURE_SEND_RAW_GYRO without DMP_FEATURE_SEND_CAL_GYRO. Data output may be incorrect. (check fifo size is a multiple of expected packet size, if not then there is an issue).

Expected behavior

calculated packet size in dmp_read should be correct, and data read from the right packet loactions.

Additional context

I have been porting the driver to Javascript using pigpio-client to drive the i2c, and came across this issue whilst trying to understand calibration, hence why the code above is not C :).