DogM Display durch Drehgeber gestört.

Robert Gast #2482010
Lesenswert?
• ▲
▼ 
Hallo, Ich habe ein DogM Display zusammen mit einem ALPS Drehgeber mit 
Taster auf einer Platine (geätzt) verbaut und das Ganze mit der 
Steuereingheit über ein Flachbandkabel verbunden. Wenn ich sehr schnell 
an dem Drehgeber drehe stürzt das Display ab.

Ich denke, dass die Schwingungen auf den Drehgeberleitungen die 
SPI-Kommunikation zum Display stören.

Jetzt meine Frage:
Wie kann ich mit überschaubarem Aufwand das Problem lösen?
Das Kabel ist ca 30cm lang und hat nah am Steuergerät ein Ferrit.
Vcc und GND sind auch in dem Flachbandkabel mit drin. Die 
Displaybeleuchtung hat ein eigenes kabel, welches auch Vcc und GND hat 
(ohne Ferrit).

Zusatzfrage:
Der Drehgeber hört bei Reichelt auf diese Nummer: STEC12E08; Welche 
Routine aus dem Artikel "Drehgeber" ist denn die richtige?
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Sascha W. #2482026
Lesenswert?
• ▲
▼ 
Robert schrieb:
> Hallo, Ich habe ein DogM Display zusammen mit einem ALPS Drehgeber mit
> Taster auf einer Platine (geätzt) verbaut und das Ganze mit der
> Steuereingheit über ein Flachbandkabel verbunden. Wenn ich sehr schnell
> an dem Drehgeber drehe stürzt das Display ab.
>
> Ich denke, dass die Schwingungen auf den Drehgeberleitungen die
> SPI-Kommunikation zum Display stören.
werden denn während des drehens Daten zum Display übertragen?

Damit eine nennenswerte Störung auftreten kann müsste über die Kontakte 
des Drehgebers schon einiges an Strom fließen - wie hast du den 
beschaltet.

Sascha
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Falk B. #2482030
Lesenswert?
• ▲
▼ 
@  Robert (Gast)

>Steuereingheit über ein Flachbandkabel verbunden. Wenn ich sehr schnell
>an dem Drehgeber drehe stürzt das Display ab.

Hmmm.

>Ich denke, dass die Schwingungen auf den Drehgeberleitungen die
>SPI-Kommunikation zum Display stören.

Wenn du DAS schaffst, bist du ein Künstler. Ein Drehgeber hat typisch 
Schalter gegen Masse, die per Pull-Up auf Vcc gezogen werden. Das Ganze 
sit so schlaff und langsam, dass da kaum was koppeln kann.

>Wie kann ich mit überschaubarem Aufwand das Problem lösen?

Erstmal sich über Netiquette informieren und sinnvolle Informationen 
bereitstellen. Schaltplan z.B.

>Das Kabel ist ca 30cm lang und hat nah am Steuergerät ein Ferrit.
>Vcc und GND sind auch in dem Flachbandkabel mit drin. Die

Schön, reicht aber bei weitem nicht.

Ich tippe auf einen Softwarefehler.

MfG
Falk
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Robert Gast #2482042
Lesenswert?
• ▲
▼ 
Falk Brunner schrieb:


> Erstmal sich über Netiquette informieren und sinnvolle Informationen
> bereitstellen. Schaltplan z.B.

>>Das Kabel ist ca 30cm lang und hat nah am Steuergerät ein Ferrit.
>>Vcc und GND sind auch in dem Flachbandkabel mit drin. Die
>
> Schön, reicht aber bei weitem nicht.

Lieber Falk, ich frage mich, was an meinem Beitrag hinsichtlich der 
Netiquette falsch ist... Ich habe eine konkrete Frage mit den meiner 
Meinung nach nützlichen Informationen gestellt. Auf meinen Ton und meine 
Gramatik habe ich auch geachtet und meine Versuche, das Problem zu 
begrenzen (Ferrite)
 habe ich auch geschildert.

