Re: iio channel sync

[Jonathan Cameron <jic23@kernel.org>]

On 31/08/16 23:47, Joshua Clayton wrote:
> Greetings,
> 
> On 08/30/2016 09:26 AM, Jonathan Cameron wrote:
>>
>> On 30 August 2016 08:41:18 BST, Matt Ranostay <mranostay@gmail.com> wrote:
>>> On Mon, Aug 29, 2016 at 10:03 AM, Joshua Clayton
>>> <stillcompiling@gmail.com> wrote:
>>>> Jonathan,
>>>>
>>>> I have an out-of tree driver I am working on mainlining.
>>>>
>>>> The device is a sensor that gets phase and amplitude (x and y) data
>>>>
>>>> on multiple physical and/or time multiplexed channels.
>>>>
>>>> It also has up to 4 optical encoders to get physical location.
>>>>
>>>> The existing driver bundles x and y together with a snapshot
>>>>
>>>> of the encoder sums at that moment.
>>>>
>>>>
>>>> This seems like a good fit for iio, but one item is bothering me.
>>>>
>>>> How is synchronization between streams usually handled with
>>>>
>>>> iio drivers? Timing can be important.
>>> Wouldn't the trigger buffer framework be good enough for this?
>> Perhaps you could describe your usecase a little more?
>>
>> Is the interesting bit that you want to sync streams with different
>> sampling frequencies? Are those encoders better represented by a
>> separate driver? (In which case I have some thoughts on simple
>> additions to IIO trigger handling that might help - basically a
>> hold off on triggers until all relevant devices are attached)

> Thanks for responding.
> 
> The encoders (often a pair of them, could be up to 4) represent the position
> of the sensor in relation to an object to be tested. (linear movement or
> rotation around an axis).
> The Maximum sample rate of the encoders is much higher than the sensor,
> but they are moved by a motor or by hand, so the actual sample rate is
> variable and may be higher or lower that the sensor sample rate.
> 
> The encoders are sometimes used as a trigger for data collection,
It would certainly be possible to do this by having a slightly unusual type
of trigger.
> but
> the encoders are also used as positional data alongside the sensor data.
Makes sense.
> 
> The way we get around this now is to bundle a snapshot of the encoder
> with the sensor data and discard it later if the encoder hasn't changed and
> the trigger function is enabled.
The only slight change I'd suggest is that if the encoders are read by
separate hardware (presumably they are into a capture unit of some type?)
then you may need to have the encoder capture triggered off the same
trigger as the sensor data.  Thus you'd end up with two buffers that
could be easily fused in user space.

That would allow  generic drivers for other users of either the sensor
or the encoder capture hardware.

If they come in through the same bit of hardware (e.g. you are routing
them both through an fpga or similar) then fine as you have it currently.

Sounds like an interesting bit of hardware ;) Some sort of radio test kit
around an antenna? (feel free to not answer, I'm always curious)

Jonathan
>