Am einfachsten anfangen ?

[PICture]

Hallo!

Ich habe mit "studieren" des Datenblattes von ATtiny24/44/84 ( http://www.atmel.com/dyn/resources/p...ts/doc8006.pdf ) angefangen und festgestellt, dass die Interruptvektoren (1 ... 17) auf Seite 48 für alle Interrruptsquellen schon fest definiert sind und können nicht beliebig geändert werden. Stimmt das ?

[radbruch]

Man kann die Zieladressen in der Sprungtabelle der Interrupts ändern. Defaultmässig springen die zu einem RETI. Einfach die Adresse der selbstgemachten ISR eintragen.

[PICture]

Das ist mir noch nicht ganz klar, weil selbstverständlich an den Adressen (0 ... 17) entsprechende ISR Adressen/Marken stehen werden. Beispielweise, wenn ich den Timer/Counter0 permanent laufen lasse, wird nach jedem Überlauf an die Adresse 0x000Bh und weiter an dort stehende Adresse/Marke entsprechender ISR gesprungen und das kann ich nicht ändern, oder ?

[Searcher]

Hallo PICture,

ich seh das auch so, daß die Zuordnung von Interruptquelle und Programmadresse bei dem ATtiny festgelegt sind.

Das kann man nicht ändern und legt auch gleichzeitig in der Reihenfolge der Interruptnummern die Prioritäten fest. Der Inhalt der Programmadresse kann geändert werden und sollte bei generellem Gebrauch von Interrupts die Anweisung (zB RJMP) zum Aufsuchen der ISR enthalten.

Als Pre-Anfänger in ASM stelle mir das so vor, das der Programmcounter durch den Interrupt HW gesteuert unbeeinflußbar auf den in der Tabelle 9-1 aufgeführten unveränderbaren Wert gesetzt wird. Dort sollte dann ein Befehl stehen, der die Programmausführung mit der ISR fortführt.


Gruß
Searcher

[Besserwessi]

Die Interruptsvektoren sind fest, am Anfang des Flash je 1 (bzw. 2 ab 16 Kbytes Speicher) Worte auseinander. In der Regel steht da dann ein Sprung (RJMP oder JMP) auf die eigentliche ISR. Wenn man die Interrupts dahinter nicht braucht kann man da auch direkt mit der ISR anfangen ohne den Sprung. Da dies im Flash steht kann man es zur Laufzeit nicht (oder nur sehr umständlich) ändern. Falls man da je nach Programmteil eine andere ISR braucht macht man das als normale Verzweigung im Code.

Ein Sprung auf ein RETI für einen nicht genutzten Interrupt ist übrigens ziemlich sinnfrei: Da könnte auch gleich das RETI hinschreiben, und außerdem aktiviert man einen ungenutzten Interrupt einfach nicht.

[PICture]

Hallo!

Danke schön Euch beiden für ausführliche und verständliche Erklärungen. Man muss also damit leben, dass auftretende z.B. ein Timer1 interrupt immer die Timer0 interrupt für die Ausführung der ISR von Timer1 anhalten kann, was mir aber nicht gefällt.

Wann genau wird das Interruptflag in GIFR Register (einzige Möglichkeit die Quelle zu erkennen) gelöscht ? So wie ich das bisher verstanden habe wird es hardwaremässig (intern) vor dem Zwangsprung in die entsprechende ISR gemacht, oder ?

Dann hätte man keine Chance rechtzeitig die Interruptquelle zu erkennen und die Ausführung der entsprechender ISR zu verhindern/verzögern.

[Besserwessi]

Wann genau das Interrupt-flag gelöscht wird, ist nicht so wichtig. Die Annahme beim Sprung zum Interruptvector kommt mir auch plausibel vor. Es gibt aber ein paar Ausnahmen wo das Bit gar nicht von der Hardware gelöscht wird und das von Hand gemacht werden muss (z.B. USI ?).

Da man für praktisch jede Interrupt-quelle einen eigenen Interrupt-vektor und damit bei Bedarf eine eigene ISR hat, braucht man die Interruptflags nicht um die Quelle zu erkennen. Gelöscht wird aber immer nur das Flag von der aktuell aufgerufenen ISR. Man könnte also in der ISR von Timer0 immer noch feststellen ob auch das Flag von Timer1 gesetzt ist. Wenn einem der Interupt von Timer1 so wichtig ist, kann man in den anderen ISRs ggf. per SEI weitere Interrupts zulassen. Das reduziert die Verzögerung, verhindert sie aber nicht ganz.