PCF8574 rotary Encoder

TR.OLL schrieb:
> einen rotary Encoder auslesen kann?

Eine Von-hinten-durch-die-Brust-Ins-Auge-Lösung.

Zu träge bzw. zu viel Last für den Prozessor.

TR.OLL schrieb:
> einen rotary Encoder auslesen kann

TROLL am Freitag, sein Name ist Programm!

Einen Drehencoder an einen I2C-Baustein hängen zu wollen klingt einfach 
nur dämlich.

OMG schrieb:
> TR.OLL schrieb:
>> einen rotary Encoder auslesen kann?
>
> Eine Von-hinten-durch-die-Brust-Ins-Auge-Lösung.
>
> Zu träge bzw. zu viel Last für den Prozessor.

Ich nutze den Interrupt des PCF8574,  deswegen sollte ich keine Probleme 
mit der hohen Last des Prozessors haben, weil ich den PCF8574 immer dann 
auslese, wenn der InterruptPin auf LOW ist.

Die Suche liefert einiges. Z.B.:

https://www.thecoderscorner.com/products/arduino-libraries/io-abstraction/rotary-encoder-switches-interrupt-pcf8574/

pegel schrieb:
> Die Suche liefert einiges. Z.B.:
>
> 
https://www.thecoderscorner.com/products/arduino-libraries/io-abstraction/rotary-encoder-switches-interrupt-pcf8574/

Ich habe diese Library schon ausprobiert. Aber erfolglos...

TR.OLL schrieb:
> ausprobiert. Aber erfolglos

Deshalb bin ich kein Ardu*-Fanboy.

TR.OLL schrieb:
> Ich nutze den Interrupt des PCF8574,

Wozu ?

Ein Drehencoder wird in zeitlich festem Raster ausgelesen, da hilft ein 
Interrupt genau gar nichts.

http://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29

Doch ein typischer TR.OLL, fachlich auf dem Holzweg.

Nein, für Arduino kenne ich nichts vorgefertigtes, ich programmiere noch 
an statt shields zusammenzuklicken.

MaWin schrieb:
> Ein Drehencoder wird in zeitlich festem Raster ausgelesen, da hilft ein
> Interrupt genau gar nichts.

Dein Absolutismus grenzt an Grössenwahn.

Du kannst schreiben dass du es so machen würdest, aber es "wird"
nicht generell so gemacht.

Insbesondere macht es keinen Sinn einen Drehencoder dauernd
abzufragen wenn dort gar nichts passiert.

Beo Bachta schrieb:
> Dein Absolutismus grenzt an Grössenwahn

Mein Grössenwahn besteht ausschliesslich darin, dass ich für eine 
Schraube einen Schraubendreher verwende.

Du einen Hammer.

Das ist blöd, wenn man nur einen Hammer hat, überall nur Nägel zu sehen. 
Eine genagelte Schraube mag schneller drin sein, hält aber nicht.

Ein pin change interrupt ausgelesener Drehencoder funktioniert genau so 
wenig.

Beo Bachta schrieb:
> Insbesondere macht es keinen Sinn einen Drehencoder dauernd
> abzufragen wenn dort gar nichts passiert

Was bitte soll der Prozessor denn sonst tun, wenn sich am Drehencoder 
nichts tut ? Er kann nichts sinnvolles tun, denn er muss jederzeit die 
Rechenzeit übrig haben, um ein plötzliches Drehen doch auswerten zu 
können.  Dann kann ef sie gleich dauerhaft dafür einsetzen statt dumm 
rum zu warten.

Du hast also wirklich auf dämlichste Art getrollt. Nun schlaf deinen 
Rausch aus.

MaWin schrieb:
> Ein pin change interrupt ausgelesener Drehencoder funktioniert genau so
> wenig.

Dann bin ich ein echter Wunderheiler. Denn meine Pin Change IRQ
Programmierung funktioniert "seltsamerweise". Wunder gibt es
immer wieder (Katja Ebstein).

MaWin schrieb:
> Du hast also wirklich auf dämlichste Art getrollt.

Du reihst dich übrigens nahtlos in die übrigen Dämlichmacher
hier im Forum ein. Leider hilft das Vorhalten eines Spiegels
bei dir gar nichts mehr, da ist Hopfen und Malz verloren.

Beo Bachta schrieb:
> Denn meine Pin Change IRQ
> Programmierung funktioniert "seltsamerweise".

