ATMEGA 32 mit LCD - Probleme mit Interrupt INT0

[Matthias L. (lindner8712)]

Hallo zussamen,

nachdem ich mir ein C-Buch zugelegt habe und das Forum bzw. Codesammlung 
quasi auswendig gelernt habe stehe ich vor einem riesen Problem...

folgendes:
Ich baue gerade ein kleines Netzteil. Hardware funktioniert, Die meisten 
Module des C-Programms auch.

Das Problem ist, ich wollte mit einem NE555 einen Takt generieren, der 
ca alle 500ms das Display aktualisiert (TIMER sind leider keiner mehr 
übrig.) Soll heißen alle Zahlenwerte löschen,
Werte neu berechnen und wieder auf dem LCD anzeigen.

Solange ich das Display mit einem Taster am INT0 Eingang (10kOhm 
Pulldown)
auslöse Funktioniert es auch wenn ich aber den NE555 stecke, hängt sich 
nach einer nicht definierbaren anzahl von INT0 Aufrufen irgendwas auf. 
Das Display wird nicht mehr aktualisiert, wenige sekunden Später fängt 
der µC von vorne im Programm an (schätze mal der Watchdog greift dort 
ein)..

Hat vllt irgendwer eine zündende Idee?

Vielen Dank im Vorraus

Matthias

PS:hier erstmal einige Codeauschnitte ( Im Anhang ist die Komplette 
Quelldatei die ist viel zu lang)

int main(void)

{  
   GICR=(1<<INT0);        //INT0 config
   MCUCR=(1<<ISC01);      //INT0 config
   sei();      //freigabe interrupts
  
  
   while(1)
   {
      asm("NOP");//Mache nichts in der Haupschleife;
      asm("NOP");//Verbrenn nur Zeit und warte auf Interrupts!
   }
   return 0;
}

ISR(INT0_vect)
{
  
  //dtostrf() wird zwar vergewaltigt, 
        //weil sie nicht mit String gefüttert wird
  //funktion trotzdem gegeben!

  //Display Aktualisieren mit NE555 
        //Rechteckgeber 5HZ Signal Duty-cycle ca 5%
   analog_IL=0;
   analog_IH=0;
   analog_U=0;
   analog_T=0;
   analog_IL=adc_read10bit(0,2); 
   analog_IH=adc_read10bit(1,2);
   analog_U=adc_read10bit(2,2);
   analog_T=adc_read10bit(3,2);

   calc_U=analog_U*adc_10;
   lcd_gotoxy(3,1);
   lcd_puts("    ");
   if(analog_U==1023)
   {
      dtostrf( calc_U, 3, 1, s );
   }
   else
   {
      dtostrf( calc_U, 3, 2, s );
   }
   lcd_gotoxy(3,1);
   lcd_puts(s);
   lcd_puts("V");
.
.
.
.
}

[Georg G. (df2au)]

VIEL zu viel Code in der ISR. Setze dir ein Flag und mach die Ausgabe 
dann in der main().

[Matthias L. (lindner8712)]

Hallo,

danke für den Tipp!! :-)

Könnte das die Ursache sein???

mfg

[Georg G. (df2au)]

Du machst z.B. intensiv Gleitpunkt Operationen im Interrupt. Da kann es 
dir schon passieren, dass sich alles gegenseitig überholt :-)

[Joe S. (bubblejoe)]

Und du hast doch sicher irgendwo einen "Grundtakt" mit einem Timer?
Daraus kannst du per Software deine Zeit für die LCD Ausgabe machen.

[Karl H. (kbuchegg)]

Matthias Lindner schrieb:

> nachdem ich mir ein C-Buch zugelegt habe und das Forum bzw. Codesammlung
> quasi auswendig gelernt habe

Dann hätte dir aber auch auffallen müssen

* keine Ausgaben in einer ISR
* keine extensiven Berechnungen in einer ISR, es sei denn es ist 
unumgänglich
* man kann eine Timer-ISR durchaus für mehr als eine Sache hernehmen. Es 
spricht nichts dagegen, dass zb ein für die Tastenentprellung 
zuständiger Timer sich auch noch um so etwas wie eine Systemzeit 
kümmert, bzw. regelmässig wiederkehrende Abläufe anstösst.


Dein Encoder-ISR wird zb regelmässig aufgerufen. Warum kann die nicht 
auch noch ein Flag setzen und dann

volatile uint8_t updateDisplay;


int main()
{
  ....

  while( 1 ) {

    if( updateDisplay )
    {
      updateDisplay = 0;

      ... dein Code für die ADC Abfrage und Ausgabe
    }
  }
}

ISR(TIMER0_OVF_vect)
{
  ....

  updateDisplay = 1;
}

Wenn dir das (wegen der fixen Zeit für die Encoder Auswertung) zu häufig 
ist, dann eben

int main()
{
  ...
  while( 1 )
  {

    if( updateDisplay == 100 )
    {
      updateDisplay = 0;

      ...
    }
  }
}

ISR( ... )
{
  ....
  updateDisplay++;
}

[Karl H. (kbuchegg)]

> (schätze mal der Watchdog greift dort ein)..

Was heißt 'schätze mal'.
Du bist der Programmierer! Das musst du WISSEN, nicht schätzen.

[Matthias L. (lindner8712)]

Das mit der zählenden variable ist auch eine Lösung. Werd ich mal 
versuchen. Danke dafür

wegen dem Interrupt; Interrupts sollen kurzgehalten werden, damit das 
Hauptprogramm nicht "verhungert" soweit mein Schulwissen. Da ich jedoch 
ab und zu wirre Zeichen auf dem Display hatte, wenn ein Interrupt 
während der Display aktualisierung eintrat. hab ich mir weiter nichts 
dabei gedacht. Es ist ja auch keine Zeitkritische Sache dabei.

Jetzt habe ich es mit einer zählenden Flag gelöst und während der 
Abarbeitung sind alle Interrupts gesperrt!!!

[Matthias L. (lindner8712)]

Karl Heinz Buchegger schrieb:
>> (schätze mal der Watchdog greift dort ein)..
>
> Was heißt 'schätze mal'.
> Du bist der Programmierer! Das musst du WISSEN, nicht schätzen.

Leider kann ich nicht in den Schwarzen Käfer hineingucken da ich kein 
JTAG o.ä. habe. es war auch nicht der Watchdog sondern das Programm ist 
beim Rücksprung aus dem Interrupt wieder zum Beginn der int main(void) 
Methode
gehüpft. warum muss ich nochmal nachforschen. leider fällt ja simulieren 
bei der LCD Library auch flach!

[Georg G. (df2au)]

Matthias Lindner schrieb:
> Da ich jedoch
> ab und zu wirre Zeichen auf dem Display hatte, wenn ein Interrupt
> während der Display aktualisierung eintrat.

Das sollt dir zu denken geben. Da fummelt ein Interrupt an Dingen, von 
denen er die Finger lassen soll. Falls das aber unumgänglich ist, kann 
man immer noch den kritischen Teil (meist nur ein, zwei Statements) in 
der main() durch "atomic region" schützen.

[Matthias L. (lindner8712)]

Also,

jetzt läuft der Controller seit fast 15 Minuten ohne Fehler bzw. 
"abstruz". Es war doch die sinnlose Idee mit dem NE555.

Danke für eure Hilfe!!!

Viele Grüße aus der Oberpfalz

Matthias