"Burst" mit atmega328 erzeugen

[MacFly (Gast)]

Servus,

ich habe ein Programmierbroblem bei dem ihr mir vielleicht helfen könnt 
den Fehler zu finden.
Ich möchte mit einem atmega328 einen "Burst" erzeugen. Als Hardware habe 
ich einen Arduino nano Klon.

Ich habe mir das so gedacht, dass ich Timer2 benutzen kann mit fast PWM 
generierung mit ocr2a als top Wert.

* Der ist zuerst auf 0, damit der Timer sozusagen auf 0 festgetackert 
ist.
* In ocr2b kommt die gewünschte Breite, also halbe Frequenz des burst. 
Bei compare match soll der Ausgang dann gsetzt werden.
* Wenn der Burst starten soll schreibe ich in ocr2a den doppelten Wert 
von ocr2b, damit die Schwingung symmetrisch ist.
* In dem COMPB Interrupt zähle ich die Halbwellen mit und setzte nach 
der Breite des bursts ocr2a wieder auf 0 zum anhalten.

#define WIDTH                      5
#define TOP_COUNT                  2*WIDTH
#define BURST_LENGTH               2
#define BURST_TRIGGER()            do{  OCR2A = TOP_COUNT; } while(0) //wird am Anfang Probleme machen je nach Triggerzeit

volatile uint8_t burst = BURST_LENGTH;

static void InitBurst(void)
{
  TCCR2B  = 0; //stop
  TCNT2   = 0;
  OCR2A   = 0; //zuerst blockieren
  OCR2B   = WIDTH;
  TCCR2A  = _BV(COM2B0) | _BV(COM2B1) | _BV(WGM20)| _BV(WGM21) ; //set on match, Fast PWM, clear bot, top ocra
  TCCR2B  = _BV(WGM22) | _BV(CS20);
  DDRD    = _BV(3);
  TIMSK2 |= (1 << OCIE2B); //Compare ch B
  sei();
}


//TIMER2_OVF_vect
//TIMER2_COMPB_vect
ISR(TIMER2_COMPB_vect)
{
  if(--burst == 0)
  {
    OCR2A = 0; //wieder blockieren
    burst = BURST_LENGTH;
  }
}


void setup() 
{
  InitBurst();
}

void loop() {
  delay(10);

  BURST_TRIGGER();
}

Funktioniert aber leider nicht so ganz. Wenn ich BURST_LENGTH = 1 setze, 
kommen 3 Schwingungen raus, bei BURST_LENGTH = 2 ebenfalls und bei 
BURST_LENGTH = 3 sind es derer 7.
Ich erkenne an dem Fehlerbild gar nichts. Möglicherweise hat es etwas 
mit dem Interrupt und einer zu naiven Vorstellung davon zu tun?

Über sachdienliche Hinweise bin ich sehr froh :-)

[MacFly-Nachtrag (Gast)]

P.S.

ach so: wenn ich das Datenblatt richtig verstehe wird der Wert für ocr2a 
aktualisiert wenn der Timer auf Bottom steht, also wenn er gerade wieder 
genullt wurde. Wenn ich im Compare match von ocr2b den Wert für ocr2a 
ändere, gilt der alte bis zum Umbruch, oder?

[Peter D. (peda)]

MacFly schrieb:
> Wenn ich BURST_LENGTH = 1 setze

Ohne Prescaler hat die CPU schlichtweg keine Zeit, Befehle auszuführen. 
Schon ein leerer Interrupt dauert 10 Zyklen.

[MacFly-Nachtrag (Gast)]

Ahhhh mir fehlt gerade der emoji für den facepalm :-)
Zu simpel um darauf zu kommen offenbar.

Welche Zeit ich einhalten könnte ist aber schwierig abzuschätzen denke 
ich, weil der avr hat ja keine Prioritäten bei den Interrupts und könnte 
durch etwas längeres lahmgelegt sein?

Ich wollte mit der oben gezeigten Art etwas rumspielen, das erschien mir 
elegant. Wäre es da für die Praxis sinnvoller einen Timerinterrupt zu 
nutzen und den Ausgangspin einfach zu Fuß zu toggeln?

[Falk B. (falk)]

