Re: Need help with libgpiod gpiod_line_request_both_edges_events()

[Bartosz Gołaszewski <bartekgola@xxxxxxxxx>]

2018-03-06 22:02 GMT+01:00 Timur Tabi <timur@xxxxxxxxxxxxxx>:
> On 03/06/2018 02:53 PM, Bartosz Gołaszewski wrote:
>>
>> 2018-03-06 21:49 GMT+01:00 Timur Tabi <timur@xxxxxxxxxxxxxx>:
>>>
>>> On 03/06/2018 01:30 PM, Timur Tabi wrote:
>>>>
>>>>
>>>>
>>>> Never mind, I figured it out.  I was passing the wrong parameter to
>>>> pthread_create().  Everything works now.
>>>>
>>>> Thanks for all your help.  libgpiod makes a lot more sense to me now.
>>>
>>>
>>>
>>> So I found one small oddity.
>>>
>>> When I start the interrupt test, the output pin is set to 1, and
>>> therefore
>>> the input pin is also set to 1 since they're wired together.
>>>
>>> It appears that gpiod_line_event_wait() is receiving a rising-edge event
>>> when I call gpiod_line_set_value(..., 1).  That is, the input is reading
>>> 1,
>>> and it is still set to 1, but I get a rising event anyway.
>>>
>>
>> This is normal, you're generating an interrupt anyway.
>
>
> How is that possible?  I'm not writing to the input line directly.  It
> should see a continuous stream of "1", so there should be nothing that
> triggers an interrupt.  If the output is "1", and I call
> gpiod_line_set_value(output, 1), there should be no electrical changes on
> that output pin.
>
> If I do this:
>
> gpiod_line_set_value(output, 1);
> gpiod_line_set_value(output, 1);
> gpiod_line_set_value(output, 1);
> gpiod_line_set_value(output, 1);
> gpiod_line_set_value(output, 1);
> gpiod_line_set_value(output, 1);
>
> I should see no changes on a scope attached to the GPIO.  So how could there
> be an interrupt?
>

This depends on your controller doesn't it? The driver will perform
its write operation (e.g. register write) and the controller may or
may not generate a signal.

>>> At one point, I told it to write a 0 to output, and I still got a rising
>>> event:
>>>
>>
>> This isn't normal - do you have an strace output for that? We need to
>> figure out if it's something in libgpiod or in the kernel.
>
>
> write(1, "Running interrupt test", 22)  = 22
> write(1, "\n", 1)                       = 1
> mmap(NULL, 8388608, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0xffff99fa0000
> mprotect(0xffff99fa0000, 65536, PROT_NONE) = 0
> clone(child_stack=0xffff9a79eb20,
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
> parent_tidptr=0xffff9a79f2e0, tls=0xffff9a79f900,
> child_tidptr=0xffff9a79f2e0) = 24048
> close(5)                                = 0
> ioctl(3, _IOC(_IOC_READ|_IOC_WRITE, 0xb4, 0x04, 0x30), 0xffffec347160) = 0
> ioctl(3, GPIO_GET_LINEINFO_IOCTL, 0xffffec3470b8) = 0
> ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0xb4, 0x08, 0x40), 0xffffec347170) = 0
> write(1, "Initial input value: 1\n", 23) = 23
> futex(0xffffec347470, FUTEX_WAKE_PRIVATE, 2147483647) = 1
> ppoll([{fd=5, events=POLLIN|POLLPRI}], 1, {1, 0}, NULL, 8) = 1 ([{fd=5,
> revents=POLLIN}], left {0, 999996600})
> read(5, "\20i\272\226Tp\31\25\1\0\0\0\0\0\0\0", 16) = 16
> ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0xb4, 0x08, 0x40), 0xffffec347170) = 0
> write(1, "Received rising edge event, valu"..., 56) = 56
> ppoll([{fd=5, events=POLLIN|POLLPRI}], 1, {1, 0}, NULL, 8) = 1 ([{fd=5,
> revents=POLLIN}], left {0, 999998200})
> read(5, "\17J\300\226Tp\31\25\2\0\0\0\0\0\0\0", 16) = 16
> ioctl(5, _IOC(_IOC_READ|_IOC_WRITE, 0xb4, 0x08, 0x40), 0xffffec347170) = 0
> write(1, "Received falling edge event, val"..., 56) = 56
> futex(0xffff9a79f2e0, FUTEX_WAIT, 24048, NULL) = 0
> write(1, "All tests passed", 16)        = 16
>
> I've attached the latest version of my code.
>
>>> Oscillate thread started
>>> Initial input value: 1
>>> Setting output to 0
>>> Received rising edge event, value=0, elapsed=-0.000204s
>>>
>>> And it apparently went backwards in time.
>>>
>>> What happens in this scenario:
>>>
>>> 1. gpiod_line_request_both_edges_events() is called
>>> 2. GPIO line transitions from 0 to 1
>>> 3. gpiod_line_event_wait() is called
>>>
>>
>> Is it possible that this event was queued in the kernel buffer and
>> that you actually read one of the previous events?
>
>
> Yes, it's very possible.  How do I flush that queue?

Read events in a loop as long as poll() doesn't return timeout.

-- 
Best regards,
Bartosz Golaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html