DogM Display durch Drehgeber gestört.

[Robert (Gast)]

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?

[Sascha W. (sascha-w)]

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

[Falk B. (falk)]

@  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

[Robert (Gast)]

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!

[Falk B. (falk)]

@  Robert (Gast)

>Lieber Falk, ich frage mich, was an meinem Beitrag hinsichtlich der
>Netiquette falsch ist

Es fehlen wesentliche Infromationen wie Schaltplan, ggf. ein Bild. Der 
Ton und die Grammatik waren schon OK.

MFG
Falk

[Johannes O. (jojo_2)]

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!

[Robert (Gast)]

Sascha Weber schrieb:
> werden denn während des drehens Daten zum Display übertragen?

Es werden immer Daten zum Display übertragen, Die Drehgeberroutine (hier 
aus dem Artikel "Drehgeber") läuft jede ms ab. Kurz bevor das Display 
angesprochen wird, wird der Drehgeber ausgewertet.

[Magnus M. (magnetus)]

Robert schrieb:
> Ein plumpes
>> Hmmm.
>>
> ohne jegliche hilfreiche Information... Schade eigentlich!

Den Beitrag von Falk fand ich schon hilfreich:

Falk Brunner schrieb:
> Ich tippe auf einen Softwarefehler.

War übrigens auch meine Vermutung.

[Sascha W. (sascha-w)]

wenn wir nun noch erfahren könnten wie dein Drehgeber angeschlossen und 
beschaltet ist. Sowie (einen Teil) von deiner Software, dann können wir 
mal weiterschauen.

Sascha

[Robert (Gast)]

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.

void encode_init( void )
{
  int8_t new;
 
  new = 0;
  if( PHASE_A )
    new = 3;
  if( PHASE_B )
    new ^= 1;                   // convert gray to binary
  last = new;                   // power on state
  enc_delta = 0;
  TCCR0 = 1<<WGM01^1<<CS01^1<<CS00;     // CTC, XTAL / 64
  OCR0 = (uint8_t)(XTAL / 64.0 * 1e-3 - 0.5);   // 1ms
  TIMSK |= 1<<OCIE0;
}
 
 
ISR( TIMER0_COMP_vect )             // 1ms for manual movement
{
  int8_t new, diff;
 
  new = 0;
  if( PHASE_A )
    new = 3;
  if( PHASE_B )
    new ^= 1;                   // convert gray to binary
  diff = last - new;                // difference last - new
  if( diff & 1 ){               // bit 0 = value (1)
    last = new;                 // store new as next last
    enc_delta += (diff & 2) - 1;        // bit 1 = direction (+/-)
  }
}
 
 
int8_t encode_read1( void )         // read single step encoders
{
  int8_t val;
 
  cli();
  val = enc_delta;
  enc_delta = 0;
  sei();
  return val;                   // counts since last call
}

int main( void )
{
  int32_t val = 0;
 
  LEDS_DDR = 0xFF;
  encode_init();
  sei();
 
  for(;;){
    val += encode_read1();          // read a single step encoder
    LEDS = val;
  }
}

Zum Schaltplan: Ich habe kein Bild, aber der Drehgeber schaltet nach 
Masse, über die internen Pull-Ups am Port (ATMega1281).

[Robert (Gast)]

Hauptroutine:

void app_task(void){
  val += encode_read1();          // read a single step encoder
  if(val>1){ app_status.button_state = BLEFT_PRESSED;
  }else if(val < -1){ app_status.button_state = BRIGHT_PRESSED;
  }    
  val = 0;

  ...
  
  if(display_on()){
    if(off == 1){
      
      dog_transmit(LCD_ON);
      app_status.button_state = 0x00;
    }      
    
    dog_home();
    dog_print(); <<Da wird das Display beschrieben
    off = 0;
  }else{
    if(off == 0){
      dog_home();
      dog_clear_lcd();
      dog_transmit(LCD_OFF);
      //dog_transmit(PWR_SAVE);
      off = 1;
    }
    //sleep
  }
}

[Robert (Gast)]

Achso: Display und Geber hangen am selben Port. (PortE)

[Magnus M. (magnetus)]

Robert schrieb:
>Zum Schaltplan: Ich habe kein Bild, aber der Drehgeber schaltet nach
> Masse, über die internen Pull-Ups am Port (ATMega1281).

Und wo werden die PullUps eingeschaltet?

[Werner A. (homebrew)]

komisch, ich war immer der Meinung, dass main die Hauptroutine ist...

[Robert (Gast)]

In der entsprechenden Initialisierungsroutine...