MacFly-Nachtrag schrieb:
> Ich wollte mit der oben gezeigten Art etwas rumspielen, das erschien mir
> elegant. Wäre es da für die Praxis sinnvoller einen Timerinterrupt zu
> nutzen und den Ausgangspin einfach zu Fuß zu toggeln?

Kann man machen, muss man nicht. So oder so muss man die Anzahl der 
Pulse per CPU und Interrupt zählen und verwalten. Dabei kann man 
nicht beliebig schnell werden, sprich, die Periodendauer eines Pulses 
muss einen Mindestwert von ??? Takten haben, in deinem Programm WIDTH. 
Wenn man maximale Geschwindigkeit haben will/braucht, muss man die ISRs 
in Assembler schreiben. Ich würde reinen Assembler in einer .S Datei 
nehmen, Hardcore-Freaks Inline-ASM ;-)

[Peter D. (peda)]

Für kleine Timerwerte sollte der Prescaler >=64 sein. Dann bleibt noch 
etwas Zeit für die Mainloop.

Der AVR führt zwischen 2 Interrupts mindestens einen Befehl der Mainloop 
aus.
Im Gegensatz dazu der ARM, der läßt die Mainloop komplett verhungern.

[Oliver S. (oliverso)]

Wenn es nicht unbedingt ein 328p sein muß, nimm einen AVR, der einen 
Output Modulator hat, z.B. den Mega2560. Damit geht  das einfacher, auch 
bei hohen Taktraten.

Oliver

[my2ct (Gast)]

Oliver S. schrieb:
> ... nimm einen AVR, der einen Output Modulator hat, z.B. den Mega2560

Wenn es doch ein ATmega328 sein soll ...
Man könnte auch ein FPGA nehmen, ist hier aber nicht das Thema.

MacFly schrieb:
> Ich möchte mit einem atmega328

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

Deswegen werden zeitkritische Operationen in Assembler geschrieben, so 
daß man wirklich genau weiß, was der Prozessor macht. Ansonsten braucht 
man sofort einen vielfach schnelleren Prozessor.

Edit:
Der Code ist auch mal wieder nicht vollständig. Dazu noch verschiedene 
Stile in einem Listing ("InitBurst();" und "BURST_TRIGGER();"), dazu 
noch so viel Caps... neee neee neee nee ne!

[Veit D. (devil-elec)]

Hallo,

der Code ist schon vollständig, nur mit dem define ein absolut blöder 
Syntax.  Eine Funktion mit #define, dass geht gar nicht. Alle defines 
Variablen hier kann man mit eindeutigen Datentypen definieren.

Wir reden hier vom Timer Mode 7 "Fast PWM" mit TOP = OCR2A.
OCR2A = 0; ist nicht blockieren.
Das sorgt jedoch für falsche Timereinstellung und der Timer spielt 
verrückt, wenn COMPARE größer TOP ist. COMPARE darf nie größer TOP sein. 
Wenn die Frequenz konstant bleiben soll muss man TOP nie ändern und 
sollte ihn nie ändern. Den Timer schaltet man ab indem man die Prescaler 
Bits auf 0 setzt.

In dem Fall hier benötigt man einen Zähler der die ausgegebenen Takte 
zählt. Das geht nicht mit beliebig hoher Frequenz. Selbst wenn man 
extern einen Schieberegister als Zähler an einen Interrupt anklemmt, 
muss der Controller "genügend" Zeit zum reagieren haben.

Wenn die Frequenz wirklich so extrem hoch sein soll, dann ist das der 
falsche Controller dafür. Habe es noch nicht probiert, aber ein 
Controller mit CCL und Eventsystem könnte das vielleicht. Ein zweiter 
Timer zählt die Pulse und schaltet mit mittels CCL den Takt nach außen 
ab. Wenn man denn bei AVR bleiben möchte wäre das vielleicht mit einem 
AVR DA/DB möglich.

Ansonsten Frequenz runter. Richtwert erstmal unter 100kHz.

[MacFly (Gast)]

Guten Morgen und danke für die Antworten!

Glaube das Problem ist gelöst. Der Formalismus kam bei den letzten Posts 
ja etwas nach oben, daher erlaube ich mir mal nach zu fragen.

>Das sorgt jedoch für falsche Timereinstellung und der Timer spielt
>verrückt, wenn COMPARE größer TOP ist. COMPARE darf nie größer TOP sein.

