Modul für RPi GPIO Zugriff mit Interrupt Funktion für Input

[klausw]

Die Pins hattest du schon in der rc.local exportiert?
Wie sieht das ganze aus, wenn du die Zeilen aus der rc.local entfernst?
Wenn wiring pi installiert ist sollte das trotzdem gehen.

Im Log steht nix, da du kein Attribut interrupt für den Input vergeben hast 

Bei Deinem GPIO21 fehlt die Datei edge. Über diese läuft die Interruptauswertung.
Vermutlich unterstützt dieser GPIO einfach keinen Interrupt.
Nutze GPIO27 bitte Testweise als Input mit Interrupt.

[Ralli]

Ja, bereits in der rc.local exportiert. Wenn ich das nicht tue, klappt so gut wie gar nichts. Das einzige, was dann funktioniert, ist das Beschalten eines Outputs - allerdings kommt er bspw. an active_low schon nicht mehr dran, so dass das auch nicht wirklich richtig klappt.

Mit dem Interrupt hole ich nochmal nach bzw. probiere das aus.

[klausw]

Ja, bereits in der rc.local exportiert. Wenn ich das nicht tue, klappt so gut wie gar nichts. Das einzige, was dann funktioniert, ist das Beschalten eines Outputs - allerdings kommt er bspw. an active_low schon nicht mehr dran, so dass das auch nicht wirklich richtig klappt.

stimmt, wiring pi ermöglicht nur zugriff auf value und edge
aber ein input sollte auch gehen, wenigstens im polling

[Ralli]

Input klappt ja im Polling auch - aber eben nicht per Interrupt.

Wenn ich manuell mit GPIO versuche, einen Pin auf Interrupt zu bringen, klappt es auch nicht. Ich bekomme die Fehlermeldung

Code Auswählen Erweitern


Unable to open GPIO edge interface for pin 21: No such file or directory


Laut einem Post auf Drogons/Gordons Seite https://projects.drogon.net/raspberry-pi/wiringpi/functions/ könnte das auf eine fehlende Unterstützung im Kernel hinweisen. Und damit ist dann leider Schluss für mich .

Frage:

Bedeutet denn das ständige Polling hier im konkreten Fall einen wesentlichen Ressourcen-Mehraufwand gegenüber der Interrupt-Lösung oder ist das zu vernachlässigen - ich kenne die Art und Weise der Abhandlung innerhalb von Perl bzw. fhem nicht? (generell ist Polling ja eher deutlich schlechter als Interrupt...)

[klausw]

Frage:

Bedeutet denn das ständige Polling hier im konkreten Fall einen wesentlichen Ressourcen-Mehraufwand gegenüber der Interrupt-Lösung oder ist das zu vernachlässigen - ich kenne die Art und Weise der Abhandlung innerhalb von Perl bzw. fhem nicht? (generell ist Polling ja eher deutlich schlechter als Interrupt...)

Es kommt immer auf die Anwendung an.
Wenn du minütlich pollst ist das sicher zu vernachlässigen (Zustand Fenster z.B). Aber zum Abfragen von Tasten ist es ungeeignet, du kannst versuchen alle 100ms abzufragen, aber das erzeugt Prozessorlast und ist an sich auch noch zu langsam. Die Interrupt Lösung erzeugt, nachdem sie aktiviert wurde, überhaupt keine Last, solange kein Interrupt ausgelöst wird.
Probiere es aus, vielleicht reicht es für deine Anwendung
Aber ... schön isses natürlich nciht.

Wenn es im Kernel nicht drin ist, kann ich leider auch nicht viel machen.
Was ist denn mit den Pins, wo die edge Datei im Verzeichnis liegt? Das war doch bei dem einen Output Pin bei die der Fall.
Kannst du auf die Datei zugreifen, wenn sie da ist?

Das Polling kannst du auch über wiringpi machen, das brauchst du nix in die rc.local zu schreiben...richtig?

[Ralli]

Hallo Klaus,

habe noch was gefunden: http://forum.lemaker.org/thread-11177-1-1-.html

Es ist wohl nicht jeder GPIO auch mit Interrupt nutzbar.

