> It is only intended for those rare
> cases where someone really wants to use a 1000 dolar IMU as a mouse.
> Not relevant here though.
We have a mouse application that is significantly less expensive than
$1000, so it might actually be relevant, in the future.
> > If the DMP is
> err, DMP?
Digital Motion Processor. It is what we call the built in micro
controller on the mpu3050 that does sensor fusion.
> > used, a buffer for the FIFO data would be created, and user space
> would be
> > responsible to push the sensor data back to iio after sensor fusion
> and
> > calibration. Without the DMP, each sensor driver would act
> independently
> > providing their own raw data.
>
> Strangely enough, your need to push data back is not dissimilar to what
> we have
> discussed in the past for DACs. Right now we only have a slow and
> simple interface
> for DACs, mainly because doing anything clever requires some fairly
> nasty additions
> to the host bus drivers and no one has had the time. Michael has
> almost
> certainly thought more on this than I ever have!
A slow interface might be ok. Highest traffic is usually in the low 10's
of bytes at 30hz.
> > We still need a way to read and write registers and DMP memory during
> > runtime from user space.
> I guess the DMP is the on device processor? So what you write varies a
> lot
> with what firmware is loaded?
Yes that is correct.
> So let me just check I understand the data flow here.
>
> Example
>
> Magnetometer -> kernel -> userspace interface -> hideously complex
> algorithm ->
> kernel -> mpu -> mpu fusion algorithm in relevant firmware -> userspace
> ?
Hideously complex algorithm or HCA for short :)
Your data path is more relevant for the mpu6050. I'll explain what it
currently looks like on each chip 2 chips. For the 3050 it looks like
this:
=======================
Accel -> mpu3050 -> DMP (6 Axis fusion) -> FIFO
(gyro) ^
|
Kernel
|
FIFO -> Kernel -> user space -> 9 Axis fusion + HCA's-> application
^
|
Compass -> kernel -> user space --/
For the mpu6050:
================
Compass -> mpu6050 -> DMP (9 Axis Fusion) -> Kernel -> User Space HCA's
-> Apps
(gyro + accel) ^ |
| |
\---------------- Kernel <------/
As you might have seen we don't have an input or an iio interface for user
space to retrieve data. Currently applications have to link in our MPL,
either standalone, or as a daemon, or something similar like the Android
sensor HAL. What I'm trying to figure out is once data is ready to be
provided to applications, where should it come from, input, IIO, or a
daemon, before I start that part of development. It seems like IIO was
built more for raw data, but that input has a facility to handle processed
data.
> So how do we know the mpu wants data? Obvious options that might be
> the case
> a) on chip fifo with flow control.
> b) interrupt to request data?
> c) Always feed latest value and it runs unsynchronized.
The MPL (Motion Processing Library user space library that includes HCA's)
makes the decision when to feed data down, and does it in an
unsynchronized way. It will do it shortly after processing a FIFO data
packet, but the timing does not need to be precise.
> Do we actually have that hideously complex algorithm in userspace
> element
> or did I invent that part? If not, we might want to use some in kernel
> hooks to pass the data back bypassing userspace entirely.
Yes the HCA's exists. They include 9 axis fusion, compass calibration
algorithms, and a number of other proprietary algorithms. We've tried to
design the MPL so that they can be removed and still provide basic
functionality. This basic functionality is available to be pushed into
the kernel if necessary, but we will still need a way to support the
HCA's.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