Das habe ich ehrlich gesagt bei studium des Datenblattes nicht bemerkt. 
Für mich generiert in dem Modus der ocra einen Reset des Timers und der 
ocrb den Vergkleichswert. Wenn ocra kleiner als ocrb ist zieht der 
compare Wert halt den kürzeren. Also so habe ich das interpretiert; bist 
du dir da sicher dass nicht nicht sein darf? Manchmal ist ja ein 
Nebensatz entscheidend.


>Edit:
>Der Code ist auch mal wieder nicht vollständig. Dazu noch verschiedene
>Stile in einem Listing ("InitBurst();" und "BURST_TRIGGER();"), dazu
>noch so viel Caps... neee neee neee nee ne!

Ich habe mir angewöhnt, Funktionen als "DasIstMeineFunktion" zu 
schreiben und Variablen in "meine_variable", sowie #defines groß. Da 
behalte ich den besten Überblick.  Was spräche denn da generell gegen? 
(Außer dass man sofern man Arduino library zusätzlich benutzt dabei mixt 
- die Nano sind aber angenehm, weil man die direkt aus dem Editor 
flashen kann, kein Netzteil braucht etc)

>Eine Funktion mit #define, dass geht gar nicht.

Das ist doch an sich nur eine lesbare Abkürzung um das Register zu 
setzen.

[Oliver S. (oliverso)]

MacFly schrieb:
>>Das sorgt jedoch für falsche Timereinstellung und der Timer spielt
>>verrückt, wenn COMPARE größer TOP ist. COMPARE darf nie größer TOP sein.
>
> Das habe ich ehrlich gesagt bei studium des Datenblattes nicht bemerkt.

Was daran liegt, daß das da auch nicht drin steht. Wenn compare größer 
Top ist, passiert genau das, was man erwartet, nämlich gar nichts. Es 
gibt halt keinen compare Match, das war’s.

Im O-Text:
„ When changing the TOP value the program must ensure that the new TOP 
value is higher or equal to the value of all of the Compare Registers. 
If the TOP value is lower than any of the Compare Registers, a compare 
match will never occur between the TCNTn and the OCRnx. “

Oliver

[Falk B. (falk)]

MacFly schrieb:

>>Das sorgt jedoch für falsche Timereinstellung und der Timer spielt
>>verrückt, wenn COMPARE größer TOP ist. COMPARE darf nie größer TOP sein.
>
> Das habe ich ehrlich gesagt bei studium des Datenblattes nicht bemerkt.
> Für mich generiert in dem Modus der ocra einen Reset des Timers und der
> ocrb den Vergkleichswert. Wenn ocra kleiner als ocrb ist zieht der
> compare Wert halt den kürzeren.

Das ist auch so.

> Also so habe ich das interpretiert; bist
> du dir da sicher dass nicht nicht sein darf?

Doch, das darf so sein, es passiert dann halt nix.

>>Der Code ist auch mal wieder nicht vollständig. Dazu noch verschiedene
>>Stile in einem Listing ("InitBurst();" und "BURST_TRIGGER();"), dazu
>>noch so viel Caps... neee neee neee nee ne!
>
> Ich habe mir angewöhnt, Funktionen als "DasIstMeineFunktion" zu

AKA CamelCase, sprich ein Großbuchstabe am Wortanfang, keine 
Unterstriche.

> schreiben und Variablen in "meine_variable",

Das ist die Schreibweise mit Unterstrich.

> sowie #defines groß. Da
> behalte ich den besten Überblick.  Was spräche denn da generell gegen?

Gar nichts, das sind gängige, akzeptierte Schreibweisen.

>>Eine Funktion mit #define, dass geht gar nicht.
>
> Das ist doch an sich nur eine lesbare Abkürzung um das Register zu
> setzen.

Eben, Macros als kompakte (Inline)Funktionen sind üblich, wenn gleich 
man das diskutieren kann.

[Oliver S. (oliverso)]

Falk B. schrieb:
> Eben, Macros als kompakte (Inline)Funktionen sind üblich, wenn gleich
> man das diskutieren kann.

