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

[klausw]

so siehts aus.

Code Auswählen Erweitern

pi@raspberrypi ~ $ ls -l /sys/class/gpio
total 0
-rwxrwx--- 1 root gpio 4096 Sep  6 19:58 export
lrwxrwxrwx 1 root gpio    0 Sep  6 19:58 gpio21 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpio21
lrwxrwxrwx 1 root gpio    0 Jan  1  1970 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Jan  1  1970 unexport
pi@raspberrypi ~ $

die Rechte passen.
Hast du:

Code Auswählen Erweitern

sudo adduser fhem gpio
sudo reboot
ausgeführt?

Edit:
den gpio21 hast du per FHEM angelegt?

[Ellert]

@ Werniemann: Die Datei /usr/local/bin/gpio existiert nicht. Weder auf dem funktionierenden Sytem, noch auf dem nicht funktionierenden.

@klausw: Ja, das Testsystem ist eine Kopie des Wirksystems mit einer auf den Test reduzierten fhem.cfg. Insofern lief der GPIO vor dem Upgrade mit fhem in gpio..

Code Auswählen Erweitern

pi@raspberrypi /usr/local/bin $ sudo adduser fhem gpio
The user `fhem' is already a member of `gpio'.


Ich habe gerade ins Modul geschaut, /usr/local/bin/gpio ist für WiringPi. WiringPi habe ich nicht installiert, da ich die "pud_resistor" nicht nutze.

[klausw]

@klausw: Ja, das Testsystem ist eine Kopie des Wirksystems mit einer auf den Test reduzierten fhem.cfg. Insofern lief der GPIO vor dem Upgrade mit fhem in gpio..

Code Auswählen Erweitern

pi@raspberrypi /usr/local/bin $ sudo adduser fhem gpio
The user `fhem' is already a member of `gpio'.


Ich habe gerade ins Modul geschaut, /usr/local/bin/gpio ist für WiringPi. WiringPi habe ich nicht installiert, da ich die "pud_resistor" nicht nutze.

Ah, jetzt bist du mir zuvorgekommen, das wollte ich gerade schreiben. Außerdem ist es eher eine Altlast aus der Zeit, wo es dir Gruppe gpio noch nicht gab.

1. Kannst du bitte das Ergebnis von:

Code Auswählen Erweitern

ls -l /sys/class/gpio/gpio24
posten.

2. Was passiert wenn du

Code Auswählen Erweitern

define gpio24 RPI_GPIO 24
erneut ausführst?

[Ellert]

Code Auswählen Erweitern

pi@raspberrypi /usr/local/bin $ ls -l /sys/class/gpio/gpio24
lrwxrwxrwx 1 root gpio 0 Sep  8 07:49 /sys/class/gpio/gpio24 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio24


define gpio24 RPI_GPIO 24 liefert wieder: gpio24: failed to export pin gpio24
Das Device wird nicht angelegt.

und im Log steht mit verbose 5:

Code Auswählen Erweitern

2015.09.08 10:36:54 5: Cmd: >define gpio24 RPI_GPIO 24<
2015.09.08 10:36:54 4: gpio24: write access to file /sys/class/gpio/export, use it to export GPIO
2015.09.08 10:36:59 1: gpio24: can't export gpio24, no write access to /sys/class/gpio/export and file /usr/local/bin/gpio doesnt exist
2015.09.08 10:36:59 1: gpio24: failed to export pin gpio24
2015.09.08 10:36:59 1: define gpio24 RPI_GPIO 24: gpio24: failed to export pin gpio24

Im Frontend ergeben die Abfragen:

Code Auswählen Erweitern


{(-e "/sys/class/gpio/gpio24")} liefert 1

{(-w "/sys/class/gpio/gpio24/value")} liefert "nichts"

{(-w "/sys/class/gpio/gpio24/direction")} liefert "nichts"

{(-w "/sys/class/gpio/export")} liefert 1


Und wenn ich mir die Rechte anzeigen lasse ist gpio nicht dabei:

Code Auswählen Erweitern