Und siehe da - wenn man einen GPIO für Input nimmt, der auch Interrupt beherrscht, klappt's auch . Aber auch hier gilt: er muss genau wie die anderen in der rc.local geimpft werden.

Meine rc.local habe ich um Folgendes ergänzt:

Code Auswählen Erweitern


# in /etc/init.d/rc.local den Pfad ergänzen um :/usr/local/sbin:/usr/local/bin

gpio reset

# Input-Ports (BCM)
for Port in 4 21
  do
  echo "$Port" > /sys/class/gpio/export
  echo "in" >/sys/class/gpio/gpio${Port}/direction
done

# Output-Ports (BCM)
for Port in 27
  do
  echo "$Port" > /sys/class/gpio/export
  echo "out" >/sys/class/gpio/gpio${Port}/direction
  echo "1" > /sys/class/gpio/gpio${Port}/active_low
  echo "0" >/sys/class/gpio/gpio${Port}/value
done

chmod 775 -R /sys/class/gpio
chown -R root:gpio /sys/class/gpio
chmod 775 -R /sys/devices/platform/gpio-sunxi
chown -R root:gpio /sys/devices/platform/gpio-sunxi


[hobbynaut]

Hi,
ich verwende ein paar Raspi-Pins für Alarmsignale wie z.B. von einem Rauchmelder. Da die Signale zum Teil kürzer als eine Minute sind verwende ich den Interrupt-Modus:

Code Auswählen Erweitern


define Rauchmelder RPI_GPIO 11
attr Rauchmelder active_low yes
attr Rauchmelder direction input
attr Rauchmelder interrupt falling

Den Pin habe ich mit einem Notify verknüpft, der im Alarmfall eine SMS sendet. Bei einem Test wurde jedoch alle paar Sekunden eine neue SMS gesendet.
Sollte der Notify denn nicht nur bei dem Flankenwechsel ausgelöst werden?

Die Alarmeingänge habe ich auch mit einem Log verknüpft und dort sieht man, dass die Pins sehr oft täglich toggeln und den Counter hochzählen, obwohl der Pinlevel immer Low ist:

Code Auswählen Erweitern


2015-01-29_15:44:57 Rauchmelder Pinlevel: low
2015-01-29_15:44:57 Rauchmelder off
2015-01-29_15:44:57 Rauchmelder Toggle: on
2015-01-29_15:44:57 Rauchmelder Counter: 26386
2015-01-29_17:50:39 Rauchmelder Pinlevel: low
2015-01-29_17:50:39 Rauchmelder off
2015-01-29_17:50:39 Rauchmelder Toggle: off
2015-01-29_17:50:39 Rauchmelder Counter: 26387

Ist das bei euren Interrupt-Pins auch so oder mach ich hier etwas falsch?

[klausw]

Hi,
ich verwende ein paar Raspi-Pins für Alarmsignale wie z.B. von einem Rauchmelder. Da die Signale zum Teil kürzer als eine Minute sind verwende ich den Interrupt-Modus:

Code Auswählen Erweitern


define Rauchmelder RPI_GPIO 11
attr Rauchmelder active_low yes
attr Rauchmelder direction input
attr Rauchmelder interrupt falling

Den Pin habe ich mit einem Notify verknüpft, der im Alarmfall eine SMS sendet. Bei einem Test wurde jedoch alle paar Sekunden eine neue SMS gesendet.
Sollte der Notify denn nicht nur bei dem Flankenwechsel ausgelöst werden?

Die Alarmeingänge habe ich auch mit einem Log verknüpft und dort sieht man, dass die Pins sehr oft täglich toggeln und den Counter hochzählen, obwohl der Pinlevel immer Low ist:

Code Auswählen Erweitern


2015-01-29_15:44:57 Rauchmelder Pinlevel: low
2015-01-29_15:44:57 Rauchmelder off
2015-01-29_15:44:57 Rauchmelder Toggle: on
2015-01-29_15:44:57 Rauchmelder Counter: 26386
2015-01-29_17:50:39 Rauchmelder Pinlevel: low
2015-01-29_17:50:39 Rauchmelder off
2015-01-29_17:50:39 Rauchmelder Toggle: off
2015-01-29_17:50:39 Rauchmelder Counter: 26387

Ist das bei euren Interrupt-Pins auch so oder mach ich hier etwas falsch?