In wenigen Super-Sonder-Spezialfällen ist das hilfreich. Ansonsten 
stammt das aus einer Zeit, als man hoffte, daß solche 
Define-Maros-Funktionen schnelleren Code erzeugen würden . Die Zeiten 
sind aber lange vorbei. Funktionen sind ein (durchaus elementarer) 
Bestandteil der Sprache C(++), und ja, man darf die tatsächlich ohne 
Nachteile auch benutzen. Der Compiler kriegt das mit den "kompakten 
inline-Funktionen" schon hin.

Oliver

[Falk B. (falk)]

Ich hab das auch mal probiert, siehe Anhang. Einmal mit ISR in C, einmal 
ISR in handpoliertem Assembler. In C braucht es 24 Takte bis zum 
Ausschalten des Timers, in ASM 15.

ISR vom C-Compiler, am rechten Rand die CPU Takte/Befehl

ISR(TIMER2_COMPB_vect) {            ; 5
 678:  1f 92         push  r1        ; 2
 67a:  0f 92         push  r0        ; 2
 67c:  0f b6         in  r0, 0x3f  ; 63  ; 1
 67e:  0f 92         push  r0        ; 2
 680:  11 24         eor  r1, r1        ; 1
 682:  8f 93         push  r24        ; 2

  if (--burst == 0) {
 684:  80 91 21 02   lds  r24, 0x0221      ; 2
 688:  81 50         subi  r24, 0x01    ; 1
 68a:  80 93 21 02   sts  0x0221, r24      ; 2
 68e:  81 11         cpse  r24, r1      ; 2
 690:  02 c0         rjmp  .+4        ; 0x696 <__vector_14+0x1e>
    TCCR2B  = 0;   // Timer 2 STOP
 692:  10 92 b1 00   sts  0x00B1, r1      ; 2 , 24 Takte von ISR Anfang bis hier her
  }
}
 696:  8f 91         pop  r24
 698:  0f 90         pop  r0
 69a:  0f be         out  0x3f, r0  ; 63
 69c:  0f 90         pop  r0
 69e:  1f 90         pop  r1
 6a0:  18 95         reti

handgeklöppelte Assembler-ISR

                                    ; Takte
TIMER2_COMPB_vect:                  ; 5, ISR call
  push  r16                          ; 2
  push  r17                          ; 2
  in    r17, _SFR_IO_ADDR(SREG)      ; 1, save SREG
    
  lds    r16, burst                  ; 2
  dec    r16                          ; 1
  brne  TIMER2_COMPB_vect_not_done  ; 1
  sts    TCCR2B, r16                  ; 2, 16 Takte vom ISR Start bis hier her
                                    ; r16 is now zero, stop timer 2
TIMER2_COMPB_vect_not_done:      
  sts    burst, r16                  ; 2

  out    _SFR_IO_ADDR(SREG), r17      ; 1
  pop    r17                          ; 2
  pop    r16                          ; 2
  reti                              ; 5

Es braucht mindestens diese Anzahl Takte vom Ende des Pulses bis zum 
Ende der Periode des zählers, damit die CPU diesen vor der nächsten 
Periode abschalten kann. Real braucht es ca. 5 Takte mehr, warum auch 
immer. Ich hab noch 5 Takte Panikreserve draufgepackt ;-) Ebenso dürfen 
dabei keine anderen Interrupts aktiv sein, denn die können das Timing 
zum Abschalten versauen.

Siehe Anhang.

Wenn man minimal externe Hardware einsetzen will, nimmt man ein 
AND-Gatter und verknüpft die OCx zweier Timer, z.B. Timer 2 und 1. Timer 
2 macht dabei das Pulssignal, wie hier schon gezeigt. Timer 2 
konfiguriert man so, daß damit die Torzeit für den Burst erzeugt wird, 
also N*Periode. Am Ende müssen aber auch dort wieder ausreichend Takte 
übrig bleiben, bis die neue Periode von Timer 1 beginnt, damit die CPU 
diesen stoppen kann. Aber da ist man DEUTLICH flexibler, denn man kann 
Timer 1 ja passend einstellen, die Periodendauer ist nahezu frei 
wählbar, dazu kommt der Prescaler.

[Veit D. (devil-elec)]

Hallo,

wie bekommt man den Assemblerteil in den C Code? Bzw. wie inkludiert man 
die isr.S ?