Ein plumpes
> Hmmm.
>
ohne jegliche hilfreiche Information... Schade eigentlich!
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Johannes O. #2482051
Lesenswert?
• ▲
▼ 
Ich könnte mir vorstellen dass sich dein µC an den Interrupts 
verschluckt weils einfach so viele werden?
Aber genaueres kann man da nicht sagen ohne Schaltplan und Quellcode.

Nur zum Vergleich: Hab hier ein SPI mit 10MHz laufen und daneben schalte 
ich mit ca. 3-4KHz einen Strom von mehr als 10A. Abstand sind einige cm. 
Da stört sich ÜBERHAUPTS NIX.

Das bisschen µA bis mA was da der Drehencoder zieht geht bei sowas im 
Rauschen unter ;-) Das kanns also schonmal nicht sein!
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Robert Gast #2482064
Lesenswert?
• ▲
▼ 
Johannes O. schrieb:
> Ich könnte mir vorstellen dass sich dein µC an den Interrupts
> verschluckt weils einfach so viele werden?

Es sind keine Interrupts.

1
void encode_init( void )

2
{

3
  int8_t new;

4
 

5
  new = 0;

6
  if( PHASE_A )

7
    new = 3;

8
  if( PHASE_B )

9
    new ^= 1;                   // convert gray to binary

10
  last = new;                   // power on state

11
  enc_delta = 0;

12
  TCCR0 = 1<<WGM01^1<<CS01^1<<CS00;     // CTC, XTAL / 64

13
  OCR0 = (uint8_t)(XTAL / 64.0 * 1e-3 - 0.5);   // 1ms

14
  TIMSK |= 1<<OCIE0;

15
}

16
 

17
 

18
ISR( TIMER0_COMP_vect )             // 1ms for manual movement

19
{

20
  int8_t new, diff;

21
 

22
  new = 0;

23
  if( PHASE_A )

24
    new = 3;

25
  if( PHASE_B )

26
    new ^= 1;                   // convert gray to binary

27
  diff = last - new;                // difference last - new

28
  if( diff & 1 ){               // bit 0 = value (1)

29
    last = new;                 // store new as next last

30
    enc_delta += (diff & 2) - 1;        // bit 1 = direction (+/-)

31
  }

32
}

33
 

34
 

35
int8_t encode_read1( void )         // read single step encoders

36
{

37
  int8_t val;

38
 

39
  cli();

40
  val = enc_delta;

41
  enc_delta = 0;

42
  sei();

43
  return val;                   // counts since last call

44
}

45


46
int main( void )

47
{

48
  int32_t val = 0;

49
 

50
  LEDS_DDR = 0xFF;

51
  encode_init();

52
  sei();

53
 

54
  for(;;){

55
    val += encode_read1();          // read a single step encoder

56
    LEDS = val;

57
  }

58
}

Zum Schaltplan: Ich habe kein Bild, aber der Drehgeber schaltet nach 
Masse, über die internen Pull-Ups am Port (ATMega1281).
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Robert Gast #2482073
Lesenswert?
• ▲
▼ 
Hauptroutine:
1
void app_task(void){

2
  val += encode_read1();          // read a single step encoder

3
  if(val>1){ app_status.button_state = BLEFT_PRESSED;

4
  }else if(val < -1){ app_status.button_state = BRIGHT_PRESSED;

5
  }    

6
  val = 0;

7


8
  ...

9
  

10
  if(display_on()){

11
    if(off == 1){

12
      

13
      dog_transmit(LCD_ON);

14
      app_status.button_state = 0x00;

15
    }      

16
    

17
    dog_home();

18
    dog_print(); <<Da wird das Display beschrieben

19
    off = 0;

20
  }else{

21
    if(off == 0){

22
      dog_home();

23
      dog_clear_lcd();

24
      dog_transmit(LCD_OFF);

25
      //dog_transmit(PWR_SAVE);

26
      off = 1;

27
    }

28
    //sleep

29
  }

30
}
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Robert Gast #2482106
Lesenswert?
• ▲
▼ 
In der entsprechenden Initialisierungsroutine...
1
void app_button_init(void){

2
  BUTTON_PORT |= (1<<BUTTON0) | (1<<BUTTON2) | (1<<BUTTON3);

3
  BUTTON_DDR |= (1<<BUTTON0) | (1<<BUTTON2) | (1<<BUTTON3);

4
  EICRB |= /*(1<<ISC41) | (1<<ISC51) |*/ (1<<ISC61) /* |(1<<ISC71)*/;

5
  EIMSK |= /*(1<<INT4) | (1<<INT5) |*/ (1<<INT6)/* | (1<<INT7)*/;

6
  EIFR = 0;

7
}

