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

[klausw]

wenn ich das wüsste...
ich hätte als erstes wiringpi in Verdacht. Da ja bei Dir und mir die Gpio Dateien mit unterschiedlichen Rechten angelegt werden.

Code Auswählen Erweitern

gpio -v

sagt bei mir:

Code Auswählen Erweitern

gpio version: 2.13

und bei Dir?

Aber vielleicht liegt es auch an den Kerneltreibern.

Code Auswählen Erweitern

cat /proc/version

bringt bei mir:

Code Auswählen Erweitern

Linux version 3.10.25+ (dc4@dc4-arm-01) (gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08) ) #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014

[backbone10]

Hi,
genau das gleiche 

soll ich mal was neu installieren ? wen ja, was und mit welchem user ?

mfg

bb10

[klausw]

puh, gute frage
hast Du eine 2. SD Karte?
Dann würde ich es komplett neu aufsetzten mit der aktuellen raspbian Version.
Ich habe letzte Wochen mein 2. Raspi neu aufgesetzt. Da hat es auch auf Anhieb funktioniert.

PS: ich habe alle installationen mit dem user pi gemacht

[backbone10]

Hi,
kann ich hiermit bestaetigen. Funktioniert

Danke

bb10

[Apollo]

Ich komme mit dem Interrupt nicht weiter, was muß ich da noch konfigurieren?
Ich habe jetzt folgendes:

define Pin12 RPI_GPIO 18
attr Pin12 direction input
attr Pin12 interrupt falling

Egal was ich weiteres einstelle, der Zustand des PIN12 ändert sich in FHEM nicht.
Außerdem habe ich beobachtet, dass die CPU auf 100% geht, sobald ich den Interrupt einschalte.
Dabei gehen knapp 50% an perl und ebenfalls knapp 50% an startpar.

Letztendlich möchte ich mit dem Interrupt das lesen des MCP23017 per i2c auslösen.

Danke

[klausw]

Ich komme mit dem Interrupt nicht weiter, was muß ich da noch konfigurieren?
Ich habe jetzt folgendes:

define Pin12 RPI_GPIO 18
attr Pin12 direction input
attr Pin12 interrupt falling

Egal was ich weiteres einstelle, der Zustand des PIN12 ändert sich in FHEM nicht.
Außerdem habe ich beobachtet, dass die CPU auf 100% geht, sobald ich den Interrupt einschalte.
Dabei gehen knapp 50% an perl und ebenfalls knapp 50% an startpar.

Letztendlich möchte ich mit dem Interrupt das lesen des MCP23017 per i2c auslösen.

Danke

interrupt falling bedeutet, das bei fallender Flanke die werte aktualisiert werden
Da kannst natürlich du keine Veränderung von state sehen (da immer nur der low Pegel aktualisiert wird). Allerdings sollte sich die Zeit bei jedem Interrupt ändern. Pinlevel wird in diesem Fall nur bei einem reload aktualisiert.
Aber um ein notify zum auslesen des MCP... zu erzeugen reicht das.
Mit interrupt both ändert sich state bei jedem Pegelwechsel.
Mit interrupt both ändert sich
Wie lang bleibt die CPU denn auf 100%? Das habe ich mir noch nciht angeschaut

[Apollo]

danke für deine schnelle Antwort.

Leider geht das auch mit both auch nicht. Der Pinlevel wird nur beim Reload der Detailseite aktualisiert, aber das macht es ja auch ohne den Interrupt-Eintrag.

Die 100% CPU bleiben so lange, bis ich den Interrupt-Eintrag wieder kösche, dann ist sofort 98% Idle.

Revision 1 oder 2 des RPI dürfe ja keinen unterschied machen, oder? (Ich hab die 1)

[klausw]

Leider geht das auch mit both auch nicht. Der Pinlevel wird nur beim Reload der Detailseite aktualisiert, aber das macht es ja auch ohne den Interrupt-Eintrag.

Genau, das beteutet aber schonmal das es grundsätzlich funktioniert

Die 100% CPU bleiben so lange, bis ich den Interrupt-Eintrag wieder kösche, dann ist sofort 98% Idle.

Was bedeutet löschen? Den Pin zurücksetzen? Oder ein Undefine?
Geht FHEM noch wenn du bei 100% bist?

Revision 1 oder 2 des RPI dürfe ja keinen unterschied machen, oder? (Ich hab die 1)

