Drehgeber am Pi

Für sowas wurden Interrupts erfunden, damit man nicht permanet und 
sinnlos pollen muß ...

Wenn Python eine Option ist, hätte ich folgenden Code (s. Anhang)
Beispiel für Benutzung:

1

import time

2

import RPi.GPIO as GPIO

3

from encoder import Encoder

4

5

def DrehTest(val):

6

  print('Gedreht: %+d' % (val))

7

8

9

### Main routine ###

10

11

if __name__ == "__main__":

12

  GPIO.setwarnings(False)       # Disable this line on Rev 1 boards

13

  GPIO.setmode(GPIO.BCM)       # Use BCM GPIO numbers

14

15

  e = Encoder(18, 17)      # Encoder an GPIO 17 und 18

16

  e.SetValueHandler(DrehTest, 4)

17

18

  while True:

19

    time.sleep(1)

>

Gruß Andreas

> Und das läuft zuverlässig?

Mehr oder weniger. Ab und zu wird ein Schritt vergessen. Kannst noch was 
an den Debounce-Zeiten rumspielen. Hatte ich mal für mein Raspi-Radio im 
Einsatz.
Für meine neuere Version des Radios habe ich dann einen ATmega als I2C 
Slave eingebaut. Das hatte den Vorteil, dass er die ganze Bitschubserei 
machen kann (LCD, Drehencoder, Taster, PWM LCD-Beleuchtung). Das läuft 
schon besser; obwohl man dann wieder das Problem hat, dass der RASPI 
kein I2C Clock-Stretching kann :-(
Aber du kannst meine Python-Lösung gern ausprobieren, kostet ja nix :-)
Für den Encoder 
https://www.reichelt.de/Drehimpulsgeber/STEC12E08/3/index.html?&ACTION=3&LA=5000&GROUP=B29&GROUPID=3714&ARTICLE=73923&START=0&SORT=-rank&OFFSET=500 
hatte ich den Teiler 4 genommen.

raspi-user schrieb:
> Ja, aber dann muss ich immer diese Schleife mitlaufen lassen und
> wenn
> die Drehgeber vielleicht alle paar Stunden mal ein Signal ausgeben finde
> ich, ist das viel verschwendete Rechenzeit. Außerdem geht das doch in
> die Hose, wenn die CPU mal von anderen Prozessen stark ausgelastet wird,
> oder?

Alles eine Frage der Timer-Interrupt-Priorität.

Die muss so oder so höher sein als die Priorität dieser anderen 
Prozesse, denn sonst würde das System ja nicht auf den Drehgeber 
reagieren wenn diese Prozesse ihn (über)lasten. Egal ob die Drehgeber 
direkt ausgewertet werden oder per SPI oder anderer Schnittstelle ein 
extra Auswertechip angeschlossen wird, blöd wäre eine zu geringe 
Priorität also in jeden Fall.

Es ist auch vollkommen egal, ob der rPi 0.1% seiner Rechenzeit dauerhaft 
auf die Abfrage sich nicht-bewegender Drehgeber investiert, denn auch im 
Höchstauslastungsfall muss er diese 0.1% Rechenleistung übrig haben. Er 
hat sie also sowieso übrig, und übriges kann man nutzen, immer, 
jederzeit.

Jens G. schrieb:
> Für sowas wurden Interrupts erfunden, damit man nicht permanet und
> sinnlos pollen muß ...

Oh nö, noch ein total Ahnungsloser.

Andreas R. schrieb:
> Wenn Python eine Option ist

Das iat natürlich die schlechteste Lösung von allen, eine Skriptsprache 
die nicht am Timer-Interrupt hängt und deren Priorität nicht angepasst 
werden kann. Aber erstaunlich, wenn es damit immer noch funktioniert.

Andreas R. schrieb:
> Ab und zu wird ein Schritt vergessen

Ok, funktioniert nicht, wird hier aber trotzdem als Lösung angepriesen. 
Die üblichen Mistkonstruktionen also, hätte man schon daran sehen können 
daß jemand meint, Drehgebereingänge "debouncen" zu müssen.

> Ok, funktioniert nicht, wird hier aber trotzdem als Lösung angepriesen.
> Die üblichen Mistkonstruktionen also, hätte man schon daran sehen können
> daß jemand meint, Drehgebereingänge "debouncen" zu müssen.

Ja nimm unbedingt meine Lösung alles andere ist Mist. Und ich bin total 
sauer wenn du sie nicht nimmst. Ich bin nämlich der einzige der Ahnung 
hat.
@laberkopp: Denkst du so?

Andreas R. schrieb:
> Denkst du so?

Ich denke, daß ein Lösungsvorschlag, der "ab und zu wird ein Schritt 
vergessen" nicht als Lösungsvorschlag taugt.

Sollte so was auch China kommen, wir hier gleich laut geschrieen, das 
wäre Chinapfusch.

An dir sieht man aber: Deutsche Lösungen sind noch schlimmer, aber 
arrogant behaupten Leute wie du, die Lösung wäre schon gut.

Nein, sie ist Pfusch und bleibt Pfusch, auch wenn du sie erfunden hast.

Andreas R. schrieb:

> Ja nimm unbedingt meine Lösung alles andere ist Mist.

Nun, Drehgeber werden extra so gebaut, das man sie mit Auswertung
der Zustände eindeutig dekodieren kann. Lösungen, die auf Flanken
reagieren, sind eindeutig "Mist", da sie bei älteren Drehgebern
eben eindeutig nicht mehr zuverlässig funktionieren. Wenn man
sowieso per Rechner auswertet, sollte es auch keinen Unterschied
machen, ob man ein "richtiges" oder ein "falsches" Programm
verwendet. Das Wissen über die richtige Auswertung von Drehgebern
ist übrigens Jahrzehnte alt und keine "neue" Erfindung.

Leute nun lasst mal die Kirche im Dorf.  Der TE  kann doch selbst 
entscheiden ob er den PI mal kurz per Steckbrett mit dem Encoder testet 
oder nicht. Vielleicht reicht es für manche Anwendung wenn alle 30 
Schritte einer vergessen wird. Natürlich kann man auch eine hoch.-priore 
Anfrage-Task schreiben oder den Linux-Kernel anpassen oder ein 
Echtzeit-Linux installieren. Nach oben sind da sicher keine Grenzen.