Re: GPIO inputs on Pis?

> Am 24.01.2023 um 13:58 schrieb Karl Denninger <karl@denninger.net <mailto:karl@denninger.net>>:
> 
> On 1/24/2023 10:43, Dr. Rolf Jansen wrote:
>> I sent an old ink to the thread on the mailing list, which does not work anymore. Here ist the new link:
>> 
>> https://lists.freebsd.org/pipermail/freebsd-arm/2020-November/022738.html <https://lists.freebsd.org/pipermail/freebsd-arm/2020-November/022738.html>
>> 
>>> Am 24.01.2023 um 12:35 schrieb Karl Denninger <karl@denninger.net <mailto:karl@denninger.net>>:
>>> 
>>> Thank you -- will check it out.
>>> 
>>> On 1/24/2023 10:35, Dr. Rolf Jansen wrote:
>>>>> Am 23.01.2023 um 11:41 schrieb Karl Denninger <karl@denninger.net <mailto:karl@denninger.net>>:
>>>>> 
>>>>> Is there support somewhere in the 13.x for other than "read current state" / "set current state"?
>>>>> 
>>>>> Specifically, there is evidence in the sys/gpio.h header file that I can open up a file descriptor and then use select()/read() to grab the contents of a ring buffer of some size (presumably interrupt-posted) of events since last look, and determine if there's anything in there.  Provided you're reasonably fast this might be enough to, for example, read an optical encoder that has a modest pulse rate.
>>>>> 
>>>>> I see apparent review code at https://reviews.freebsd.org/D27398 <https://reviews.freebsd.org/D27398> from late 2020, but nothing else I can find digging around; an example (assuming it is actually implemented and works) would be helpful
>>>>> 
>>>> See
>>>> 
>>>> https://forums.freebsd.org/threads/gpio-api-general-orange-pi-h3.83950/post-556728 <https://forums.freebsd.org/threads/gpio-api-general-orange-pi-h3.83950/post-556728>
>>>> 
>>>> And the messages in that thread that follow the one linked above.
>>>> 
>>>> There is a respective thread on this mailing list as well:
>>>> 
>>>> Porting FreeBSD to ARM processors: User Space GPIO Interrupt programming - GSoC-2018 <https://lists.freebsd.org/archives/freebsd-arm/2020-November/022740.html>-- 
>>> Karl Denninger
>>> karl@denninger.net <mailto:karl@denninger.net>
>>> The Market Ticker
>>> [S/MIME encrypted email preferred]
>> 
> So the answer at this point appears to be "not in the codebase and no indication on when/if it might be, but there are patches that are in some state of development.“
> 
No, at this point (13.1-RELEASE) everything is in the kernel, no patches needed. Even the test tool made it into the source tree. It has only be renamed from gpioc_intr_test.c to gpioevents.c.

/usr/src/tools/test/gpioevents/gpioevents.c

The documentation is missing. It is however easy to learn how things work by examining the code of gpioevents.c.

> Being able to read an encoder of some sort basically means being able to know how many events occurred between "looks"; for most purposes you don't need each event delivered exactly when it occurs, but missing some of the counts entirely is not acceptable.

Yes, and for this reason, this GPIO event code which was developed by Christian Krämer in the course of the GSoC-2018 and has been submitted in 2020 by Ian Lepore to the freebsd tree is perfect.

Ian tested it with a 10 MHz sqaure wave on an imx6 (ARMv7, 1GHz) and got an event every 10 µs. That means the max. speed without event losses would be 100 kHz. I did not do exact measurements, however, my impression is that my RPi4B can do it a tad faster than my BeagleBone Black. With the RPi4, I needed to improve the debouncing of the encoder and the buttons, because it saw hundreds of bounces which the BBB didn’t. However, it may also be, that the internal GPIO circuits of the BBB have a different damping characteristic.

Anyway for my applications, 100 kHz way faster than what I need.

On my GitHub repository I placed another example on using the GPIO events for the RPi:

https://github.com/cyclaero/shutdd <https://github.com/cyclaero/shutdd>

See also the respective thread on this mailing list:

https://lists.freebsd.org/archives/freebsd-arm/2022-July/001576.html <https://lists.freebsd.org/archives/freebsd-arm/2022-July/001576.html>