Button0 ist der Taster, die andenren beiden der Geber. Da es langsam 
funktioniert, sollte es eigentlich schnell(so schnell am den Drehgeber 
von Hand drehen kann) auch funktionieren.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Sascha W. #2482129
Lesenswert?
• ▲
▼ 
@Robert,

kann es sein, das bei schneller Drehung die Daten so schnell 
nacheinander an das Display gesendet werden, das dies noch nicht wieder 
zur Aufnahme neuer Daten bereit ist?
Wird der Status vorm senden von neuen Daten abgefragt?
Wie sieht das fehlerhafte Verhalten am Display aus?

Sascha
Antwort Zitieren Bearbeiten Löschen Beitrag melden
g457 Gast #2482136
Lesenswert?
• ▲
▼ 
> es gibt Hauptroutinen und davon wieder Hauptroutinen... das ist beliebig
> oft rekursierbar!

Nö isses nicht, weil dann wärs echt turingmächtig ;-)

Mach mal ein Minimalprogramm, das den Fehler erzeugt (-> Netiquette) und 
dann zeig uns den ∗vollständigen∗ Quellcode (-> Netiquette), ggf. nebst 
Schaltplan und aussagekräfigten Fotos vom Aufbau.

Ich tippe ebenfalls auf einen klassischen Softwarefehler.

HTH und nix für ungut.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Robert Gast #2482146
Lesenswert?
• ▲
▼ 
Sascha Weber schrieb:
> kann es sein, das bei schneller Drehung die Daten so schnell
> nacheinander an das Display gesendet werden, das dies noch nicht wieder
> zur Aufnahme neuer Daten bereit ist?

Nein. Die Daten werden ja unabhängig vom Drehgeber bei jedem Durchgang 
durch das Programm gesendet. So das es nicht flackert.

> Wird der Status vorm senden von neuen Daten abgefragt?

Wessen Status?

> Wie sieht das fehlerhafte Verhalten am Display aus?

Es scheint, als würden die Zeilen/Spalten mit fehlerhaften Daten oder in 
der falschen Reihenfolge beschrieben. es geht auch die initialisierung 
des Displays verloren, es reagiert im nächsten Durchlauf nicht mehr.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Sascha W. #2482155
Lesenswert?
• ▲
▼ 
Robert schrieb:
> Sascha Weber schrieb:
>> kann es sein, das bei schneller Drehung die Daten so schnell
>> nacheinander an das Display gesendet werden, das dies noch nicht wieder
>> zur Aufnahme neuer Daten bereit ist?
>
> Nein. Die Daten werden ja unabhängig vom Drehgeber bei jedem Durchgang
> durch das Programm gesendet. So das es nicht flackert.
??? Nicht das ich schon mal mit einem DOGM gearbeitet hätte, aber das 
das Display ohne ständigen Datennachschub nichts anzeigt währe mit neu!
Es ist doch nur dann notwendig was zu senden wenn sich auf dem Display 
was ändern soll.

>> Wird der Status vorm senden von neuen Daten abgefragt?
>
> Wessen Status?
den vom Display

>> Wie sieht das fehlerhafte Verhalten am Display aus?
>
> Es scheint, als würden die Zeilen/Spalten mit fehlerhaften Daten oder in
> der falschen Reihenfolge beschrieben. es geht auch die initialisierung
> des Displays verloren, es reagiert im nächsten Durchlauf nicht mehr.
das sieht so aus, als wenn die Daten vom Display nicht vollständig 
verarbeitet werden und dadurch versteht das Display dann Mist.

