On Thu, 23 May 2019 15:54:09 +0200 "Andreea Lutac" <andreea.lutac@xxxxxxxxxxxxxx> wrote: > Hi Jean-Baptiste, > > Thank you for the prompt response. Your explanation makes sense and I know how to at least work around this issue for now. For my current purposes, it is still useful to have the temperature data as well, so I'll stick to reading all 14 bytes for now and then see if there's a way to permanently enable temp as a more long-term solution. > > I probably wouldn't have come across this problem had it not been the case that libiio fails to enable the temp channel. Looking into it I found that libiio has an open issue where channels like temp that are neither modified, nor indexed are not counted as scan elements and thus can't be enabled. So just in case someone facing a similar issue comes across this thread, this can be either worked around by making temp an indexed channel in the driver and hopefully solved definitively by waiting for the fix to be merged into libiio. > > Thanks for all the help! > All the best, > Andreea Hi Andreea / Jean-Baptiste. One 'easy' way to make this work (based on your discussion) is to provide the available_scan_masks element of the iio_dev. That is used to find a 'superset' of the channels that have been intentionally enabled, and enable that on the hardware side. If userspace has requested something that isn't an exact match there is demux code that will automatically reorganize the incoming data so that userspace sees what it is expecting. That code will be bypassed in the event of the channel selection matching a case that is in the list. Jonathan > > > On Thursday, May 23, 2019 12:12 CEST, Jean-Baptiste Maneyrol <JManeyrol@xxxxxxxxxxxxxx> wrote: > > > Hi Andreea, > > > > I understand the issue now. The problem is that temperature data are always present in the FIFO. Even when the attribute is disabled. This is a limitation of this chip and cannot be changed on the hardware side. > > > > When temp attribute is disabled while accel and gyro are on, the iio buffer is expecting to have 12 bytes with accel + gyro data. But the driver will still provides 14 bytes with temperature in the middle since the FIFO will contain that. Always enabling temperature attribute on userspace will solve this issue, but that's certainly not the best. > > > > A correct solution would be to enforce temperature data in iio buffer by having the temp attribute always enabled and read-only in userspace. That would reflect correctly the chip capabilities. But I don't know if this is feasible. A workaround would be to add data post-processing in the driver and delete temp data when it is disabled. But I don't like this kind of workaround because that goes against iio buffer design principle. > > > > Hope this help you. > > > > Best regards, > > Jean-Baptiste Maneyrol > > > > From: Andreea Lutac <andreea.lutac@xxxxxxxxxxxxxx> > > Sent: Thursday, May 23, 2019 11:44 > > To: Jean-Baptiste Maneyrol > > Cc: stevemo@xxxxxxxxxx; jic23@xxxxxxxxxx; knaack.h@xxxxxx; lars@xxxxxxxxxx; pmeerw@xxxxxxxxxx; linux-iio@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx > > Subject: Re: ICM20602 buffer issues with the inv_mpu6050 driver > > > > CAUTION: This email originated from outside of the organization. Please make sure the sender is who they say they are and do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > Hi Jean-Baptiste and Stepan, > > > > Thanks so much for the replies and the advice. I've dug a bit deeper into this and added a few printk statements to the driver, as suggested by Stepan. It looks like the device is getting recognized correctly as ICM20602 and the buffer is being filled with 14 bytes as expected. > > > > But I've identified some strange behaviour regarding the temperature channeI. If I manually enable all 7 scan elements and read 14 bytes from the device file, the readings appear correct and change accordingly when I move the chip around. However, if I set in_temp_en set to 0 (with everything else still enabled) and read 12 bytes, the buffer doesn't seem to acknowledge this change and shift the gyro values up, instead getting only the first 12 bytes (accel_x, accel_y, accel_z, temp, gyro_x, gyro_y), without gyro_z. So this is why it looks as if temp is replacing gyro_x. > > I made a pastebin here with some of the (unconverted) values I got while testing these cases: https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_BYVqDNch&d=DwIFaQ&c=WoJWtq5JV8YrKnzRxvD8NxmTP_1wxfE0prPmo0NeZwg&r=4jiDX_1brsSWfCjfA6Ovj1d4h9MF8q7Xk5aBwG28mVk&m=sbkHiUlsj8pOWjf2iTq5CXEFvv-MNyqBKOqCjxOj9kc&s=Pmb23R-DoTj9hDwYk3qqiUfOCUWbtfpVQjUZ1lajeFI&e= > > > > Attempting the same reads with my C++ program via libiio always results in only the first 12 bytes being read, as for some strange reason libiio fails to enable the temperature channel, so iio_device_get_sample_size() is always 12 and it's actually gyro_z that I can't get to. > > > > I'll try to look through the code that is supposed to enable a channel and see why it's not succeeding via libiio. Do you have any clue as to which bit of code does the adjustment of the buffer values according to which channels are enabled? Is this done in the driver or deeper in the kernel? > > > > Thanks once again for the help! > > Best regards, > > Andreea > > > > On Wednesday, May 22, 2019 16:33 CEST, Jean-Baptiste Maneyrol <JManeyrol@xxxxxxxxxxxxxx> wrote: > > > > > Hello, > > > > > > 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 <andreea.lutac@xxxxxxxxxxxxxx> > > > Sent: Tuesday, May 21, 2019 12:40 > > > Cc: Jean-Baptiste Maneyrol; stevemo@xxxxxxxxxx; jic23@xxxxxxxxxx; knaack.h@xxxxxx; lars@xxxxxxxxxx; pmeerw@xxxxxxxxxx; linux-iio@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx > > > Subject: ICM20602 buffer issues with the inv_mpu6050 driver > > > > > > 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 ( ), 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 > > > > > >
