Re: GPIO inputs on Pis?

From: Karl Denninger <karl_at_denninger.net>
Date: Tue, 24 Jan 2023 16:58:31 UTC 
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
>
>> Am 24.01.2023 um 12:35 schrieb Karl Denninger <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>:
>>>>
>>>> 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 
>>>> 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
>>>
>>> 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
>> /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."

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.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/