Re: GPIO inputs on Pis?

On 1/24/2023 14:15, Dr. Rolf Jansen wrote:
> 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

So..... just to see  if I'm understanding this correctly (pretty sure I 
am having read through the test code).

Presume I have "X" pins configured as inputs and "Y" configured as 
outputs.  I use the ioctl calls to set the outputs (which works just 
fine) and can read current input state (which also works.)

If I set /on the same descriptor /(not on the specific pins; it applies 
to all input pins on that descriptor as it appears there's no 
pin-specific setting in the configuration flags to enable this on a 
pin-by-pin basis) the event report config type I want I can then 
select() on the descriptor with the usual timeouts (or zero for a poll) 
and get a "ready" (much as one would for any other sort of I/O) and, if 
I do get a "ready" return on the descriptor a read() on that descriptor 
will return zero or more structures of the type I said I configured, 
each of which describes either an individual state change on one of 
configured input pins that is set up for individual event reporting OR a 
structure of the summary of changes for a given pin.  I assume given the 
16-bit "count" field on the summary return that counts are "since last 
returned" and not "since boot" or "since descriptor was opened and 
configuration set."

This also presumes that there is some buffer depth on this that, at some 
point, may be exceeded so if I "go away" for too long I may miss things 
-- particularly if I need detail-level reporting.

Thus it looks like that its possible for most cases (assuming resolution 
of the time stamps is high enough and the driver timing is accurate 
enough, plus the code is sparse enough that actually does the reading) 
to not just read an optical encoder with this but also (if you use 
detail reporting) to read a bi-phase encoder so you can determine which 
direction it is moving.

On to check it out; if I missed something here a "heh idiot, no it 
actually works like this!" would be appreciated :-)

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