Genau so gut wie die in vielem kommerziellen Geräten deren Entwickler 
genau so arrogant dumm waren wie du es bist und die die Kunden damit zur 
Weissglut bringen weil der Knopf nicht so spurt wie sie erwarten.

Merke: Verfahren, die schon in der Theorie ihre Schwächen zeigen und 
nicht funktionieren, funktionieren in der Praxis erst recht nicht, 
selbst wenn beim Entwicklertest erst alles ok erscheint.


Beo Bachta schrieb:
> Du reihst dich übrigens nahtlos in die übrigen Dämlichmacher

Alles Geisterfahrer. Dabei ist das Thema hinreichend durchdiskutiert, du 
hättest nur mal zuhören müssen.

TR.OLL schrieb:
> weil ich den PCF8574 immer dann
> auslese, wenn der InterruptPin auf LOW ist.

Tust du nicht, zwischen dem Signal und dem Auslesen vergeht signifikant 
Zeit - genau das wird Dein Problem werden.

Joachim B. schrieb:
> Auch einen PCF8574 der braucht nur µs, bei 400kHz die der 8574 auch noch
> schafft evtl. 100µs.

Sonst hat dein µC nichts anderes zu tun? Dann kann das klappen.

Joachim B. schrieb:
> deswegen hat er viel Zeit ... in der wordclock12h

Ja das wird das wohl kein Problem sein. Wer es schafft, einen µC mit so 
einer Anwendung auszulasten, hat ganz andere Probleme.

Matthias S. schrieb:
> Dann kann man sich immer noch
> überlegen, welche Strategie hier die sinnvollere ist.
> Denn zuerst muss ja I²C laufen, bevor es weitergeht.

Das I2C geht schon und den PCF8574 kann ich ansprechen

Auslesen kann ich die Daten von einem Inkrementaldrehgeber jetzt aber es 
fehlt noch der Teil, der auswertet in welche Richtung der 
Quadraturencoder gedreht worden ist.

Code der nicht geht:

1

  if(di.p1 == true){

2

      button_last_pressed = 1;

3

    }

4

     if(di.p3 == true){

5

      button_last_pressed = 4;

6

    }

7

  /*   if(di.p2 == true){

8

      button_last_pressed = 3;

9

    }

10

     if(di.p3 == true){

11

      button_last_pressed = 4;

12

    }*/

13

    changed = false;

14

    Serial.println(button_last_pressed);

15

/*

16

     encoderPinANow = di.p2;

17

     if ((encoderPinALast == HIGH) && (encoderPinANow == LOW)) {

18

      if (di.p1 == HIGH) {

19

       button_last_pressed = 3;

20

       Serial.println("up");

21

      } else {

22

        button_last_pressed = 2;

23

        Serial.println("down");

24

      }

25

  }

26

  encoderPinALast = encoderPinANow;

27

*/

28

  encoderPinANow = di.p2;

29

  if(encoderPinANow == HIGH && encoderPinALast == LOW){

30

    if(di.p1 == LOW){

31

      button_last_pressed = 3;

32

      Serial.println("up");

33

    }

34

    if(di.p1 == HIGH){

35

      button_last_pressed = 2;

36

      Serial.println("down");

37

    }

38

  }

39

 if(encoderPinANow == LOW && encoderPinALast == HIGH){

40

    if(di.p1 == HIGH){

41

      //button_last_pressed = 3;

42

      Serial.println("up");

43

    }

44

    if(di.p1 == LOW){

45

      //button_last_pressed = 2;

46

      Serial.println("down");

47

    }

48

  }

49

  encoderPinALast = encoderPinANow;

TR.OLL schrieb:
> Code der nicht geht

Du hast offenbar in di die Anschlüsse A und B des Encoders.

Dein Code wertet bei Flankenwechsel von A die Spur B aus und wandelt das 
in einen Tastendruck up oder down um.
Warum zum Schluss auskommentiert, weiss der Geier

Diese Methode des Flankenwechsels funktioniert nicht, wie schon 
geschrieben. Das Prellen beim übergang produziert dutzende Tastendrücke.

Warum glaubst du den Code unbedingt selbst noch mal falsch entwerfen zu 
müssen, an statt einfach bekannt funktionierende Beispiele abzuschreiben 
?

Ja, wenn man JEDE Position des Drehencoders nutzen will, gibt es 
heftiges Geflatter an den Übergängen. Daher haben die meisten Encoder 2 
Übergänge zwischen den Rastpositionen.