Der Pinlevel ist nicht immer Low. Das attribut Interrupt auf falling sorgt allerdings dafür, das nur bei einem high->low Wechsel am GPIO der Status aktualisiert wird. Das heisst, es wird immer nur low reingeschrieben. Trotzdem muss der Pin vorher high gewesen sein. Das wird aber nur registriert, wenn du interrupt auf both stellst. Zum zählen ist es irrelevant.
Ich vermute, das du am GPIO kein stabiles Eingangssignal hast.

[hobbynaut]

Bei einem Alarmeingang verwende ich Interrupt = both. Dann müsste ich in dem zugehörigen Log ja auch mal pinlevel = high sehen. In dem Log steht aber immer nur pinlevel = low.

[Ralli]

Hallo Klaus,

nachdem ich heute einen B+ mit rpi-update und software-seitig auf aktuellen Stand gebracht habe, ist mir aufgefallen, dass der in der commandref aufgeführte Pfad bei chown -R fhem:root /sys/devices/virtual/gpio/* zumindest unter Raspbian nicht (mehr) existiert.

Der Pfad lautet /sys/devices/soc/20200000.gpio/gpio/*

[klausw]

Hallo Klaus,

nachdem ich heute einen B+ mit rpi-update und software-seitig auf aktuellen Stand gebracht habe, ist mir aufgefallen, dass der in der commandref aufgeführte Pfad bei chown -R fhem:root /sys/devices/virtual/gpio/* zumindest unter Raspbian nicht (mehr) existiert.

Der Pfad lautet /sys/devices/soc/20200000.gpio/gpio/*

Ich frage mich sowieso gerade, was ich da geschrieben habe....

Gibt es denn: /sys/class/gpio/export?
und damit auch die /sys/class/gpio/gpio[zahl]?

nach eingabe von:

sudo adduser fhem gpio
sudo reboot

und reboot sollte beim raspbian sowieso alles direkt ohne weitere Änderungen laufen.

[Ralli]

Ich frage mich sowieso gerade, was ich da geschrieben habe....

Gibt es denn: /sys/class/gpio/export?
und damit auch die /sys/class/gpio/gpio[zahl]?

Ja - beides. Ersteres als ausführbare Datei, letztes jeweils als Verzeichnis.

Und nein, nach dem

sudo adduser fhem gpio
sudo reboot

war nach der Update-Prozedur nicht alles gut.

[klausw]

Ja - beides. Ersteres als ausführbare Datei, letztes jeweils als Verzeichnis.

dann sollte doch auch

Code Auswählen Erweitern

chown -R fhem:root /sys/class/gpio/*
funktionieren. Oder?

Und nein, nach dem

war nach der Update-Prozedur nicht alles gut.

was ist denn nicht gut?
geht es nur eingeschränkt oder gar nicht?

wie sind den die Rechte ohne die Anpassung in der rc.local?

[Ralli]

dann sollte doch auch

Code Auswählen Erweitern

chown -R fhem:root /sys/class/gpio/*
funktionieren. Oder?

Nein, das alleine funktioniert nicht. Da werden die Berechtigungen nicht richtig durchgereicht (virtuelle Dateien).

was ist denn nicht gut?
geht es nur eingeschränkt oder gar nicht?

wie sind den die Rechte ohne die Anpassung in der rc.local?

Das gleiche Problem wie bei der Banane. Ohne Bearbeitung in der rc.local nur rudimentäre Funktionen. Genaueres kann ich Dir leider jetzt nicht mehr schreiben, da ich gestern auf die Banane migriert habe und der PI nun platt ist.

[klausw]

Nein, das alleine funktioniert nicht. Da werden die Berechtigungen nicht richtig durchgereicht (virtuelle Dateien).

Wieder was gelernt
Dann sollte ich die Pfade der verschiedenen Distros sammeln und in die commandref einbauen.

Das gleiche Problem wie bei der Banane. Ohne Bearbeitung in der rc.local nur rudimentäre Funktionen. Genaueres kann ich Dir leider jetzt nicht mehr schreiben, da ich gestern auf die Banane migriert habe und der PI nun platt ist.

Mach  nix, wenn jemand Probleme hat wird er sich sicher melden.