Sascha
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Robert Gast #2482264
Lesenswert?
• ▲
▼ 
Sascha Weber schrieb:
> das sieht so aus, als wenn die Daten vom Display nicht vollständig
> verarbeitet werden und dadurch versteht das Display dann Mist.

Das sehe ich anders. Der Drehgeber wird wie im Artikel gepollt, damit 
fällt ein overrun aus. Das Display wird erst dann beschrieben, wenn 
alles im Programm dafür fertig ist. Der Drehgeber ändert ja nichts am 
Programmablauf, triggert keine IRQs sondern setzt nur zwei (!) flags - 
daran kann es nicht liegen.

Für mich scheint es eher, als würden die gesendeten Daten verfälscht.

@Michael H.: Und worüber denken WIR nochmal nach?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Sascha W. #2483872
Lesenswert?
• ▲
▼ 
Robert schrieb:
> Für mich scheint es eher, als würden die gesendeten Daten verfälscht.
hast du mal die SPI-Frequenz runter gesetzt?

wie oft wird diese Funktion aufgerufen?
1
void app_task(void){

2
  val += encode_read1();          // read a single step encoder

3
  if(val>1){ app_status.button_state = BLEFT_PRESSED;

4
  }else if(val < -1){ app_status.button_state = BRIGHT_PRESSED;

5
  }    

6
  val = 0;

7


8
  ...

9
  

10
  if(display_on()){

11
    if(off == 1){

12
      

13
      dog_transmit(LCD_ON);

14
      app_status.button_state = 0x00;

15
    }      

16
    

17
    dog_home();

18
    dog_print(); <<Da wird das Display beschrieben

19
    off = 0;

20
  }else{

21
    if(off == 0){

22
      dog_home();

23
      dog_clear_lcd();

24
      dog_transmit(LCD_OFF);

25
      //dog_transmit(PWR_SAVE);

26
      off = 1;

27
    }

28
    //sleep

29
  }

30
}


Sascha
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Robert Gast #2484220
Lesenswert?
• ▲
▼ 
Nochwas: die Leitungen am Drehgeber haben, nachdem ich die BUTTONs als 
Eingänge (schäm) konfiguriert habe, 3,3; 1,7 und 1,7 Volt bei 3,3V Vcc. 
Das Display stürzt jetzt bei dem ersten Dreh ab.

Thema Ferrite: was kann/muss ich tun, damit Störungen aus dem Kabel 
"weggehen"? Oder ist das Kabel viel zu kurz und die Frequenzen des 
Drehgebers zu niedrig um solche Fehler zu verusachen?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Falk B. #2484746
Lesenswert?
• ▲
▼ 
@  Joe J. (neutrino)

>> Thema Ferrite: was kann/muss ich tun, damit Störungen aus dem Kabel
>> "weggehen"?

>Ich hatte einen ähnlichen Fall, bei dem ein "großer" Ferrit über dem
>Dispaykabel das Problem löste, etwa in der Art:

Kaum. Der Op betreibt eine Schaltung ohne nennenswerte EMV-Störer in der 
Umgebung und das Ding schmiert definiert beim ersten drehen ab. Das ist 
kein EMV Problem, sondern was grundlegendes. Ebenso grundlegende wie 
seine Resistenz, mal einen VOLLSTÄNDIGEN Schaltplan unf Quelltext zu 
posten.

MfG
Falk
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Robert Gast #2487320
Lesenswert?
• ▲
▼ 
Sascha Weber schrieb:
> Bleibt mir ein Rätsel was du mit dieser Geschwindigkeit erreichen
> willst.

Es tut mir Leid, aber warum motzt du mich hier so an? Das es suboptimal 
ist, das Display ständig zu beschreiben ist mir klar, aber eben 
wesentlich einfacher, als alle Variablen standig zu überwachen.

Auf meine Frage nach der Möglichkeit der Störung durch den Drehgeber hat 
ja auch noch keiner geantwortet, aber klar; ich bin ja ein Idiot.

Kommt mal wieder runter!
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Falk B. #2487330
Lesenswert?
• ▲
▼ 
@  Robert (Gast)

