On 15/09/2020 12:12, Computer Nerd Kev wrote:
> I've been dealing a lot with Pi interrupts in Linux lately, but with
> a somewhat different application to yours. In my case I've ended up
> cheating my way out of setting up an interrupt-driven system in Linux
> (for now) by avoiding/disabling the system interrupts and polling an
> input.
>
yuk. No way!

> These are my links for when I go back and try to implement things
> "properly" so that I'm not wasting so many cycles polling (I believe
> I'll have to write a Linux kernel driver, but my timing requirements
> are much tighter than 50ms):
>
I don't think you should have to do that. I believe I saw that the gpio
interrupts can be handled by a your own routine

A kernel driver is not the hardest thing to write, anyway.


> *Interrupts can be used to avoid polling the edge detection register.
>   Need to use the Linux GPIO subsystem and poll() in C.
>   -A sort-of example:
>    
https://stackoverflow.com/questions/34808276/poll-on-raspberry-gpio-sysfs-raspb
erry
>   -Best (fastest) interrupt handling would require a proper Linux
>    device driver. Or running bare-metal.
>    -Example of the latter:https://github.com/enricorov/Pinterrupt

The advantage of bare metal is that you control the environment totally,
the disadvantage is you have to write your own networking drivers to use
networkimg and usb drivers top use that.


>   -See:https://www.raspberrypi.org/forums/viewtopic.php?p=1149836
>     -- Notes some measured interrupt response times

"For the record the normal driver response is about ten to twenty times
faster than user space .. usual quoted numbers
Jessie user space: tmin =179 us tave = 280us tmax = 511us
Jessie driver space: tmin = 6us tave = 12us tmax = 43us"

Bugger. I really wanted to be in and around 25uS total time to service
the interrupt.

Kernel driver at least on i/o to achieve buffering to carry past that
delay  looks needful..


>   -Some valuable low-level info:
>    http://xinu.mscs.mu.edu/Interrupt_handling_(Raspberry_Pi)

No link found

>   -Hints at usage with Linux:
>   
https://www.iot-programmer.com/index.php/books/22-raspberry-pi-and-the-iot-in-c
/chapters-raspberry-pi-and-the-iot-in-c/55-raspberry-pi-and-the-iot-in-c-input-
and-interrupts?start=1
>    -Getting into it properly here:
>    
https://www.iot-programmer.com/index.php/books/22-raspberry-pi-and-the-iot-in-c
/chapters-raspberry-pi-and-the-iot-in-c/55-raspberry-pi-and-the-iot-in-c-input-
and-interrupts?start=2

Hmm. So its either code device drivers to get speed, or code your own
network drivers and write a minimal real time kernel.

Many thanks for all that. It narrows the options down enough to be of
use in deciding whether to use a pi at all.


--
“The urge to save humanity is almost always only a false face for the
urge to rule it.”
– H. L. Mencken

--- SoupGate-Win32 v1.05