ATmega8 - der Aufruf der ISR daurt sehr lange

[Thomas B. (dertom83)]

Hallo zusammen,
mir kommt gerade bei der Programmierung eines ATmega8 etwas spanisch 
vor.
Eingestellt ist er auf 8MHz.
Das beduetet ja, dass ein Prozessortakt 125ns dauert.
Ich habe nun folgendes programmiert und mit nem Osca gemessen:

int main(void)
{
 while(1){
 PORTB ^=(1 << PB1);
 }
}

Das bit ist laut Messung je 615ns gesetzt und 615ns zurückgesetzt - 
alles ok.

Änder ich jetzt die Programmierung ab und lasse in einer ISR vom Timer0 
überlauf den Ausgang togglen, dauert das ganze 5µs
Ich finde das steht nicht im verhältnis. Warum dauert der ISR aufruf so 
lange?

int main(void)
{  
//TIMER0 initialisieren
 TCCR0= (0<<CS02)|0<<CS01|(1<<CS00);  // Start Timer 0 OHNE Prescaler              
 TCNT0  = 255;        // Vorladen
 TIMSK |= (1<<TOIE0);      // Interrupts aktivieren
 sei();          // Das I-bit im SREG Register setzen
  
//Endlosschleife
 while(1){
 }
}

ISR(TIMER0_OVF_vect)
{
 PORTB ^=(1 << PB1);
 TCNT0  = 255;
 }

Vor jahren habe ich mal mit nem PIC und Assamlber programmiert - nun ist 
es ein ATMEL mit c...
Ich könnte mir daher vorstellen, dass ich den Timer oder die ISR falsch 
aufgerufen habe - könnt ihr mir einen Tip geben?
Vielen Dank schonmal.

[Peter II (Gast)]

Thomas Borsdorf schrieb:
> Warum dauert der ISR aufruf so
> lange?

schau dir den ASM code an! Da wird schon noch etwas mehr gemacht.

Dann wird nach jedem return aus einer ISR auch noch mindestens 1 asm 
Befehl ausgführt bevor es wider in eine ISR geht.

[Karl H. (kbuchegg)]

Thomas Borsdorf schrieb:

> Änder ich jetzt die Programmierung ab und lasse in einer ISR vom
> Timer0 überlauf den Ausgang togglen, dauert das ganze 5µs

Wie vertrauenswürdig sind diese 5µs? Sind das 5.000µs?

5µs wären 40 Takzyklen. Ist in der Tat ein wenig viel.

Das LSS-File schon mal angesehen?

[Karl H. (kbuchegg)]

Thomas Borsdorf schrieb:

> Eingestellt ist er auf 8MHz.

interner Takt?
Dann sind diese 8Mhz auch nicht besonders vertrauenswürdig.

> Das bit ist laut Messung je 615ns gesetzt und 615ns zurückgesetzt -
> alles ok.

Da 615 nicht durch 125 teilbar ist, ist das schon mal ein Hinweis, dass 
die 8Mhz wohl daneben sein werden. Du solltest mal von diesem Test das 
Assembler LSS File ansehen und dort die Takte zählen, die die Schleife 
wirklich braucht. Aus den gemessenen 615ns und der Anzahl der Takte 
kannst du dir dann die echte Taktzykluszeit ausrechnen.

[uwe (Gast)]

Laut meiner berechnung sollte es sogar 31,875µs Dauern.

[Glania (Gast)]

uwe schrieb:
> Laut meiner berechnung sollte es sogar 31,875µs Dauern.

Bitte orrechnen.

[Ralf G. (ralg)]

Karl Heinz schrieb:
> 5µs wären 40 Takzyklen. Ist in der Tat ein wenig viel.

Die ISR ist genau 20 Instruktionen lang. Das ergibt hier 40 Taktzyklen.

uwe schrieb:
> Laut meiner berechnung sollte es sogar 31,875µs Dauern.
siehe:
Thomas Borsdorf schrieb:
> TCNT0  = 255;

[Thomas B. (dertom83)]

Erstmal vorweg: im Anfangsbeitrag sind es 625ns nicht 615ns - 
Tippfehler.

Ralf G. schrieb:
> Karl Heinz schrieb:
>> 5µs wären 40 Takzyklen. Ist in der Tat ein wenig viel.
>
> Die ISR ist genau 20 Instruktionen lang. Das ergibt hier 40 Taktzyklen.