[MacFly (Gast)]

Danke für die Info, Falk.

Ich mache das ja aus Vergnügen, da freue ich mich evtl. über Ostern 
etwas zum frickeln zu haben.

[Falk B. (falk)]

Veit D. schrieb:
> Hallo,
>
> wie bekommt man den Assemblerteil in den C Code?

Gar nicht, deswegen ist es ja eine eigene Datei.

>Bzw. wie inkludiert man
> die isr.S ?

Man muss sie nur im Projektbaum einbinden, wie jede andere Quelldatei. 
Sowohl das alte AVR-Studio als auch das hippe Microchip Studio erkennen 
Assemblerdateien und assemblieren und linken sie, ganz so wie C-Dateien.
Auch die Arduino-IDE macht das automatisch. Irgendwie clever, was? ;-)

[Dieter R. (drei)]

Falk B. schrieb:
> handgeklöppelte Assembler-ISR

Ginge es nicht noch etwas kürzer, wenn man eines der GPIOR-Register 
verwendet?

[Falk B. (falk)]

Dieter R. schrieb:
> Ginge es nicht noch etwas kürzer, wenn man eines der GPIOR-Register
> verwendet?

Was soll da kürzer werden?

[Dieter R. (drei)]

out gpior1, r16
in r16, sreg
out gpior2, r16

2 Zyklen weniger. Bin mir unsicher, nicht getestet, scheint mir aber 
richtig.

[Peter D. (peda)]

Falk B. schrieb:
> Real braucht es ca. 5 Takte mehr, warum auch
> immer.

Erstmal muß der laufende Befehl (1..4) beendet werden, dann der PC 
gepusht und die IV-Table angesprungen (4) und dann der rjmp zum Handler 
(2).
Bei den großen AVRs mit 3 Byte PC nochmal 3 Zyklen mehr.

[Falk B. (falk)]

Peter D. schrieb:
> Erstmal muß der laufende Befehl (1..4) beendet werden, dann der PC
> gepusht und die IV-Table angesprungen (4) und dann der rjmp zum Handler
> (2).

Schon klar, aber der push des PC + Jump dauern beim Mega laut Datenblatt 
5 Takte. Deine extra 2 Takte werden nicht benötigt.

> Bei den großen AVRs mit 3 Byte PC nochmal 3 Zyklen mehr.

Das hier ist vom 128er, das 256er Datenblatt hab ich gerade nicht. Dort 
steht 5 statt 4.

"Interrupt Response
Time
The interrupt execution response for all the enabled AVR interrupts is 
four clock cycles minimum. After four clock cycles, the program vector 
address for the actual interrupt handling routine is executed. During 
this 4-clock cycle period, the Program Counter is pushed onto the Stack. 
The vector is normally a jump to the interrupt routine, and this jump 
takes three clock cycles. If
an interrupt occurs during execution of a multi-cycle instruction, this 
instruction is completed before the interrupt is served."

[Oliver S. (oliverso)]

Falk B. schrieb:
> Das hier ist vom 128er, das 256er Datenblatt hab ich gerade nicht. Dort
> steht 5 statt 4.

Der TO hat einen 328p…

Die 3-Byte-PC-AVRs brauchen einen Takt mehr für den Einsprung in die ISR 
(5 statt 4), und ebenfalls einen Takt mehr fürs Reti (Ebenso 5 statt 4), 
weil halt jedes Mal ein Byte mehr gepusht/gepopt werden muß.

Oliver

[Veit D. (devil-elec)]

Falk B. schrieb:
> Veit D. schrieb:
>> Hallo,
>>
>> wie bekommt man den Assemblerteil in den C Code?
>
> Gar nicht, deswegen ist es ja eine eigene Datei.
>
>>Bzw. wie inkludiert man
>> die isr.S ?
>
> Man muss sie nur im Projektbaum einbinden, wie jede andere Quelldatei.
> Sowohl das alte AVR-Studio als auch das hippe Microchip Studio erkennen
> Assemblerdateien und assemblieren und linken sie, ganz so wie C-Dateien.
> Auch die Arduino-IDE macht das automatisch. Irgendwie clever, was? ;-)

Danke schön.

[S. Landolt (Gast)]

