C++ fstream GPIO Trigger/Interrupt

[Ceos]

Weil das Kernel und Standard C lösen können und dann ist es kompatibler für andere Platinchen mit Linux

Was ich darüber so gelesen habe, brauchst du Kernelunterstützung um "echte" Interrupts zu bekommen, daher erwähnte ich das mit Wiring Pi und der Unterstützung am Rasppbery Pi, aber ohne Kernelunterstützung kannst du wohl maximal so schnell werden wie der Kernel dir für das GPIO-device ein udate macht und dann über inotify ein signal geben lassen. Aber ob es auch andere wege gibt habe ich leider keine Ahnung.

Inotify brauch übrigens keine FDs sondern nur den Pfad zur überwachenden Datei/Ordner (achtung bei änderungen an dateien im ordner selbst werden nicht zwingend signale vom ordner-notifier ausgegeben, das ist wohl vom dateisystem abhängig)

[alexander_ro]

GPIO sind ja keine echten Interrupt. Deshalb bezeichne ich die auch immer als Trigger das kommt besser hin. Ein echter Interrupt muss von der Hardware auch als solcher unterstützt werden und echte Hardware Interrupt macht der Kernel selber die Steuerung. Kann so ein Ereignis aber auch wieder an den Userspace weiterreichen. Ich weiß nicht ob der Raspi an seinem Stecker einen echten Hardware Interrupt herausführt. Bei den AVR gibt es so was aber auch dort kann das nicht jeder Port.

Man kann aber so tun als ob ein GPIO ein Interrupt ist das ist dann ein Software Interrupt so zu sagen. So ähnlich wie das auch bei PWM ist die kann man in Hardware haben und in Software Simulieren.

Inotify kenne ich jetzt nicht so gut ich weiß auch nicht wie schnell das ist weil es relativ kompliziert aussieht. Für diesen Zweck würde ich jetzt eher epoll oder poll benutzen. Wenn man dem glaubt was geschreiben steht ist epoll schneller als poll, Dabei geht es ja eigentlich nur darum das das warten auf ein Ereignis möglichst wenig Rechenzeit verbraucht.

Hier hatte ich das her: http://opensourceforu.com/2011/04/ge...-with-inotify/
Der benutzt fd für den inotify init. Das hatte ich übersehen das es kein File fd ist.

[edit]
inotify hat aber einen Nachteil gegenüber poll/epoll man muss ja selber in einer Schleife lesen ob eine Nachricht da ist. Dann kann man genauso gut in einer Schleife prüfen ob der Port sich geändert hat. inotify würde ich jetzt mal sagen ist erst dann interessant wenn man mehrere Dateien überwachen muss.
[/edit]

[Ceos]

GPIO sind ja keine echten Interrupt. Deshalb bezeichne ich die auch immer als Trigger das kommt besser hin. Ein echter Interrupt muss von der Hardware auch als solcher unterstützt werden und echte Hardware Interrupt macht der Kernel selber die Steuerung. Kann so ein Ereignis aber auch wieder an den Userspace weiterreichen. Ich weiß nicht ob der Raspi an seinem Stecker einen echten Hardware Interrupt herausführt. Bei den AVR gibt es so was aber auch dort kann das nicht jeder Port.

genau daher mein nachsatz, wiringPi kann genau das auf raspberrys

aber was das inotify angeht, versuchs makl mit folgender webseite (englisch, ich weis) https://www.ibm.com/developerworks/l...ify/index.html

in der erklärung sieht das relativ simple aus, du macht das init, dann ein add_watch auf die datei (also den pfad) und auf die eventqueue (die du vom add_watch bekommst) ein read, das so lange blockt bis die datei sich tatsächlich ändert und das event gesendet wird. Aus der queue siehst du dann welches event, führst dein read auf der datei aus, holst das ergebnis und löst ggf. ein signal oder einen callback aus. Optimal läuft das natürlich nur als multithread aber ich habe auch gelesen dass inotify angeblich selber in der lage sein sollte signals auszulösen, wenn cih finde, reich ich's nach

[HaWe]

wenn ich den OP recht verstanden habe, will er ja kein wiringPi, und wiringPi Sourcecode ist zwar kein Hexenwerk und ist auch bereits auf jedem neueren Raspbian via apt fertig installiert und einsehbar, aber wegen des Raspi device trees ist es dennoch nicht unbedingt zu anderen Linux kompatibel, noch nicht mal unbedingt zu anderen Debians (z.B. nicht zu ev3dev, auch eine Debian distri.).

[alexander_ro]

WriingPi mach aus einem GPIO aber auch keinen echten Hardware Interrupt.
Wenn es nicht zwingend sein muss würde ich die Lösung gerne Hardware unabhängig halten. Da sind halt Kernel und C Funktionen meiner Meinung die besser Wahl.

Ich schau mir das mal an was IBM von inotify schreibt. Die Seite die ich gefunden hatte war ja auch Englisch findet man leider ja öfter nicht anderes. Ich probier das auch mal aus mit inotify dann kann ich auch mal gucken wie schnell das ist. Stimmt schon an die blockierenden read habe ich nicht mehr gedacht.

[HaWe]

WriingPi mach aus einem GPIO aber auch keinen echten Hardware Interrupt.

vermutlich, nach meinem begrenzten Verständnis, hast du damit Recht.
Hier äußert sich der Meister des wiringPis persönlich dazu:
https://www.raspberrypi.org/forums/v...146408#p146408

s.a. hier unter "Interrupts"
https://projects.drogon.net/raspberr...gpi/functions/

[Ceos]

WriingPi mach aus einem GPIO aber auch keinen echten Hardware Interrupt.

neuerem kernel sei dank schon, wie gesagt der einzige grund wrum ich es nochmal erwähnt hatte ... leider aber eben limitiert auf raspbery pi
https://www.raspberrypi.org/forums/v...ic.php?t=74643

viel erfolg beim probieren mit inotify, und denk dran, wenn der kernel älter ist, musst du auf dnotify zurückfallen aber dann wirds unperformant ... zumindest nach dem was ich bei vergleichsdiskussionen so gelesen habe


PS: -----------

du kansnt auch die realtime patches installieren wenns richtig dramatisch werden sollte mit den timings, aber dann hast du natürlich nichts universelles mehr

[alexander_ro]

@Ceos: So alte Kernel gibt es doch für den Raspberry gar nicht mehr. Bei IBM ist für inotify von Kernel 2.6 die rede. Ich habe zwar ein Gentoo auf meinem laufen ich benutze aber den Kernel den auch das Raspian benutzt. Die boot Partition habe ich einfach kopiert.

Das ist ein Irrtum zu glauben das etwas schneller wird mit den Realtime Funktionen des Kernels. Realtime garantiert nur eine Reaktion in einer bestimmten Zeit. Diese Zeit muss aber auch im Rahmen der Möglichkeiten des Systems liegen. Deutlich schneller würde es nur wenn man die Filesystem Zugriffe durch Memory Mapped IO ersetzt. Das will ich aber nicht weil das wieder andere Probleme mit sich bringt. Trotzdem will ich aber auch nicht sinnlos Rechenzeit verschwenden.

Ob das echte Hardware Interrupts sind müsste man im Datenblatt des Prozessors nachlesen. Das ist mir aber im Moment zu viel Aufwand.