Das klingt doch schonmal nach einer Erklärung.

Gibt es auch eine Lösung, oder sind alle ISR Aufrufe so "Langsam"
Würde es Sinn machen auf Assambler umzusteigen?
Im anhang die Screenshotas der Messung.

[uwe (Gast)]

>TCNT0  = 255;
Ah hab das hier übersehen, jetzt verstehe ich was du erreichen willst, 
du willst einen Overflow sofort nach dem beedigen des Interupthandlers.
Aber der sichert jetzt erst mal das Statusregister zurück, und die 
Register vom Stack und dann springt er zurück in die main. Danach führt 
er einen weiteren Befehl aus von der main und springt wieder in den 
Handler sichert die Statusflags und packt Register auf den Stack. 
Wieviele Register packt er denn auf den Stack und holt sie auch wieder 
runter?
-also der sprung in den interupt sind  2 Takte.
-laden des statusflags in ein Register 1 Takt.
-speichern des registers auf dem Stack 2 Takte.
-speichern der restlichen Register n x 2 Takte.
-Portb1 invertieren                    1 Takt.
-counter auf 255 setzen                1 Takt.
-laden der gesichtern register     n x 2 Takte. (hier ist der Counter 
schon wieder übergelaufen)
-laden des registers mit den Flags     2 Takte.
-speichern der flags im Statusregister 1 Takt.
-Rücksprung zu main                    2 takte.
-hier wird mindestens 1 Befehl abgearbeitet 1 Takt (obwohl Overflow 
gesetzt)
-wieder nach oben
Macht wenn ich von zwei Registern ausgehe 21 Takte.
macht 2,625µs an und 2,625µs aus zusammen 5,25µs.

[Karl H. (kbuchegg)]

Ralf G. schrieb:
> Karl Heinz schrieb:
>> 5µs wären 40 Takzyklen. Ist in der Tat ein wenig viel.
>
> Die ISR ist genau 20 Instruktionen lang. Das ergibt hier 40 Taktzyklen.

Tatsächlich.

  5e:  1f 92         push  r1
  60:  0f 92         push  r0
  62:  0f b6         in  r0, 0x3f  ; 63
  64:  0f 92         push  r0
  66:  11 24         eor  r1, r1
  68:  8f 93         push  r24
  6a:  9f 93         push  r25

  6c:  88 b3         in  r24, 0x18  ; 24
  6e:  92 e0         ldi  r25, 0x02  ; 2
  70:  89 27         eor  r24, r25
  72:  88 bb         out  0x18, r24  ; 24
  74:  8f ef         ldi  r24, 0xFF  ; 255
  76:  82 bf         out  0x32, r24  ; 50

  78:  9f 91         pop  r25
  7a:  8f 91         pop  r24
  7c:  0f 90         pop  r0
  7e:  0f be         out  0x3f, r0  ; 63
  80:  0f 90         pop  r0
  82:  1f 90         pop  r1
  84:  18 95         reti

war mir so noch gar nicht bewusst, dass für Präambel und Postambel schon 
14 Befehle draufgehen.

[Peter II (Gast)]

Thomas Borsdorf schrieb:
> Gibt es auch eine Lösung, oder sind alle ISR Aufrufe so "Langsam"
man könnte die Funktion als naked deklarieren, dann geht es schneller. 
Das kann man aber nur machen, Arbeitsregister in der ISR ändert. In 
diesem Fall sollte es gehen, in der Praxis meist nicht.

> Würde es Sinn machen auf Assambler umzusteigen?
ja, aber spätestens wenn der code etwas mehr machen soll, wird es 
genauso langsam. Denn da musst du auch die Register sichern und 
widerherstellen.

[Karl H. (kbuchegg)]

Thomas Borsdorf schrieb:

> Gibt es auch eine Lösung, oder sind alle ISR Aufrufe so "Langsam"

Mein Gedächtnis kramt da noch was raus, dass man ISR auch 'naked' machen 
kann. Habs aber noch nie wirklich gebraucht. Denn 5µs sind ja nicht 
wirklich langsam. Wann hat man schon mal den Fall, dass man Interrupts 
in derart kurzen Abständen braucht?

> Würde es Sinn machen auf Assambler umzusteigen?

Wenn du den Speed brauchst.
Brauchst du den wirklich?

[Peter II (Gast)]