>ist, das Display ständig zu beschreiben ist mir klar, aber eben
>wesentlich einfacher, als alle Variablen standig zu überwachen.

???
Man kann einfach einen kompletten Update alle 500ms machen, reicht 
locker aus.

>Auf meine Frage nach der Möglichkeit der Störung durch den Drehgeber hat
>ja auch noch keiner geantwortet, aber klar; ich bin ja ein Idiot.

Meine Glaskugel ist kaputt. Und kostenloses Remote Debugging ist auch 
nicht so das Wahre. . .
Antwort Zitieren Bearbeiten Löschen Beitrag melden
meckerziege Gast #2487364
Lesenswert?
• ▲
▼ 
das ist schon geil: es ist streng geheim was du machst und du darfst 
nicht mehr code posten... aber du bist unfähig nen simplen drehgeber zu 
verwenden. von emv hast du auch keine ahnung und meist die ministröme 
die der drehgeber macht, würden solche störungen verursachen.
entweder du rückst mehr code raus und erklärst anständig was los ist, 
oder du kannst alleine weitersuchen.
wenn in den paar zeilen hier schon soviel fehler sind,wieviele sinds 
dann erst im kompletten code? ach ne... streng geheim...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Michael H. #2487423
Lesenswert?
• ▲
▼ 
Robert schrieb:
> Auf meine Frage nach der Möglichkeit der Störung durch den Drehgeber hat
> ja auch noch keiner geantwortet
sicher. weil das bullshit ist. sieh das doch endlich mal ein.

dein drehgeber hat irgendwo pegel auf halber betriebsspannung (!!!) und 
du rennst immer noch gegen die emi-wand.
denk doch mal n bisschen nach.

dein code oder deine hardware ist fehlerhaft. punkt.
wenn du nichts davon rausrückst, kann dir keiner helfen.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Robert Gast #2487439
Lesenswert?
• ▲
▼ 
Nein, teilweise kann ich keine Informationen geben, zum Teil weis ich 
nicht, ob ich das darf, andererseits habe ich keine Lust mir meine 
Anwendung und deren Sinn hier diskutieren zu lassen.

Bei den ganzen wenig hilfreichen 'Tipps' hier, die nur dazu dienen das 
sich hier 'Wissende' profilieren, weil sie mir keine Information zur 
Verbesserung oder Problemlösung geben.

Unglaublich viele Fehler in meinem Code... Ein DDR falsch gesetzt und 
das Display zu oft beschrieben... alles klar!

Wenn ich von all den Sachen hier Ahnung hätte und keine Fehler machen 
würde, bräuchte ich ja kaum fragen - dann würde einfach das, was ich mir 
ausdenke, einfach funktionieren.

Bei uC.net dummgemacht werden: eine selbsterfüllende Prophezeiung.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lothar M. Moderator (Firma: Titel) Persönliche Seite #2487492
Lesenswert?
• ▲
▼ 
Robert schrieb:
> Bei uC.net dummgemacht werden: eine selbsterfüllende Prophezeiung.
Nachdem damit alles gesagt wurde: zurück zum Thema.

Robert schrieb:
> Jetzt meine Frage:
> Wie kann ich mit überschaubarem Aufwand das Problem lösen?
Wie wärs mal mit Messen stat Raten?
So ein Oszibild hat schon manchem die Augen geöffnet...

> Das Kabel ist ca 30cm lang und hat nah am Steuergerät ein Ferrit.
Warum? Erwartest du Gleichtaktstörungen? Hast du differentielle Signale?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
holger Gast #2487524
Lesenswert?
• ▲
▼ 
>dein drehgeber hat irgendwo pegel auf halber betriebsspannung (!!!) und
>du rennst immer noch gegen die emi-wand.

Das ist doch genau der Punkt. Es stimmt etwas nicht.

>Ein DDR falsch gesetzt

Wer weiss wie oft du das noch machst im Code.

Oder das Flachbandkabel hat einfach Kurzschlüsse.

Man kann das Dogm auch einfach vor der Bildschirmausgabe
neu initialisieren ohne es zu löschen.
Das verdeckt dann aber das eigentliche Problem.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren