Re: GPIO inputs on Pis?

On 1/24/2023 2:15 PM, Dr. Rolf Jansen wrote:
>> Am 24.01.2023 um 13:58 schrieb Karl Denninger <[email protected]>:
>>
>> 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 <[email protected]>:
>>>>
>>>> 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 <[email protected]>:
>>>>>>
>>>>>> 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 
>>>>>> athttps://reviews.freebsd.org/D27398from 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
>>>> [email protected]
>>>> /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
>
> See also the respective thread on this mailing list:
>
> https://lists.freebsd.org/archives/freebsd-arm/2022-July/001576.html
Ok, I misunderstood.  Thank you; will look into it and give it a crack, 
this is good news.
-- 
-- Karl Denninger
/The Market-Ticker/
S/MIME Email accepted and preferred