Keiner, dem Dieter Rs Idee gefällt? Brächte immerhin 4 Takte.

Etwas aufpoliert:

  out   GPIOR1,r16
  out   GPIOR2,r17
  ...
  ...
  in    r17,GPIOR2
  in    r16,GPIOR1

Oder spricht aus C-Sicht etwas dagegen?

[Falk B. (falk)]

S. Landolt schrieb:
> Keiner, dem Dieter Rs Idee gefällt? Brächte immerhin 4 Takte.

Schweigen heißt zustimmen. Ja, ist ein cleverer Trick.

[Peter D. (peda)]

S. Landolt schrieb:
> Etwas aufpoliert:  out   GPIOR1,r16
>   out   GPIOR2,r17
>   ...
>   ...
>   in    r17,GPIOR2
>   in    r16,GPIOR1

Es geht noch sparsamer. Man reserviert sich einige der 32 Register für 
die Sicherung:

#define saveregs r15:r14
  movw saveregs, r17:r16
  ; interrupt code
  movw r17:r16, saveregs
  reti

[Peter D. (peda)]

Falk B. schrieb:
> Deine extra 2 Takte werden nicht benötigt.

Aber nur wenn die nachfolgen Vektoren nicht benötigt werden. Den Code 
direkt in die Tabelle zu plazieren, ist also die absolute Ausnahme.

[Falk B. (falk)]

Peter D. schrieb:
> Es geht noch sparsamer. Man reserviert sich einige der 32 Register für
> die Sicherung:

Toll, und wie sagst du das dem C-Compiler? Das #define reicht mal sicher 
nicht.

[Falk B. (falk)]

Peter D. schrieb:
>> Deine extra 2 Takte werden nicht benötigt.
>
> Aber nur wenn die nachfolgen Vektoren nicht benötigt werden. Den Code
> direkt in die Tabelle zu plazieren, ist also die absolute Ausnahme.

Davon rede ich gar nicht! In den 4 bzw. 5 Takten ist der Sprung AUS der 
Vektortabelle schon drin! Siehe mein Zitat aus dem Datenblatt!

[S. Landolt (Gast)]

Falk Brunner schrieb:
> Schweigen heißt zustimmen.

Natürlich nicht. Man kann aus Höflichkeit schweigen, oder weil man von 
der Sache zu wenig versteht; weil man es für zu offensichtlich absurd 
hält; oder, auch wenn es jetzt politisch wird, weil man die Folgen des 
Widerspruchs fürchtet.

an Peter Dannegger:
Da die ISR ja in ein C-Programm eingebunden werden soll, die Frage: 
lässt sich über r14,15 frei verfügen?

[Peter D. (peda)]

Falk B. schrieb:
> Toll, und wie sagst du das dem C-Compiler?

Müßte man mal in der GCC-Doku nachlesen. Mikrooptimierung hat mich nie 
ernsthaft interessiert.

[Peter D. (peda)]

Falk B. schrieb:
> In den 4 bzw. 5 Takten ist der Sprung AUS der
> Vektortabelle schon drin!

Probiers im Simulator aus. Ein leerer Interrupt 
(Tabelleneinsprung+rjmp+reti) kostet 10 Zyklen.

[Falk B. (falk)]

Peter D. schrieb:
> Müßte man mal in der GCC-Doku nachlesen. Mikrooptimierung hat mich nie
> ernsthaft interessiert.

Deine Codebeispiele hier an diversen Stellen behaupten das Gegenteil.

[Falk B. (falk)]

Peter D. schrieb:
> Probiers im Simulator aus. Ein leerer Interrupt
> (Tabelleneinsprung+rjmp+reti) kostet 10 Zyklen.

Das war gar nicht die Frage! Es gib um das Erreichen es ISR ANFANGs, um 
den Timer schnellstmöglich abzuschalten! Und da ist es egal, wie lange 
ein reti oder sonstwas dauert, das NACH dem Abschalten des Timers 
passiert.
Trink mal nen Kaffee, dann klappt's vielleicht besser mit dem 
Textverständnis.

[Peter D. (peda)]

Den MOWV Trick hatte ich mal in pure Assembler beim ATtiny13 verwendet, 
um Code zu sparen. Ist schon sehr lange her.

[Peter D. (peda)]

