On Fri, 16 Nov 2018 18:36:46 +0000 "Medenblik, H.J.W. (Henk)" <henk.medenblik@xxxxxx> wrote: > Hi Jonathan, Hi Henk, > > I was triggered by this mail because here was something mentioned about > metadata in FIFO's and the use within iio. > I am currently designing some FPGA functionality and originally I also > wanted to use metadata in front of the actual payload data of my IIO > device (which is a radar acquisition system). > Therefore I was wondering if there never have been a request to support > a metadata feature in the iio framework. Is this because of complexity > or does it have another reason? The problem has always been that it is extremely difficult to design a userspace ABI that is generic if we have metadata inside the dataflow. In theory we could do a very limited set of cases, but then we in turn have to provide meta data to describe the metadata. It might be possible to do it, but it's a very complex challenge. If it is just for a particular device, then it can of course be done, but at that stage there is limited point in using an upstream IIO driver as you have to have custom userspace handling to do anything useful with it. > In my case I would like to add this metadata to inform the user with > formatting of the payload data but it would also give us a manner to > include hardware timestamps which can be used to correlate with other > captured data (from other sensors). For timestamps it is possible to include them as a normal channel type. We have a small number of existing devices doing this. In theory a number of devices we support do dynamic formatting (usb-hid sensors for starters) but the reality is that it is almost never implemented because it doesn't make sense and is very hard to interpret - again we come back to custom userspace code. I'm yet to meet a strong usecase for dynamic formatting. If it comes along, I think it would be better treated as a datatype embedding the data and the dynamic formatting (which tends to be a scale factor) rather than as a separate meta data block. That would be easier to write generic code against. Thanks, Jonathan > > With kind regards > Henk > > On 16-11-18 18:17, Jonathan Cameron wrote: > > On Wed, 14 Nov 2018 09:36:42 -0800 > > David Frey <dpfrey@xxxxxxxxx> wrote: > > > >> Hi, > > Hi David, > > > >> 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): > > Yeah. This is an annoyingly common hardware design. To my mind it's overkill > > as the chances of any software actually taking full advantage of different > > frequencies of data is fairly low. > > > > Also note that typically sampling frequency controls have additional side > > effects in terms of filtering etc which apply to data not coming through > > the fifos. > > > >>> 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. > > Indeed you are correct on that but there are ways of handling this if > > it actually matters enough. > > > >> 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? > > So, when we first met devices that did this sort of tagged data (which > > as you have observed doesn't fit with our data model at all), we did > > exactly what you say and had drivers only support a shared data rate > > across all their data types (basically don't use the tagged modes). > > > > There is however, one bit exception in tree which offers another (more > > complex path), the lsm6dsx. In that case we actually register multiple > > iio devices, one per data type, handle the complexity of bringing them > > up appropriately and then push data to the right iio device dependant > > on the tag. I've always been in two minds about this. One side effect > > is you loose the implicit association between channels of different types > > and have to align the data using timestamps in userspace which is ugly, > > but if we need to support it that is the only way to do it in a model > > where we don't carry meta data in the buffer. > > > > Now to support this in the bmi160 which supports (I believe) the > > headerless mode already, we would have to continue supporting a single > > device, but could potentially have additional auxilliary devices on which > > channels can be enabled if you want to have the data with header mode > > with uneven sampling frequencies. It can be done, but it'll make for > > a somewhat unexpected userspace interface which is perhaps not a good > > thing. > > > > So the question is whether your question is abstract, or you have a > > real usecase that needs the uneven sampling? Or have you just spotted > > a bug with how it currently works and want to fix that (so the frequencies > > are in lock when the buffer is enabled?) > > > >> Thanks, > >> David > > Jonathan > > > > This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages. >
