LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Andreea Lutac" <andreea.lutac@fixposition.ch>
To: unlisted-recipients:; (no To-header on input)
Cc: jmaneyrol@invensense.com, stevemo@skydio.com, jic23@kernel.org,
	knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net,
	linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: ICM20602 buffer issues with the inv_mpu6050 driver
Date: Tue, 21 May 2019 12:40:32 +0200	[thread overview]
Message-ID: <42bd-5ce3d580-2b-ca9e8b0@181689754> (raw)

Hello,

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 (https://patchwork.kernel.org/patch/10882883/), 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-21 10:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-21 10:40 Andreea Lutac [this message]
2019-05-22 14:33 ` Jean-Baptiste Maneyrol
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=42bd-5ce3d580-2b-ca9e8b0@181689754 \
    --to=andreea.lutac@fixposition.ch \
    --cc=jic23@kernel.org \
    --cc=jmaneyrol@invensense.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    --cc=stevemo@skydio.com \
    --subject='Re: ICM20602 buffer issues with the inv_mpu6050 driver' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).