ISR macht mucken

[Joachim .. (joachim_01)]

Moin,
ich mach hiern bisschen Spielerei, hab nen alten 6522 aus meiner 
Jugendzeit an nen ATMega 1284P angehängt der einwandfrei läuft. 
Knuffiges Teilchen.

Über ISR(INT2_vect) kommt nen Interrupt rein. Dort wird ein Bit für 
Zähler++ im Hauptprogramm (Ausgabe auf ein Touch-Display) gesetzt das 
zyklisch in main aufgerufen werden soll. Gleichzeitig wird in der ISR 
ein 16bit-Zähler im 6522 neu justiert. Da ich aber die ISR nicht noch 
größer machen will hab ich das Unwichtige ausgelagert und setze nur ein 
Erkennungsbit.

Seitdem ich das Hauptprogramm  schneller gemacht habe kommt das Bit 
nicht mehr durch. Vorher funktionierte das, auch ohne 
'volatile'-Deklarierung (die ich ohnehin noch nie so ganz verstanden 
hab', was hier aber nicht das Thema ist). Ich benutze noch den Timer 0 
Interrupt, aber selbst den abzuhängen ändert gar nichts.
Irgendne Idee?

C-Code

 ISR(INT2_vect) {
  DDRD = 0xFF; //Data out
  PORTC = VIA_CHIP_SEL + VIA_T2C_L * 4;
  VIA_WRITE();
  PORTD = 0x9;      
  _delay_us(20); //settle down

  PORTC = VIA_CHIP_SEL + VIA_T2C_H * 4;
  VIA_WRITE();
  PORTD = 0x0;  
  _delay_us(20); //settle down
  DDRD = 0x0; //Data in for next read cycle
  IRQflag6522 = 1;  // <- kommt in Hauptprogramm nicht an. Zeitkritisch?  

}

im Moment ruft main nur: 

while (1) {  
read6522Register2();
}


/************************************************************************
 *
 * read6522Register2: 6522 register dump
 * blank = xx bewirkt austasten (blinken) des zu editierenden Inhalts
 *
 ************************************************************************/
void read6522Register2 (void) {
  unsigned int  T2 = 0; 
  static uint16_t irq6522 = 0;
  
  static int8_t count1 = 0;  //blink 5x
  static int8_t count2 = 1;  //15 items
  static  unsigned long old = 0;
  
  
  //Timer ISR, calculate a nick of time
  if ((eternal - old) == 1)  {
                count1++;
  }  
  old = eternal;  
  
  if (count1 == (2*5)) {
            count1 = 0;
            count2++;
  }          
        
  if (blink == 1)  {            
            blank = count2;
  }            
  else  blank = 0;   
  if (count2 > 15) count2 = 1;
  

  regStatus = read6522 (VIA_IOR_A);  
  convDecToHex (255-regStatus); 
  if (blank == 1 ) SendAscii(Touch160x104, 4* FONTWIDTH , 1*FONTHEIGHT,"  ");
  else        SendAscii(Touch160x104, 4* FONTWIDTH , 1*FONTHEIGHT, buf2);
  
.
.
.
  
  regStatus = read6522 (VIA_T2C_H);
  T2 = 65535 - (256 * regStatus + T2) ;
  convDecToHex (regStatus);
  if (blank == 14) SendAscii(Touch160x104, 8*FONTWIDTH , 7*FONTHEIGHT, "  ");
  else        SendAscii(Touch160x104, 8*FONTWIDTH , 7*FONTHEIGHT, buf2);
  regStatus = read6522 (VIA_T2C_L);
  T2 = regStatus;
  convDecToHex (regStatus);
  if (blank == 15) SendAscii(Touch160x104, 10*FONTWIDTH +3, 7*FONTHEIGHT , "  ");
  else        SendAscii(Touch160x104, 10*FONTWIDTH +3, 7*FONTHEIGHT , buf2);


//check for interrupts ...funktioniert nicht
   if (IRQflag6522) {
     sprintf( buf1, "IRQs: %i", ++irq6522);  //
     SendAscii(Touch160x104, 0, 8*FONTHEIGHT, buf1);
    IRQflag6522 = 0;  //release
  }

[Walter S. (avatar)]

Joachim ... schrieb:
> Vorher funktionierte das, auch ohne
> 'volatile'-Deklarierung

Zufall!
volatile muss sein

[Martin K. (maart)]

Wo wird denn die globale Interruptfreigabe gemacht?

[Joachim .. (joachim_01)]

>Wo wird denn die globale Interruptfreigabe gemacht?

Vorm Aufruf. Wie gesagt, der Interrupt ist nicht das Problem, der kommt 
ja - ich seh's an der Aktualisierung des Counters im 6522. Lediglich das 
Weiterreichen von IRQflag6522 funktioniert nicht. Ich hab mindestens 
drei mal den Code danach abgesucht ob das der Zustand von IRQflag6522 
irgendwo beeinflusst werden könnte. Hab nix gefunden.

[holger (Gast)]

Einen Chip in der ISR und in der main()
zu beackern ist ne ziemlich bescheuerte Idee.

[Joachim .. (joachim_01)]

Wieso? Wie willst'n zeitkritische Probleme außer in nem Nebenprogramm 
handhaben? Ich hab den Code zum debuggen stark vereinfacht, deswegen das 
aufrufen von main aus.

[Joachim .. (joachim_01)]

Hardware-Problem. Grrrr!

Alles klar jetz.

[... (Gast)]

Joachim ... schrieb:
> Hardware-Problem. Grrrr!

Was wars denn?

[Karl H. (kbuchegg)]

Joachim ... schrieb:
> Wieso? Wie willst'n zeitkritische Probleme

gerade weil es zeitkritisch ist, gehört es in die ISR

Aber solange in deiner ISR ein
   _delay_us(20); //settle down
rumlungert, brauchen wir uns gar nicht länger weiter unterhalten.

zeitkritisch und _delay passen nicht zusammen.