Falk B. schrieb:
> Es gib um das Erreichen es ISR ANFANGs, um
> den Timer schnellstmöglich abzuschalten! Und da ist es egal, wie lange
> ein reti oder sonstwas dauert

Nö, das rjmp mußt Du schon noch ausführen, ehe irgendwelcher ISR-Code 
kommt, d.h. mindestens 6 Zyklen Delay nach Ende der aktuellen 
Instruktion.
Probiers aus.

[Falk B. (falk)]

Peter D. schrieb:
> Den MOWV Trick hatte ich mal in pure Assembler beim ATtiny13 verwendet,
> um Code zu sparen. Ist schon sehr lange her.

Wenn man schon exclusive Register für eine ISR reserviert, dann kann man 
sie direkt nutzen, da muss man nicht erst andere Register dort 
reinspeichern.

Aber um nochmal Klarheit zum Thema Interruptreaktionszeiten zu bekommen.

- Interrupt wird angefordert
- aktuellen Befehl beenden (1-3 Takte)
- PC (program counter) auf Stack schieben, PC mit passendem 
Interruptverktor laden und den im Normalfall dort liegenden RJMP oder 
JMP Befehle ausführen = 4 Takte (bei großen AVRs mit PC > 5 Takte) Das 
alles ist eine atomare Operation!
der erste ISR-Befehl kann ausgeführt werden, Verzögerung 5-7 CPU-Takte 
(6-8 bei den großen AVRs)

Siehe Datenblatt, "Interrupt response time", her vom mega 2561

"7.8.1 Interrupt Response Time
The interrupt execution response for all the enabled AVR interrupts is 
five clock cycles minimum. After five clock cycles the program vector 
address for the actual interrupt handling routine is executed. During 
these five clock cycle period, the Program Counter is pushed onto the 
Stack. The vector is normally a jump to the interrupt routine, and this 
jump takes three clock cycles. If an interrupt occurs during execution 
of a multi-cycle instruction, this instruction is completed before the 
interrupt is served. If an interrupt occurs when the MCU is in sleep 
mode, the
interrupt execution response time is increased by five clock cycles. 
This increase comes in addition to the start-up time from the selected 
sleep mode.

A return from an interrupt handling routine takes five clock cycles. 
During these five clock cycles, the Program Counter (three bytes) is 
popped back from the Stack, the Stack Pointer is incremented by three, 
and the I-bit in
SREG is set."

[Falk B. (falk)]

Peter D. schrieb:
> Nö, das rjmp mußt Du schon noch ausführen, ehe irgendwelcher ISR-Code
> kommt, d.h. mindestens 6 Zyklen Delay nach Ende der aktuellen
> Instruktion.
> Probiers aus.

Du hast es nicht verstanden bzw. bist im Irrtum. Oder die Datenblätter 
von Atmel stimmen nicht.

[Peter D. (peda)]

Falk B. schrieb:
> Deine Codebeispiele hier an diversen Stellen behaupten das Gegenteil.

Dann schau mal auf das Datum dieser Beispiele bzw. es sind nur 
Fragmente, keine komplette Anwendungen. Ab WINAVR hab ich Assembler 
fallen gelassen, wie eine heiße Kartoffel.

[Peter D. (peda)]

Falk B. schrieb:
> Oder die Datenblätter
> von Atmel stimmen nicht.

Nö, die sind schon vollkommen korrekt:
"4.7.1 Interrupt Response Time
The interrupt execution response for all the enabled AVR interrupts is 
four clock cycles mini-um. After four clock cycles the Program Vector 
address for the actual interrupt handling routine is executed. During 
this four clock cycle period, the Program Counter is pushed onto the 
Stack. The vector is normally a jump to the interrupt routine, and this 
jump takes three clock cycles."

Das sagt eindeutig, daß nach 4 Zyklen Minimum Du erst in der Tabelle 
gelandet bist. Und dort steht dann typisch der Sprung zur ISR.

[Falk B. (falk)]

Peter D. schrieb:
> Das sagt eindeutig, daß nach 4 Zyklen Minimum Du erst in der Tabelle
> gelandet bist. Und dort steht dann typisch der Sprung zur ISR.

Hmmm, hab ich irgendwie missverstanden. OK, mein Fehler!