Das sollte egal sein ... bis auf die Tatsachem das einige GPIOs auf anderen Pins sitzen.

Wie alt ist Deine Raspbian Installation?

[Apollo]

Ja eben, es geht ja grundsätzlich. Ich kann den Zustand des Pins auslesen oder ihn als Ausgang benutzen, nur das mit dem Interrupt will nicht.

Mit löschen meinte ich das Attribut "interrupt", entweder direkt auf der Detailseite mit "deleteattr", oder direkt in der fhem.cfg und save (das braucht nicht mal ein rereadcfg).
Erstaunlicherweise geht FHEM trotz der 100% CPU noch recht gut.

Raspbian ist das letzte (2014-01-07)

edit: das Log sagt auch nichts weiter
2014.03.27 20:52:56 5: Cmd: >define Pin12 RPI_GPIO 18<
2014.03.27 20:52:56 5: Loading ./FHEM/51_RPI_GPIO.pm
2014.03.27 20:52:56 5: Pin12: direction: input
2014.03.27 20:52:57 5: Cmd: >attr Pin12 direction input<
2014.03.27 20:52:57 5: Pin12: direction: input
2014.03.27 20:52:57 5: Cmd: >attr Pin12 interrupt both<
2014.03.27 20:52:57 5: Datei: /sys/class/gpio/gpio18/value, FH: IO::File=GLOB(0x1ebfc08), EXCEPT_FD: 8, akt. Wert: 1
2014.03.27 20:52:57 5: Pin12: interrupt: both

[klausw]

Ja, das Log sieht normal aus.
Die Perl Version ist auch aktuell?

[Apollo]

Ich habe noch mal update/upgrade von Raspbian gemacht, somit sollte perl aktuell sein.
Komischer weise ist jetzt die hohe CPU-Last weg. Geändert hat sich beim Interrupt aber nichts.

welches Modul ist eigentlich das aktuellere?
das im trunk
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/
oder das im Board
http://forum.fhem.de/index.php/topic,16519.msg115933.html#msg115933

Ich werde mal die Tage Raspbian noch mal komplett neu aufzusetzen, eventuell ist ja doch irgendwo etwas quer.

[klausw]

per update im FHEM solltest Du die aktuelle Version bekommen
das ist dann das im trunk

[Apollo]

Ich habe gerade in einem anderen Beitrag gelesen, dass die pins mit 3,3V arbeiten. ich hab für mein Steckboard die 5V vom RPI abgegriffen, kann das mein Interrupt-Problem sein?

Beim I2C-Bus müsste das ja egal sein, da die ICs ja mit low-Pegel arbeiten und die Pullups auf dem RPI sind.

[klausw]

Ich habe gerade in einem anderen Beitrag gelesen, dass die pins mit 3,3V arbeiten. ich hab für mein Steckboard die 5V vom RPI abgegriffen, kann das mein Interrupt-Problem sein?

Beim I2C-Bus müsste das ja egal sein, da die ICs ja mit low-Pegel arbeiten und die Pullups auf dem RPI sind.

Das steht auch in der connmandref drin.
Mit 5V kannst du Dir die Pins zerschießen, vielleicht ist das auch schon passiert.
Wie der Controller dann reagiert ist schwer zu sagen.
Hast Du noch einen Pin, der keine 5V gesehen hat? Dann solltest Du es an diesem noch einmal probieren.

Manche I2C Module haben aber auch Pullups drauf. Da würde ich aufpassen.

[Apollo]

Ja, erst lesen wäre besser. Meistens mach ich das leider anders herum.
Ich hatte einen 4,7k Widerstand gegen 5V, das hat der Pin denke ich überlebt.
Ich hab jetzt auch noch Pin7 (GPIO4) dran, aber ist das selbe.
Wenn ich das pollen lasse (Attr:poll_interval) dann geht es ( in Minutenabständen ), nur nicht per Interrupt.

Momentan hab ich ja nur ein Steckboard dran und da hab ich die Pullups komplett weg gelassen.
Wenn es dann so funktioniert, wie es soll, dann baue ich mir die Module auch selber.

Das die hohe CPU-Last weg ist, stimmt übrigens nicht. Hatte gestern wahrscheinlich auf die falsche SSH Konsole geschaut, war schon spät.

Wenn ich Zeit habe, werde ich noch mal mit einem frischen Raspbian anfangen.