Buffers and sampling frequency

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

 



Hi,

I'm trying to add triggered buffer support to the bmi160 IMU driver and
a question came up that I don't know the answer to.  The driver defines
an x, y, z channel of type IIO_ACCEL and an x, y, z channel of type
IIO_ANGL_VEL.  Then within each of these channel definitions,
info_mask_shared_by_type is set to:
BIT(IIO_CHAN_INFO_SCALE) | BIT(IIO_CHAN_INFO_SAMP_FREQ)

This means that the driver allows for a different sampling frequency on
the accelerometer and gyro components.  The chip has a hardware FIFO and
the chip is configurable whether the FIFO is in headerless or header
mode.  In header mode the header tells the reader the structure of the
data.  Here's a relevant snippet from the datasheet
(https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BMI160-DS000-07.pdf):

> In contrast, the header mode is intended for situations where flexibility in the data structure is required, e.g. when sensor run at different ODRs or when switching sensors on or off on the fly during operation.

Do IIO buffers support the case where multiple channels are enabled that
have different ODRs (sampling frequencies)?  It seems to me like the
client on the receiving end of the buffer will receive samples of a
fixed size equal to the sum of the sizes of all the enabled channels and
that the client can only look at which channels are enabled.  They can't
distinguish which channels are populated in the current sample.

Am I correct about this limitation?  If so, what is the suggested
behavior by the driver?  Should the channel definitions be changed so
that sampling frequency is info_mask_shared_by_all?  Or should I do
something like use iio_buffer_setup_ops.validate_scan_mask to validate
that the sampling frequency is equal for all channels specified by the
scan_mask?

Thanks,
David



[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