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

[TeeVau]

Hallo, kann mir jemand auf die Sprünge helfen, welche Debian Pakete ich alles benötigt, um WiringPi zu compilen?
Make und gcc habe ich installiert, funktioniert aber leider nicht.

Code Auswählen Erweitern

root@pibz:/tmp/wiringPi-72b2af2# ./build
wiringPi Build script
=====================


WiringPi Library
[UnInstall]
[Compile] wiringSerial.c
[Compile] piHiPri.c
[Compile] wiringShift.c
[Compile] wiringPi.c
[Compile] piThread.c
piThread.c:26:21: fatal error: pthread.h: No such file or directory
wiringPi.c:55:19: fatal error: stdio.h: No such file or directory
compilation terminated.
compilation terminated.
wiringSerial.c:23:19: fatal error: stdio.h: No such file or directory
compilation terminated.
piHiPri.c:27:19: fatal error: sched.h: No such file or directory
compilation terminated.
In file included from wiringShift.c:25:0:
/usr/lib/gcc/arm-linux-gnueabihf/4.6/include/stdint.h:3:26: fatal error: stdint.h: No such file or directory
compilation terminated.
Makefile:89: recipe for target 'wiringSerial.o' failed
make: *** [wiringSerial.o] Error 1
make: *** Waiting for unfinished jobs....
Makefile:89: recipe for target 'wiringPi.o' failed
make: *** [wiringPi.o] Error 1
Makefile:89: recipe for target 'piThread.o' failed
make: *** [piThread.o] Error 1
Makefile:89: recipe for target 'piHiPri.o' failed
make: *** [piHiPri.o] Error 1
Makefile:89: recipe for target 'wiringShift.o' failed
make: *** [wiringShift.o] Error 1

Make Failed...


[klausw]

Hallo, kann mir jemand auf die Sprünge helfen, welche Debian Pakete ich alles benötigt, um WiringPi zu compilen?

keine Ahnung, läuft das unterschiedlich zum Raspbian? dort geht es so:

Code Auswählen Erweitern

sudo apt-get install git-core
git clone git://git.drogon.net/wiringPi
cd wiringPi ./build

[TeeVau]

Ja, es ist ein respian. Benutze das Image Musikbox Pi. Git kopiert ja nur den sourceforge, das Build compiliert das ganze ja. Das macht bei mir Probleme. Sonst schreib ich den Entwickler die Tage mal an

[Nemo0815]

Hab darauf hier noch keine Anwort gefunden:

Läuft der Counter irgnedwann über? Fängt er wieder bei 0 an? (z.B. bei 65535?)

[klausw]

Gute Frage, vermutlich ja. Aber da sollte jede Menge Luft sein. Evtl. findest du in der Perldoku was.

[Nemo0815]

Gute Frage, vermutlich ja. Aber da sollte jede Menge Luft sein. Evtl. findest du in der Perldoku was.

Bei mir ist nicht viel Luft, es hängt ein Windmesser am GPIO und mit dem Counter wird die Windgeschwindigkeit berechnet

[klausw]

Na dann lass es mal laufen und berichte
Das ist aber eher interesse.
Ich würde in die Routine zur Geschwindigkeitsberechnung einfach das zurücksetzen des Zählers einbauen.

[Nemo0815]

Na dann lass es mal laufen und berichte
Das ist aber eher interesse.
Ich würde in die Routine zur Geschwindigkeitsberechnung einfach das zurücksetzen des Zählers einbauen.

Kann man den Counter zurücksetzen?

[klausw]

Kann man den Counter zurücksetzen?

Mit setreading, Syntax habe ich nicht im Kopf, steht aber in der commandref

Ich vermute aber, das du auch ohne zurücksetzen keinen Überlauf hinbekommst.

[Nemo0815]

Wie genau ist dieser Counter eigneltich? Bzw. bis zu welcher Frequenz lassen sich die GPIOs "abtasten"?

Irgendwie bekomme ich mit meinem Windmesser nur max. 20 km/h hin, was mir doch etwas wenig erscheint

[klausw]

Wie genau ist dieser Counter eigneltich? Bzw. bis zu welcher Frequenz lassen sich die GPIOs "abtasten"?

Irgendwie bekomme ich mit meinem Windmesser nur max. 20 km/h hin, was mir doch etwas wenig erscheint

Naja, das Counter ist wie das ganze Modul in Perl programmiert und greift auf den GPIO über das Dateisystem zu.
Bei jedem Interrupt werden Dateioperationen ausgeführt, die eine Weile dauern.
Triggerst du auf beide Flanken? Dann könnte es mit einer besser gehen.
Der Counter ist genau, solange die CPU genug Reserven hat. Werden beispielsweise gerade Plots berechnet dann kann es Probleme geben.
Das mit dem Counter hatte ich damals auf Wunsch eingebaut und mir nicht weiter Gedanken drüber gemacht.
Für eine Lösung die schneller zählen kann müsstest du was in C schreiben. Oder besser noch einen Mikrocontroller nehmen der die Geschw. direkt berechnet.

[Nemo0815]

Naja, das Counter ist wie das ganze Modul in Perl programmiert und greift auf den GPIO über das Dateisystem zu.
Bei jedem Interrupt werden Dateioperationen ausgeführt, die eine Weile dauern.
Triggerst du auf beide Flanken? Dann könnte es mit einer besser gehen.
Der Counter ist genau, solange die CPU genug Reserven hat. Werden beispielsweise gerade Plots berechnet dann kann es Probleme geben.
Das mit dem Counter hatte ich damals auf Wunsch eingebaut und mir nicht weiter Gedanken drüber gemacht.
Für eine Lösung die schneller zählen kann müsstest du was in C schreiben. Oder besser noch einen Mikrocontroller nehmen der die Geschw. direkt berechnet.