Karl Heinz schrieb:
> war mir so noch gar nicht bewusst, dass für Präambel und Postambel schon
> 14 Befehle draufgehen.

ein schönes Beispiel für Leute die immer behaupten, der Compiler macht 
es schon optimal.

Hier geht es sehr großzügig mit Registern um, ein Register hätte 
gereicht.

[ich (Gast)]

Hi, ist denn die ISR schon fertig bevor der Timer überläuft? (Weil es 
müssen ja noch register zurück geschrieben werden?)
MfG
ich

[ich (Gast)]

So, jetzt ziehe ich meine Frage zurück.
MfG
ich

[Karl H. (kbuchegg)]

Peter II schrieb:
> Karl Heinz schrieb:
>> war mir so noch gar nicht bewusst, dass für Präambel und Postambel schon
>> 14 Befehle draufgehen.
>
> ein schönes Beispiel für Leute die immer behaupten, der Compiler macht
> es schon optimal.

:-)
Seitenhieb akzeptiert.

> Hier geht es sehr großzügig mit Registern um, ein Register hätte
> gereicht.

Jep. Ist halt die einfache allgemeine ISR Präambel. Wundert mich 
eigentlich, dass da einiges nicht wegoptimiert wird. Ich hatte das 
eigentlich anders in Erinnerung. Zumindest das r1 überhaupt nicht 
verändert wird (*), hätte er schon rausfinden können.

* gemeint ist: vom eigentlichen Nutzcode. Der fixe eor r1, r1 in der 
Präambel zählt nicht.

[uwe (Gast)]

> Würde es Sinn machen auf Assambler umzusteigen?
Output compare Einheit verwenden, die macht das togglen ohne Interupt.
Ansonsten wenns nen anderer Pin als OC0 sein muß, dann Output Compare 
Interupt. Wenn du dann nichts im interupt machst brauchst du auch nicht 
Statusregister und andere auf den Stack legen.
-also der sprung in den interupt sind  2 Takte.
-Pin Togeln                            1 Takt
-Rücksprung zu main                    2 Takte.
-hier wird mindestens 1 Befehl abgearbeitet 1 Takt (obwohl Overflow
gesetzt)
-wieder nach oben
Sind dann 6 Takte

[c-hater (Gast)]

uwe schrieb:

> -also der sprung in den interupt sind  2 Takte.
> -laden des statusflags in ein Register 1 Takt.
> -speichern des registers auf dem Stack 2 Takte.
> -speichern der restlichen Register n x 2 Takte.
> -Portb1 invertieren                    1 Takt.
> -counter auf 255 setzen                1 Takt.
> -laden der gesichtern register     n x 2 Takte. (hier ist der Counter
> schon wieder übergelaufen)
> -laden des registers mit den Flags     2 Takte.
> -speichern der flags im Statusregister 1 Takt.
> -Rücksprung zu main                    2 takte.
> -hier wird mindestens 1 Befehl abgearbeitet 1 Takt (obwohl Overflow
> gesetzt)

Da fehlt ganz zu Anfang noch was, nämlich die statische Interruptlatenz 
von 4 Takten. Die werden gebraucht, um die Rücksprungadresse auf den 
Stack zu legen.

[Thomas B. (dertom83)]

Super, danke für die Erklärung, jetzt wird es mir auch klar.

Karl Heinz schrieb:
> Wenn du den Speed brauchst.
> Brauchst du den wirklich?

Gute Frage - ich lese ein Protokol aus und möchte keine Information 
verlieren.

Dachte mir ursprünglich, dass es einfacher den Timer einfach hoch zu 
stellen.
Jetzt werde ich wohl umdenken und mich mit int0/int1 bechäftigen - beim 
PIC war das immer so Aufwendig -.-
Mal schauen wie es mit nem Atmel läuft.

Danke nochmal für die Hilfe und Infos.

[Dr. Sommer (Gast)]

Für zeitkritische Aufgaben gibt es daher Controller wie den Cortex-M3, 
der generell höhere Taktfrequenzen erreicht, und einen Interrupt in 12 
Takten aufruft (inklusive der Sicherung von 4 Registern + 
Status-Register), und bei aufeinanderfolgenden Interrupts das 
Wiederherstellen-Sichern wegfallen lässt.

[uwe (Gast)]

Output compare Einheit verwenden, die macht das togglen ohne Interupt.