LKML Archive on
help / color / mirror / Atom feed
From: Jean-Baptiste Maneyrol <>
To: Andreea Lutac <>
Cc: "" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>
Subject: Re: ICM20602 buffer issues with the inv_mpu6050 driver
Date: Wed, 22 May 2019 14:33:44 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <42bd-5ce3d580-2b-ca9e8b0@181689754>


I had a look inside the driver to verify the buffer implementation. It looks correct to me. I don't see where the problem can come from. I am sorry I don't have a setup currently to test in live.

For sure you can have a different result by reading the buffer through the char device file compared to reading the raw sysfs entry. The buffer is taking the data from the FIFO and the raw sysfs from the sensor data registers.

You can perhaps test value 1 by 1 in the buffer, and verify the correctness of every attributes. If you can also send a complete buffer log that would be helpful.
Every data is 2 bytes long and in the following order: accel_x, accel_y, accel_z, temp, gyro_x, gyro_y, gyro_z

Best regards,
JB Maneyrol

From: Andreea Lutac <>
Sent: Tuesday, May 21, 2019 12:40
Cc: Jean-Baptiste Maneyrol;;;;;;;
Subject: ICM20602 buffer issues with the inv_mpu6050 driver

I've been trying to get some data samples from the ICM20602 IMU using the mpu6050 driver which recently added support for it, but I'm encountering an issue with the ordering of the data in the FIFO.
According to the specs of the device, if the accel and gyro XYZ channels are enabled, then the hardware FIFO is filled with 14 bytes corresponding to the following channels: accel_x, accel_y, accel_z, temp, anglvel_x, anglvel_y, anglvel_z. However, when reading out the buffer, the value I get for anglvel_x seems to actually be the temperature. This  occurs both when reading with iio_channel_read (via libiio) and also if I read directly from /dev/iio:device with only in_anglvel_x_en set. But in_anglvel_x_raw reports correct values, which made me suspect that maybe somewhere in the driver this interleaved temp channel is not accounted for in the buffer structure.

I had a look at the driver code and inv_mpu6050_read_fifo() in particular, but I can't identify anything amiss. I've applied the recent patch that added the extra 2 temperature bytes ( ), but the problem persists. So far I've tried changing the size of the data buffer, defined in inv_mpu_iio.h:

/* 6 + 6 round up and plus 8 */
#define INV_MPU6050_OUTPUT_DATA_SIZE     24

from 24 to 32, according to the intuition that 24 corresponds to readings without temperature (i.e. 6 bytes for accel, rounded up to 8 + 6 bytes for gyro, rounded up to 8 + 8 bytes for the timestamp = 24) and thus another 8 bytes would be needed, but that doesn't seem to have solved it.

I'm quite new to driver development though, so I think there might be something I'm not getting. I would be really grateful if anyone could shed some light over what's happening here or give some advice as to what I could be doing wrong.

Best regards,
Andreea Lutac

  reply	other threads:[~2019-05-22 15:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-21 10:40 Andreea Lutac
2019-05-22 14:33 ` Jean-Baptiste Maneyrol [this message]
2019-05-23  9:44   ` Andreea Lutac
2019-05-23 10:12     ` Jean-Baptiste Maneyrol
2019-05-23 13:54       ` Andreea Lutac
2019-05-26 17:31         ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: ICM20602 buffer issues with the inv_mpu6050 driver' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).