User Space GPIO Interrupt programming - GSoC-2018

Tue Dec 1 05:15:14 UTC 2020

Am 30.11.2020 um 18:52 schrieb Ian Lepore <ian at freebsd.org>:
> On Fri, 2020-11-27 at 19:45 -0300, Dr. Rolf Jansen wrote:
>> Am 27.11.2020 um 15:04 schrieb Ian Lepore <ian at freebsd.org>:
>>> On Fri, 2020-11-27 at 10:16 -0700, Ian Lepore wrote:
>>>> On Fri, 2020-11-27 at 14:28 +0300, Vladimir Goncharov wrote:
>>>>> Here it is.
>>>>> There is struct gpioc_event with pin number and bintime which
>>>>> is send
>>>>> to userspace.
>>>>> 
>>>>> Also I'm thinking about to implementation notofication without
>>>>> extra
>>>>> reading from socket via struct kevent's extra fields
>>>>> (fflags/ext[4]),
>>>>> looks like it is possible.
>>>>> 
>>>> 
>>>> Please don't top-post on freebsd mailing lists.
>>>> 
>>>> I think we need a way for the app to choose whether it wants
>>>> simple
>>>> reporting of pin number (like the original code) perhaps along
>>>> with a
>>>> count, versus requesting detailed per-event data.  I'm going to
>>>> propose
>>>> something more detailed about this as soon as I get my thoughts
>>>> all
>>>> organized.  I also want to get the original code and the locking
>>>> fixes
>>>> I've done to it into a phab review for people to start looking at
>>>> before starting to do new major changes to it.
>>>> 
>>>> Allocating memory in the interrupt handler isn't a good idea, it
>>>> will
>>>> just increase latency on processing other pin interrupts and lead
>>>> to
>>>> inaccurate timestamps.  IMO, it would be better to allocate a
>>>> fixed
>>>> array of events; when the app requests detailed event reporting
>>>> it can
>>>> request the number of stored events it wants handled and we could
>>>> allocate all at once based on that.
>>>> 
>>> 
>>> The gsoc2018 code, with locking and style(9) fixes, is now at:
>>> 
>>> https://reviews.freebsd.org/D27398
>> 
>> I got it working, and as expected, by your comments the level
>> interrupt mode has been disabled. I am OK with this. Later, I will
>> add more comments on this in my response to you other e-mail.
>> 
>> Best regards
>> 
>> Rolf
> 
> I've just updated the phabricator review with new code.  This adds the
> detailed versus summary reporting.  I decided the detailed reporting
> should still be the default like it was before, but now it can handle
> many events between calls to read(), unlike the old code that only
> stored one pin change event between calls.  Now it uses a circular
> buffer, and there's a new ioctl function for increasing the size of the
> buffer (or switching to summary reporting mode).
> 
> I incorporated Christian's test program into the phab review, and added
> some enhancements to it.  It shows how to read and interpret the new
> detailed and summary structures, how to convert the monotonic clock
> event timestaps to UTC if needed (*), and how to handle getting
> multiple event notifications with each read() call (by passing a big
> buffer and parsing the structs from it after the call).
> 
>  https://reviews.freebsd.org/D27398
> 
> (*) The conversion of monotonic to utc time doesn't attempt to deal
> with the system clock being stepped between the time an event was
> recorded and when it is printed.  In the real world, system time gets
> stepped when the system boots, not at random while apps are running.
> 
> -- Ian

I just tested it, by utilizing the gpioevent test tool. And everything is working exactly the way, I need it. For example, on the BBB, I connected a quite worn-out push button to a GPIO in PU mode and to DGND. This button is known to bounce heavily. Now with your enhancements and the new tool which reports the timestamps, I could do debouncing in software.

gpioevents -f /dev/gpioc2 -m r 3 er

Again this is a really bad button, however the BBB seems to be able to pick up the bounces in less than a ms resolution. I don’t need more.

Press:
time 1122.784614858 pin 3 state 1
time 1122.786906911 pin 3 state 1
time 1122.787700011 pin 3 state 1
time 1122.787758051 pin 3 state 1
time 1122.788112206 pin 3 state 1
time 1122.788434696 pin 3 state 1
time 1122.788699563 pin 3 state 1
time 1122.788742728 pin 3 state 1
time 1122.788775310 pin 3 state 1
time 1122.788962180 pin 3 state 1
time 1122.789201714 pin 3 state 1
time 1122.789409790 pin 3 state 1
time 1122.791530140 pin 3 state 1
time 1122.792603357 pin 3 state 1
time 1122.792638730 pin 3 state 1
time 1122.792694146 pin 3 state 1
time 1122.792759185 pin 3 state 1
time 1122.792782851 pin 3 state 1
time 1122.792858890 pin 3 state 1
time 1122.792903722 pin 3 state 1
time 1122.792926555 pin 3 state 1
time 1122.793038426 pin 3 state 1
time 1122.793119549 pin 3 state 1
time 1122.793301335 pin 3 state 1
time 1122.793501662 pin 3 state 1
time 1122.793565368 pin 3 state 1
time 1122.793608283 pin 3 state 1
time 1122.793768903 pin 3 state 1
time 1122.794032353 pin 3 state 1
time 1122.797496036 pin 3 state 1
time 1122.797512911 pin 3 state 1

Release
time 1122.933694459 pin 3 state 1
time 1122.933713000 pin 3 state 1
time 1122.933749748 pin 3 state 1

What is the expected significant time resolution. 9 digits suggests that it is nanoseconds, however, I tend to believe, that it is perhaps microseconds (6 digits after the dp), isn’t it?

Please let me know, if you want me to test anything else.

Please inform me once all this becomes committed to head, then I can remove the patched files and svn-update the sources for the custom kernel.

Thank you very much.

Best regards

Rolf