pi@raspberrypi /usr/local/bin $ ls -l /sys/class/gpio/gpio24/*
-rw-r--r-- 1 root root 4096 Sep  8 11:21 /sys/class/gpio/gpio24/active_low
lrwxrwxrwx 1 root root    0 Sep  8 11:21 /sys/class/gpio/gpio24/device -> ../../../20200000.gpio
-rw-r--r-- 1 root root 4096 Sep  8 11:05 /sys/class/gpio/gpio24/direction
-rw-r--r-- 1 root root 4096 Sep  8 11:21 /sys/class/gpio/gpio24/edge
lrwxrwxrwx 1 root root    0 Sep  8 07:49 /sys/class/gpio/gpio24/subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Sep  8 07:49 /sys/class/gpio/gpio24/uevent
-rw-r--r-- 1 root root 4096 Sep  8 07:49 /sys/class/gpio/gpio24/value


Im funktionierenden System sieht es so aus:

Code Auswählen Erweitern

pi@raspberrypi ~ $ ls -l /sys/class/gpio/gpio24/*
-rwxrwx--- 1 root gpio 4096 Sep  7 20:36 /sys/class/gpio/gpio24/active_low
lrwxrwxrwx 1 root gpio    0 Sep  7 20:36 /sys/class/gpio/gpio24/device -> ../../../20200000.gpio
-rwxrwx--- 1 root gpio 4096 Sep  7 20:36 /sys/class/gpio/gpio24/direction
-rwxrwx--- 1 root gpio 4096 Sep  7 20:36 /sys/class/gpio/gpio24/edge
lrwxrwxrwx 1 root gpio    0 Sep  7 20:36 /sys/class/gpio/gpio24/subsystem -> ../../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Sep  7 20:36 /sys/class/gpio/gpio24/uevent
-rwxrwx--- 1 root gpio 4096 Sep  7 20:36 /sys/class/gpio/gpio24/value


[klausw]

Code Auswählen Erweitern

pi@raspberrypi /usr/local/bin $ ls -l /sys/class/gpio/gpio24
lrwxrwxrwx 1 root gpio 0 Sep  8 07:49 /sys/class/gpio/gpio24 -> ../../devices/platform/soc/20200000.gpio/gpio/gpio24


define gpio24 RPI_GPIO 24 liefert wieder: gpio24: failed to export pin gpio24
Das Device wird nicht angelegt.

Oha, das ist bisschen wenig.

Das sollte etwas mehr bringen:
ls -l /sys/class/gpio/gpio24/

und im Log steht mit verbose 5:

Code Auswählen Erweitern

2015.09.08 10:36:54 5: Cmd: >define gpio24 RPI_GPIO 24<
2015.09.08 10:36:54 4: gpio24: write access to file /sys/class/gpio/export, use it to export GPIO
2015.09.08 10:36:59 1: gpio24: can't export gpio24, no write access to /sys/class/gpio/export and file /usr/local/bin/gpio doesnt exist
2015.09.08 10:36:59 1: gpio24: failed to export pin gpio24
2015.09.08 10:36:59 1: define gpio24 RPI_GPIO 24: gpio24: failed to export pin gpio24

Die zweite Zeile ist falsch, da muss ich die Fehlermeldungen mal anpassen. Schreibzugriff ist schließlich vorhanden :/

[Ellert]

Irgend wie hängt die Rechtevergabe mit dem DeviceTree zusammen, denn wenn ich in der config.txt den DeviceTree abschalte, kann ich mit define gpio24 RPI_GPIO 24 den Port definieren. Siehe https://www.raspberrypi.org/documentation/configuration/device-tree.md#part4.3

Das wird aber keine Lösung auf Dauer sein.

Ich hatte letzten meinen Beitrag schon ergänzt, das ist ein bisschen unübersichtlich, tut mir Leid. Hier nochmal die Rechte:

Code Auswählen Erweitern

pi@raspberrypi ~ $ ls -l /sys/class/gpio/gpio24/
total 0
-rw-r--r-- 1 root root 4096 Sep  8 12:34 active_low
lrwxrwxrwx 1 root root    0 Sep  8 12:34 device -> ../../../20200000.gpio
-rw-r--r-- 1 root root 4096 Sep  8 12:34 direction
-rw-r--r-- 1 root root 4096 Sep  8 12:34 edge
lrwxrwxrwx 1 root root    0 Sep  8 12:34 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Sep  8 12:34 uevent
-rw-r--r-- 1 root root 4096 Sep  8 12:34 value
p

[klausw]

Irgend wie hängt die Rechtevergabe mit dem DeviceTree zusammen, denn wenn ich in der config.txt den DeviceTree abschalte, kann ich mit define gpio24 RPI_GPIO 24 den Port definieren. Siehe https://www.raspberrypi.org/documentation/configuration/device-tree.md#part4.3

Das wird aber keine Lösung auf Dauer sein.

Ich hatte letzten meinen Beitrag schon ergänzt, das ist ein bisschen unübersichtlich, tut mir Leid. Hier nochmal die Rechte:

Alles gut, ich fands durchaus Übersichtlich
Wo es nicht geht ist die Gruppe root anstelle von gpio. Mich wundert es nur, das es bei manchen funktioniert und bei anderen nicht.
Seltsamerweise läuft bei mir alles normal mit aktuellem Image und Kernel. Ich habe I2C in der config.txt aktiviert:

Code Auswählen Erweitern

dtparam=i2c_arm=on aber daran sollte es eigentlich nicht liegen.


Immerhin ist es erstmal eine Lösung.
Du hast

Code Auswählen Erweitern

device_tree= in die config.txt eingefügt?

Ich habe es vermulich überlesen...welches Pi hast du?

[Ellert]

Als Wirksystem habe ich einen Pi B+, der meldet sich mit: Linux raspberrypi 3.18.11+ #781 PREEMPT Tue Apr 21 18:02:18 BST 2015 armv6l. Damit funktionieren die GPIOs, wie in der Comandref zu RPI_GPIO beschrieben einwandfrei.

Mein Testsystem läuf auch auf einem Pi B+ und basiert auf dem Wirksystem. Darauf habe ich ein Upgrade durchgeführt, mit:

Code Auswählen Erweitern

sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get autoremove -y
sudo reboot

Dann meldet sich das System mit: Linux raspberrypi 4.1.6+ #810 PREEMPT Tue Aug 18 15:19:58 BST 2015 armv6l.
Hier gibt es die Rechteprobleme mit den GPIOs. Die Probleme verschwinden, wenn ich versuchsweise "device_tree=" am Ende der config.txt eintrage und neu starte. Das wird wahrscheinlich Geräte beeinflussen, die jetzt über DeviceTree angesprochen werden. Ich habe das nicht getestet, da an dem Testsystem nichts weiter angeschlossen ist. Ich denke jedoch, der Versuch deutet darauf hin, dass das Rechteproblem mit dem DeviceTree zusammen hängt. Ich denke am Modul liegt es nicht, denn wenn ich einen GPIO manuell exportiere, besteht das gleiche Problem:

Code Auswählen Erweitern

pi@raspberrypi ~ $ echo "24" > /sys/class/gpio/export
pi@raspberrypi ~ $ ls -l /sys/class/gpio/gpio24/
total 0
-rw-r--r-- 1 root root 4096 Sep  8 16:13 active_low
lrwxrwxrwx 1 root root    0 Sep  8 16:13 device -> ../../../20200000.gpio
-rw-r--r-- 1 root root 4096 Sep  8 16:13 direction
-rw-r--r-- 1 root root 4096 Sep  8 16:13 edge
lrwxrwxrwx 1 root root    0 Sep  8 16:13 subsystem -> ../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Sep  8 16:13 uevent
-rw-r--r-- 1 root root 4096 Sep  8 16:13 value


Es besteht für mich keine Notwendigkeit zum Upgrade, daher bleibt mein Wirksystem unverändert.

[cremofix]

Hatte auch massiv das Problem mit den GPio Berechtigungen. fhem hat die immer mit root:root angelegt und ich musste die Rechte manuell ändern, was nur bis zum nächsten Reboot funktionierte.

Hilfe hat nur ein komplett neu aufgesetzter raspi mit raspbian jessie gebracht.

- Sytem neu aufgespielt
- fhem installiert
- wiringPi installiert

jetzt gehts und die GPIOS werden sauber mit root:gpio angelegt
Gruß
Mario

[klausw]

Hilfe hat nur ein komplett neu aufgesetzter raspi mit raspbian jessie gebracht.

Kann ich bestätigen. Nach dem Upgrade von Wheezy ist die Rechtevergabe für die GPIOs im A...
Nach Neuinstallation funktioniert es wieder mit der gruppe GPIO wie in der commandref beschrieben.

[cocktailyogi]

Kann ich bestätigen. Nach dem Upgrade von Wheezy ist die Rechtevergabe für die GPIOs im A...
Nach Neuinstallation funktioniert es wieder mit der gruppe GPIO wie in der commandref beschrieben.

Bei mir ist es immernoch so.... Vor einigen Wochen kam es mir so vor, als sei ich der Einzige mit dem Problem, aber so langsam zeichnet sich das Schema ab. Nur dass ich keine Neuinstalltion machen kann, da mein RPI2 noch viel mehr Aufgaben erledigt. Wie kann ich helfen, die Ursache einzugrenzen? Könnten wir irgendwie eine Neuinstalltion mit mit meiner "Upgradeversion" vergleichen?

Gruß,
Yogi

[frober]

Hallo,

leider habe ich auch ein Problem:

Ich habe 5 Pins in Fhem definiert, 3 funktionieren, bei 2 bekomme ich einen Logeintrag "/usr/local/bin/gpio: Unable to open GPIO direction interface for pin 27: No such file or directory" das gleiche für Pin 17.

Unter /sys/class/gpio sind die zwei auch nicht angelegt.
Mit "echo 17 > ...../export" kommt die Meldung "Gerät oder Ressource ist beleg.
Dann wollte ich mit  "echo 17 > ...../unexport" den Pin freigeben geben,  kommt die Meldung "Schreibfehler, Argument ist ungültig"

Nachtrag:
Die Meldungen kommen so unter pi, sudo und su root.

Fhem und pi ist in der Gruppe gpio eingetragen.

Hat jemand eine Idee?

[klausw]

Ich habe 5 Pins in Fhem definiert, 3 funktionieren, bei 2 bekomme ich einen Logeintrag "/usr/local/bin/gpio: Unable to open GPIO direction interface for pin 27: No such file or directory" das gleiche für Pin 17.

Unter /sys/class/gpio sind die zwei auch nicht angelegt.
Mit "echo 17 > ...../export" kommt die Meldung "Gerät oder Ressource ist beleg.
Dann wollte ich mit  "echo 17 > ...../unexport" den Pin freigeben geben,  kommt die Meldung "Schreibfehler, Argument ist ungültig"

Nachtrag:
Die Meldungen kommen so unter pi, sudo und su root.

Fhem und pi ist in der Gruppe gpio eingetragen.

wenn ein GPIO geht dann gehen grundsätzlich alle

Gerät oder Ressource ist beleg sagt eigentlich alles

17 und 27 haben auch alternative Funktionen vermutlich hat du die SPI in der config.txt (z.B. über raspi-config) oder anderswo aktiviert

[frober]

17 und 27 haben auch alternative Funktionen vermutlich hat du die SPI in der config.txt (z.B. über raspi-config) oder anderswo aktiviert

Erstmal danke für den Tip.
Hatte noch keine Zeit zum testen, aber wo sind die alternativen Funktionen von GPIO 17 + 27 dokumentiert?
Ich bin nach der Tabelle aus der Commandref gegangen und habe nur Pin's gewählt die keine andere Funktion haben.

Kann ich irgend wo sehen, was meine Pin's belegt?   

[klausw]

Erstmal danke für den Tip.
Hatte noch keine Zeit zum testen, aber wo sind die alternativen Funktionen von GPIO 17 + 27 dokumentiert?
Ich bin nach der Tabelle aus der Commandref gegangen und habe nur Pin's gewählt die keine andere Funktion haben.

Kann ich irgend wo sehen, was meine Pin's belegt?

mit dem gpio utility von wiringPi kannst du das anschauen
Bei einem halben Dutzend verschiedener Raspberrys ist die Tabelle in der Commandref nicht vollständig.
Google hilft da Zugegebenermaßen ist es nicht einfach eine vollständige Pinbelegung zu finden. Diese ist ganz gut.
Aber wenn das GPIO Verzeichnis nicht existiert und bei Exportversucht die Meldung kommt das die Ressource belegt ist kann es eigentlich nix anderes sein.

Aber von allein aktivieren sich die alternativen Funktionen nicht (ausgenommen die serielle Schnittstelle GPIO14,15).
Wo hast du dein SD-Image her?
Hast du über raspi-config z.B. die SPI aktiviert? (das könntest du auch in der /boot/config.txt als Paramter "dtparam=spi=on" finden)