void app_button_init(void){
  BUTTON_PORT |= (1<<BUTTON0) | (1<<BUTTON2) | (1<<BUTTON3);
  BUTTON_DDR |= (1<<BUTTON0) | (1<<BUTTON2) | (1<<BUTTON3);
  EICRB |= /*(1<<ISC41) | (1<<ISC51) |*/ (1<<ISC61) /* |(1<<ISC71)*/;
  EIMSK |= /*(1<<INT4) | (1<<INT5) |*/ (1<<INT6)/* | (1<<INT7)*/;
  EIFR = 0;
}

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.

[Robert (Gast)]

Werner A. schrieb:
> komisch, ich war immer der Meinung, dass main die Hauptroutine ist...

willst du das Ganze Programm? 12000Zeilen?
es gibt Hauptroutinen und davon wieder Hauptroutinen... das ist beliebig 
oft rekursierbar!

[Johannes O. (jojo_2)]

schonmal ein minimalbeispiel ausprobiert? Also keine 12K zeilen in 
welchen viele Fehler stecken können, sondern NUR mal die encoder-routine 
und ein wenig displayansteuerung?

[Sascha W. (sascha-w)]

@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

[g457 (Gast)]

> 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.

[Robert (Gast)]

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.

[Sascha W. (sascha-w)]

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

[Michael H. (michael_h45)]

Robert schrieb:

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

darüber denken wir nochmal nach.

[Robert (Gast)]

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?

[Robert (Gast)]

entschuldige...
> @Michael H.: Und worüber denken WIR nochmal nach?
ich habs gesehen...

[Sascha W. (sascha-w)]

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?

void app_task(void){
  val += encode_read1();          // read a single step encoder
  if(val>1){ app_status.button_state = BLEFT_PRESSED;
  }else if(val < -1){ app_status.button_state = BRIGHT_PRESSED;
  }    
  val = 0;

  ...
  
  if(display_on()){
    if(off == 1){
      
      dog_transmit(LCD_ON);
      app_status.button_state = 0x00;
    }      
    
    dog_home();
    dog_print(); <<Da wird das Display beschrieben
    off = 0;
  }else{
    if(off == 0){
      dog_home();
      dog_clear_lcd();
      dog_transmit(LCD_OFF);
      //dog_transmit(PWR_SAVE);
      off = 1;
    }
    //sleep
  }
}

Sascha

[Robert (Gast)]

so alle 50 bis 150ms

[Robert (Gast)]

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?

[Michael H. (michael_h45)]

Robert schrieb:
> 1,7
das klingt nach einem kampf zwischen ausgang dogm und ausgang 
controller.
einer will hoch, der andere runter.

bist du dir bei deinen restlichen pin-definitionen wirklich sicher?

miss mal den strom in den controller. strom durch einen kurzschluss 
sollte man schon deutlich vom strom im normalen betrieb unterscheiden 
können.

[Robert (Gast)]

nee... das ist eine Geberleitung für den Drehgeber. Nur die sollte 3V 
haben. und beim drehen auf Masse gezogen werden.

[Robert (Gast)]

Die anderen Ein/Ausgänge stimmen soweit, Stromverbrauch ohne Beleuchtung 
ca 8mA

[Joe J. (neutrino)]

Robert schrieb:
> 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:
http://ecx.images-amazon.com/images/I/41cpZKJy2WL._SL500_AA300_.jpg

Joe

[Falk B. (falk)]

@  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

[Robert (Gast)]

Falk Brunner schrieb:
> Ebenso grundlegende wie
> seine Resistenz, mal einen VOLLSTÄNDIGEN Schaltplan unf Quelltext zu
> posten.

Darf ich nicht ;)

[Joe J. (neutrino)]

Falk Brunner schrieb:
> Das ist kein EMV Problem, sondern was grundlegendes.

Da hast Du wahrscheinlich Recht. Bei mir schmierte das Display ab:
a) manchmal beim Drücken einer Taste
b) manchmal von alleine (z.B. über Nacht)
c) fast immer wenn das Licht im Raum (Leuchtstoffröhre), das in keiner 
Weise mit dem Display in Zusammenhang steht, eingeschaltet wurde.

Joe

[Sascha W. (sascha-w)]

Robert schrieb:
> so alle 50 bis 150ms
so schnell kannst du Änderungen ablesen ???
Bleibt mir ein Rätsel was du mit dieser Geschwindigkeit erreichen 
willst.

Stoppe doch mal die komplette Displayausgabe (nachdem das Teil erst mal 
was anzeigt) und schau ob sich auch dann Änderungen am angezeigten 
Inhalt des Displays ergeben.


Sascha

[Robert (Gast)]

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!

[Falk B. (falk)]

@  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. . .

[meckerziege (Gast)]

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...

[Michael H. (michael_h45)]

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.

[Robert (Gast)]

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.

[citb (Gast)]

Robert schrieb:
> 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.

Dann such alleine.

citb

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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?

[holger (Gast)]

>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.