Umschaltung Interruptserviceroutine

Doch, das geht. Der Cortex-M3 kann die Adresse seiner Vektortabelle im 
Programm ändern.

Es wäre sicherlich sinnvoll gewesen, anzugeben, dass es sich bei der 
Frage um eine Frage für den AVR handelt. Dann könnte man höchstens 
vorschlagen, dass der AVR sich selbst umprogrammiert...

Gruß
Lasse

Ich dachte mir eigentlich das ich die Vektoren umschalten kann und 
eventuell einen Vektor benutzen den ich nicht brauche.

d.h. bei Interruptereignis wird einmal die normal zuständige ISR für 
Overflow aufgerufen und ein anderes mal (nach MAnipulation der Vektoren) 
die ISR für Compare....

Grüße Kritter

Der Prozessor ist ein MEGA128, sorry

Kurz gesagt: unmöglich. Auch umprogrammieren im Betrieb geht nicht, da 
man den Flash nur 10.000 mal umprogrammieren kann. Aber was spricht denn 
eigentlich gegen 2 zusätzliche Assemblerbefehle in der ISR, mit denen Du 
die passende Routine anspringst?

Eine bool variable auszuwerten kann nicht so aufwendig sein

Man könnte auch einen pointer auf eine Funktion nehmen und diesen dann 
mit der entsprechenden Funktion zuweisen.

Da der Compiler aller Register sichern muss, sobald du aus einer ISR 
eine andere Funktion aufrufst, wird das Ergebnis nicht soviel 
effizienter sein, als wenn due ein if then else machst.

Gruss, Adib.

max schrieb:
> Auch ohne den Flash neu zu beschreiben lassen sich bei den AVRs die
> Vectoren verlegen. Ist eigentlich für andere Dinge gedacht (speziell
> Bootloader) aber unmöglich ist das definitiv nicht.

Klingt interessant, wie macht man das? Wusste nicht, dass das geht.

Zur Performance: der Gewinn ist wirklich minimal. Das Reinspringen in 
die ISR dauert sowieso 8 Zyklen, das Rausspringen nochmal 5, macht 
zusammen 13. Ein bedingter Sprung dauert inclusive Vergleich 3 Zyklen. 
Wenn du in deiner Anwendung das T-Flag nicht für andere Zwecke brauchen 
solltest, dann kannst du es für diese "Weichenstellung" verwenden und 
schaffst den Vergleich in einem Zyklus, wenn nicht gesprungen wird, und 
in zwei Zyklen, wenn gesprungen wird.

Noch ein Tipp: Falls du die nächsthöheren Interruptvektoren nicht 
benötigst, kannst du den Vergleich an dieser Stelle im Programmcode 
implementieren und kriegst die Unterscheidung möglicherweise zum 
Nulltarif.

Markus W. schrieb:
> Das Reinspringen in
> die ISR dauert sowieso 8 Zyklen, das Rausspringen nochmal 5, macht
> zusammen 13.

Ich meine reinspringen dauert 4+2 für den Sprung und ein reti kostet 
auch nur 4 (=10).

Ist der COMPA/B interrupt schon belegt? WEnn nicht kann dieser als 
Overflow genutzt werden.

max schrieb:
> Schau im jeweiligen Datenblatt nach IVSEL.

Danke, wieder was gelernt. Praktisch, aber halt auch eine Fehlerquelle. 
Ich stimm dir zu, dass es zwar möglich ist, sich aber wohl nicht lohnt.

Samuel K. schrieb:
> Ich meine reinspringen dauert 4+2 für den Sprung und ein reti kostet
> auch nur 4 (=10).

OK, ein paar Zyklen hin oder her... :-)

Ich hab mich am Datenblatt orientiert:

"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."
  --> 5+3

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

Vielleicht bist du von den kleineren AVR-Architekturen ausgegangen. Da 
gehts etwas schneller, weil RJMP statt JMP benutzt wird.

Markus W. schrieb:
> Vielleicht bist du von den kleineren AVR-Architekturen ausgegangen. Da
> gehts etwas schneller, weil RJMP statt JMP benutzt wird.

Stimmt. Ich bin noch nicht auf die Idee gekommen einen >8KB Flash AVR 
nur in Assembler zu programmieren. Aber jmp kann man auch durch einen 
Schalter durch den Compiler ersetzen lassen.

Samuel K. schrieb:
> Ich bin noch nicht auf die Idee gekommen einen >8KB Flash AVR
> nur in Assembler zu programmieren.

Stimmt, macht man normalerweise auch nicht. :-)
Außer, es kommt wirklich auf jeden Clock Cycle an, dann ist eine 
Mischung aus C und Assembler gar nicht so verkehrt.

ok, ich nehm dann doch die gute alte "Else" ;-)

Dank Euch!