Danke für die Info.

Ich habe mittlerweile versucht mir mittels eines Python scripts über RPI.GPIO Lib zu behelfen.
(und mich da in die ISR callback zu hängen). Leider funktioniert das nur wenn FHEM nicht läuft, auch wenn ich den entsprechenden Pin nicht benutze.

Wenn FHEM läuft wird kein interrupt ausgelöst, es sei denn ich definiere den Pin zusätzlich in fhem als RPI_GPIO. Gibts da irgendeinen Rechte/Resourcen Konflikt mit der Art wir RPI_GPIO die Ports benutzt?

Hier ist der Code, wens interessiert (noch nicht perfekt):

Code Auswählen Erweitern

#!/usr/bin/python3
# Windmesser
import RPi.GPIO as GPIO
import time, sys, os

# SoC als Pinreferenz waehlen
GPIO.setmode(GPIO.BCM)
GPIO.setup(27, GPIO.IN)


# Variable Counter definieren
sample_each_ms = 10000
counter = 0

t1 = time.time()

def Interrupt(channel):
   global counter
   counter = counter + 1
   print "Counter " + str(counter)

# Interrupt Event hinzufuegen. Pin 27, auf steigende Flanke reagieren und ISR "Interrupt" deklarieren
GPIO.add_event_detect(27, GPIO.RISING, callback = Interrupt, bouncetime = 10)


# Endlosschleife
while True:
   t2 = time.time()
   
   delta = t2-t1 
   if delta >= sample_each_ms/1000: 
    if counter > 0: 
      speed = ((((counter/delta) + 2) / 3) * 3.6)
      os.system('perl /opt/fhem/fhem.pl 7072 "setreading WindgeschwindigkeitExt state '+str(speed)+'"')
      sys.stdout.write('counter = {} \n'.format(counter))
      counter=0  
    else:
      os.system('perl /opt/fhem/fhem.pl 7072 "setreading WindgeschwindigkeitExt state 0"')
      sys.stdout.write('counter = 0 \n')
 
    t1=t2


[klausw]

Danke für die Info.

Ich habe mittlerweile versucht mir mittels eines Python scripts über RPI.GPIO Lib zu behelfen.
(und mich da in die ISR callback zu hängen). Leider funktioniert das nur wenn FHEM nicht läuft, auch wenn ich den entsprechenden Pin nicht benutze.

Wenn FHEM läuft wird kein interrupt ausgelöst, es sei denn ich definiere den Pin zusätzlich in fhem als RPI_GPIO. Gibts da irgendeinen Rechte/Resourcen Konflikt mit der Art wir RPI_GPIO die Ports benutzt?

Sollte es nicht geben. Vom rpi_gpio Modul werden nur die Pins exortiert, die per define angelegt wurden. Eigentlich ist es auch so, das ein anderweitig verwendeter GPIO, für die Verwendung mit dem rpi_gpio Modul blockiert ist.

[Nemo0815]

Sollte es nicht geben. Vom rpi_gpio Modul werden nur die Pins exortiert, die per define angelegt wurden. Eigentlich ist es auch so, das ein anderweitig verwendeter GPIO, für die Verwendung mit dem rpi_gpio Modul blockiert ist.

Danke,

Ich das Modul war auch nicht schuld, sorry für die Verwirrung. Anscheinend hat die RPI.GPIO Lib ein Problem sobald man os.system im Script benutzt (dann wird der Interrupt wieder disabled), mit subprocess.call dagegen funktioniert alles wie erwartet.

[MichaS]

Hallo zusammen,

nachdem ich nun einige Stunden damit verbracht habe, die Dateiberechtigungen zum GPIO Zugriff auf einem Raspi hinzubekommen, möchte ich euch gerne meine Erfahrungen hier mitteilen 

Installiert ist auf dem RPi das relativ aktuelle Raspbian 3.18.11+ von Ende April 2015 und die WiringPi Bibliothek. Nach dem Anlegen eines Outputs über define Relais RPI_GPIO 17 konnte ich das angeschlossene Relais auch schalten. Allerdings benötigt meine Relaisplatine eine invertierte Logik, schaltet also bei LOW ein. Mit dem Attribut active_low = yes sollte diese Invertierung greifen, hat es bei mir aber ersteinmal nicht getan. Ein Blick ins Log zeigt dann: Can't open file: Relais, active_low, also ein Berechtigungsproblem 

Nach Lesen der commandref ist der erste Ansatz, per sudo adduser fhem gpio den User fhem der Gruppe gpio zuzuorden - Leider gibt es scheinbar im aktuellen Raspbian keine solche Gruppe mehr.

Zweiter Ansatz aus der commandref: in der Datei rc.local die Berechtigungen setzen, bevor Fhem startet. Die Einträge von dort übernommen und angepasst - leider immer noch kein Zugriff auf die Dateien, diese werden nach Reboot immer wieder mit root:root neu angelegt und sind von fhem aus nicht beschreibbar.

Nach Recherche im Web habe ich dann herausgefunden, das es in neueren Raspian Versionen eine Veränderung im Device Tree gegeben hat und das beschriebene Verzeichnis /sys/devices/virtual nicht mehr existiert. Nun findet man die Datein hier /sys/devices/soc/....

Folgender Eintrag in der rc.local funktioniert nun endlich auch mit dem aktuellen Raspian:

Code Auswählen Erweitern

echo 17 > /sys/class/gpio/export
chown -R fhem:root /sys/devices/soc/*.gpio/*
chown -R fhem:root /sys/class/gpio/*

Gruß Micha