Re: [libgpiod] Polling precision/order

["Ryan Lovelett" <ryan@xxxxxxxxxxx>]

> Your approach isn't ideal.  It would be better to receive interrupts on
> both edges of one line, and compare the phase of the the two lines
> at that time to determine direction.  Depending on the responsiveness of
> your platform you may be able to do that from userspace - depends on
> how the interrupt rate compares to the interrupt latency to userspace.

That was my feeling as well. Thank you for that hint.

> The GPIO uAPI does not guarantee ordering of events across multiple
> lines, so mis-ordering is possible.  Also, the interface to userspace is
> buffered and it is possible for the buffer to overflow so events can be
> lost.  Obviously either of those would play havoc with your algorithm.
> What the uAPI does provide is timestamps on the events, and if I were
> you I would be looking at those.  That would provide you with ordering
> and spacing, and probably provide some clues as to the underlying
> problem.  e.g. if the timestamps are jumbled then you are getting
> mis-ordering.  If the spacing is less than you are seeing on your scope
> then you may have noise.  If the spacing is greater than you are seeing
> on your scope then you may be losing events...

I've found the timestamps and they to be jumbled. So I think I'm getting mis-ordering.

> I'd rather not speculate - more information required.
> It certainly isn't a use case that the GPIO uAPI is ideal for.

I think in general, that was my feeling. This approach might just not be right. I think I'll try a different approach. Thank you for the thoughts and feedback.