Nutzt man nur jede 2. Position, kann man nämlich up/down ohne Geflatter 
erzeugen.

http://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29

1

  int table[4][4]={{0,1,0,0},{0,0,0,0},{0,0,0,-1},{0,0,0,0}}; 

2

3

  new_quadrature_value=di.p1+2*di.p2;

4

  switch(table[last_quadrature_value][new_quadrature_value])

5

  {

6

  case 1:

7

     // up

8

     break;

9

  case -1:

10

     // down

11

     break;

12

  }

13

  last_quadrature_value=new_quadrature_value;

Jetzt geht der Code.

Danke für die Hinweise!

Hallo,

ich habe jetzt aber noch folgendes Problem:

Wenn ich den PCF8574 über auslese zeigt das LCD2004 (mit I2C) zufällige 
Zeichen an (siehe Bild als Anhang). Kennt jemand eine Lösung für das 
Problem?

Danke im Vorraus.

TR.OLL schrieb:
> Wenn ich den PCF8574 über auslese

Ich rate: Du hast zwei PCF8574 mit derselben Adresse.

Tippgeber schrieb:
> TR.OLL schrieb:
>> Wenn ich den PCF8574 über auslese
>
> Ich rate: Du hast zwei PCF8574 mit derselben Adresse.

Nein, der PCF8574 der den Encoder ausliest hat die Adresse 0x20 und der 
PCF8574 am Display hat die Adresse 0x3F.

Hi

>Wenn ich den PCF8574 über auslese zeigt das LCD2004 (mit I2C) zufällige
>Zeichen an (siehe Bild als Anhang). Kennt jemand eine Lösung für das
>Problem?

Wahrscheinlich benutzen beide PCF8574 die gleiche Adresse. Also must du 
einen über A0..2 eine neue Adresse geben.

MfG Spess

Und da schreib nochmal einer, die ARM Cortex-M3/4/7 wären so 
kompliziert.
Auf nem STM32 schreibe ich eine Handvoll Config-Bits und kann dann schön 
das Zähler-Register auslesen - Interrupt geht natürlich auch. Alles in 
Hardware.
Einfacher geht es nicht.
Spart übrigens auch externe Bausteine...

John Doe schrieb:
> Und da schreib nochmal einer, die ARM Cortex-M3/4/7 wären so
> kompliziert.
> Auf nem STM32 schreibe ich eine Handvoll Config-Bits und kann dann schön
> das Zähler-Register auslesen - Interrupt geht natürlich auch. Alles in
> Hardware.
> Einfacher geht es nicht.
> Spart übrigens auch externe Bausteine...

Und was hat das mit der eigentlichen Frage zutun?



spess53 schrieb:
> Hi
>
>>Wenn ich den PCF8574 über auslese zeigt das LCD2004 (mit I2C) zufällige
>>Zeichen an (siehe Bild als Anhang). Kennt jemand eine Lösung für das
>>Problem?
>
> Wahrscheinlich benutzen beide PCF8574 die gleiche Adresse. Also must du
> einen über A0..2 eine neue Adresse geben.
>
> MfG Spess

Die haben unterschiedliche Adressen.

TR.OLL schrieb:
> Nein, der PCF8574 der den Encoder ausliest hat die Adresse 0x20 und der
> PCF8574 am Display hat die Adresse 0x3F.

Dann liegt der Fehler in Deiner Software.

Tippgeber schrieb:
> TR.OLL schrieb:
>> Nein, der PCF8574 der den Encoder ausliest hat die Adresse 0x20 und der
>> PCF8574 am Display hat die Adresse 0x3F.
>
> Dann liegt der Fehler in Deiner Software.

Ja, aber wo?

Axel S. schrieb:
> TR.OLL schrieb:
>> Tippgeber schrieb:
>>>
>>> Dann liegt der Fehler in Deiner Software.
>>
>> Ja, aber wo?
>
> In Zeile 42. Wie immer.

Jetzt stellt sich nur die Frage in welcher Datei?

TR.OLL schrieb:
> Wenn ich den PCF8574 über auslese zeigt das LCD2004 (mit I2C) zufällige
> Zeichen an (siehe Bild als Anhang). Kennt jemand eine Lösung für das
> Problem?

Wenn Du den 8574 durch einen ATtiny25 ersetzt, hast Du nicht nur das 
Problem mit der IIC-Adressierung gelöst: 
Beitrag "mini Quadraturdekoder + 32 Bit Zähler + TWI, Attiny25"
Probiere es doch einfach aus.