[libgpiod] Polling precision/order

[libgpiod] Polling precision/order

[Ryan Lovelett]

I am trying to use libgpiod to listen for falling edge events to determine rotation direction for a rotary encoder and the values I'm reading seem unstable. I am starting to wonder if either my approach is flawed or libgpiod/Linux cannot be used for this purpose.

Rather than post my code and go with that I think I can explain the problem using the provided tools. Specifically, gpiomon, 
e.g., gpiomon --falling-edge --active-low gpiochip0 3 4. Here I've hooked up the rotary encoder clock and signal gpio pins 3 and 4. Spinning one direction should make 3 go low before 4 and spinning the opposite should make 4 go low before 3. Looking at the signal on the oscilloscope shows exactly that behavior.

Unfortunately, I do not see that in the gpiomon output. It is erratic and order is not always guaranteed. Is this just something that is not going to work on Linux due to the nature of interrupts on Linux? Is this a bug? Or just not supported use case?

-- 
  Ryan Lovelett

Re: [libgpiod] Polling precision/order

[Kent Gibson]

On Mon, Jun 01, 2020 at 09:59:07PM -0400, Ryan Lovelett wrote:
> I am trying to use libgpiod to listen for falling edge events to determine rotation direction for a rotary encoder and the values I'm reading seem unstable. I am starting to wonder if either my approach is flawed or libgpiod/Linux cannot be used for this purpose.
> 

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.

> Rather than post my code and go with that I think I can explain the problem using the provided tools. Specifically, gpiomon, 
> e.g., gpiomon --falling-edge --active-low gpiochip0 3 4. Here I've hooked up the rotary encoder clock and signal gpio pins 3 and 4. Spinning one direction should make 3 go low before 4 and spinning the opposite should make 4 go low before 3. Looking at the signal on the oscilloscope shows exactly that behavior.
> 

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...

> Unfortunately, I do not see that in the gpiomon output. It is erratic and order is not always guaranteed. Is this just something that is not going to work on Linux due to the nature of interrupts on Linux? Is this a bug? Or just not supported use case?
> 

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

Also, gpiomon could be part of your problem. If it is too slow dumping
events to wherever stdout goes, it will certainly cause events to be
lost...
Maybe redirect that to a file in RAM while you perform your test, then
examine the file afterwards.

Cheers,
Kent.

Re: [libgpiod] Polling precision/order

[Ryan Lovelett]

> 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.