RE: [PATCH 3/3] iio: imu: mpu6050: Add support for auxiliary I2C master

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The Maximum of AKM is 110Hz. That is where the data come from. You are right. We could miss data without interrupt function. I guess it is because the measurement value is more static. All we need to do is to "re-sample" the data, such as pressure and proximity or light sensor. As long as we sample fast enough, we don't miss data. If you insist not losing any data, interrupt is the way to go. This is more like "polling". For the AKM compass, it is single measurement mode. The data is stored in the register after measurement. It won't get lost.

Thanks

Ge



-----Original Message-----
From: De Marchi, Lucas [mailto:lucas.demarchi@xxxxxxxxx] 
Sent: Thursday, March 17, 2016 2:16 PM
To: Baluta, Daniel; mranostay@xxxxxxxxx; Ge Gao
Cc: lars@xxxxxxxxxx; knaack.h@xxxxxx; jic23@xxxxxxxxxx; cmo@xxxxxxxxxxx; linux-iio@xxxxxxxxxxxxxxx; adi.reus@xxxxxxxxx; srinivas.pandruvada@xxxxxxxxxxxxxxx; pmeerw@xxxxxxxxxx; Ranostay, Matt
Subject: Re: [PATCH 3/3] iio: imu: mpu6050: Add support for auxiliary I2C master

Hi,

On Thu, 2016-03-17 at 18:11 +0000, Ge Gao wrote:
> Hi Matt,
> 	I am not sure about slave 4. I always use slave0~3. MPU6050 can 
> connect up to 4 slaves by using slave 0~3. However, we only use 3 slaves.
> Each slave can be configured as read or write independently. For 
> example,
> AKM8973 compass as a slave, I usually configure slave0 as read and 
> slave 1

I also usually use slaves 0~3. However now you mention it as being 100Hz...
doesn't this depend on a) the rate configured in MPU and b) the part itself
(MPU9250 has a different internal sampling rate)?

> 	For pressure sensor or ALS(light/proximity sensor), they all have 
> autonomous mode. As long as the sample period is longer than the 
> output rate, the data is guaranteed to be new data.

I think his use of slave4 is mostly because of the interrupt that is availabe.
Depending on the sensor you are connecting, the sample rates not matching may be a problem.

Suppose your sensor is giving you data at 125Hz. This means every ~4 samples you will loose one sample.  The other case of sensor with update at 75Hz is also problematic since you may get old data - and depending on the sensor you don't have a way to know if the data is invalid.

What am I missing?


thanks

Lucas De Marchi
��.n��������+%������w��{.n�����{��(��)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux