ARM: AT91SAM7s Interrupts Verstaendnisproblem

[romanua (Gast)]

Hallo,

Kann mir jemand bitte erklaeren, was bei AT91SAM7s "external interrupt
lines" bedeuten?

Ich dachte, dass es etwas mit den durch Pins ausgeloeten Interrupts
haben soll. Aber wenn ich das Datenblatt richtig verstehe, haben die
"external interrupts" nichts mit PIO zu tun.

Danke.

[Frank (Gast)]

Der PIO-Controller kann selbst einen Interrupt auslösen, sobald sich ein
Pin ändert. Die "external interrupts" sind wohl dazu da, das ganze
etwas schneller zu machen, weil man dann in der ISR nicht erst
nachschauen muß, welcher Pin den Int ausgelöst hat. Man müsste sogar
einen FIQ damit auslösen können, was das ganze nochmal schneller
macht.

Der Frank ohne "bye"

[romanua (Gast)]

Hallo Frank, danke fuer die Hilfe.

Meinst du, dass es Pins gibt, die direkt als "interrupt sources"
eingestellt werden koennen?

Welche ist die richtige Seite im Datenblatt dazu? Im Kapitel zum
Advanced Interrupt Controller finde ich nichts.

[Frank (Gast)]

11.3 PIO Controller A Multiplexing
IRQ0,1 und FIQ sind dann Deine Pins.
Und beim AIC steht doch auch was über die IOs.
11.4 Peripheral Identifiers

[romanua (Gast)]

@ Frank,

Danke fuer die Erklaerung, es hat geholfen.

I moecht Dich noch fragen, ob ich die Sache richtig sehe:

Fast Interrupts unterscheiden sich von normalen Interrupts durch
R8_fig-R12_fig, die im FIQ Modus als R8-R12 dienen und die man nicht
absichern muss. Das spart Zeit und dadurch - FAST Interrupt.

In etwa so, oder es gibt noch Punkte warum FIQ schneller als IRQ ist?


Noch eine Frage zu Fast Forcing.

Wenn ein normaler Interrupt ausgeloest wird, kann ich die Adresse des
Handlers in AIC_IVR finden, wenn ein schneller Interrupt(FIQ) dann
steht die Adresse des Handlers in AIC_FVR.

Wo lese ich die Adresse des Handlers wenn ein  Fast geforcter Interrupt
ausgeloest wird? Das Datenblatt sagt AIC_FVR zeigt immer AIC_SVR0, egal
welche Quelle es war. Ist es dann AIC_IVR?

Wenn "ja", wird PC mit 0x18(wie bei IRQ) oder mit 0x1C(wie bei FIQ)
beladen?

Gruss,
r.

[Frank (Gast)]

>In etwa so, oder es gibt noch Punkte warum FIQ schneller als IRQ ist?

Nein, das sehe ich eigentlich auch so. Wenn man den FIQ-handler in
Assembler schreibt, braucht man u.U. sonst keine Register zu sichern.

>Ist es dann AIC_IVR?

Ich glaube nicht, allerdings hab ich mit FIQs oder fast forcing noch
nichts gemacht. So wie ich das sehe liegt der Sinn von fast forcing
darin, wenn man EINE Interruptquelle besonders schnell behandeln will,
also z.B. wenn Du einen Timerinterrupt besonders schnell machen willst,
dann schreib die Adresse des Handlers direkt in AIC_SVR0 und mach ihn
fast forcing. Es macht doch wenig Sinn, einen Interrupt als fast
forcing zu deklarieren, wenige Takte beim sichern der Register zu
gewinnen und dann wieder zu verschwenden, weil man erstmal schauen
muss, welcher Interrupt denn nun behandelt werden muß. Da kann man auch
gleich beim normalen IRQ bleiben. Bei FF wird der PC mit 0x1C geladen,
wie beim normalen FIQ. Der AIC aktiviert die nFIQ Leitung zum Core.

[A.K. (Gast)]

"In etwa so"

Ja.

"oder es gibt noch Punkte warum FIQ schneller als IRQ ist?"

Indirekt. Normale IRQs werden mitunter "nested" betrieben, d.h. höher
priorisierte IRQs kommen auch innerhalb einer Interrupt-Routine durch.
Die nicht ganz durchdachte Interrupt-Technik der ARMs erfordert dafür
signifikanten Verwaltungsaufwand. Entfällt dann beim FIQ.

"Wo lese ich die Adresse des Handlers wenn ein  Fast geforcter
Interrupt ausgeloest wird?"

Seitens der CPU sind keinerlei Interrupts oder Exceptions vektorisiert,
weder IRQ noch FIQ. Üblich ist freilich, dass der erste Befehl des IRQ
den Vektor aus dem Interrupt-Controller in den PC lädt, der FIQ-Code
jedoch entweder direkt bei 0x1C beginnt (weshalb das ja die letzte
Adresse in der Sprungleiste ist), oder dort schlicht der Sprung zur
FIQ-Routine steht. Zwar kann man evtl. auch für FIQs einen
Interrupt-Controller verwenden, aber das entspricht nicht ganz dem Sinn
der Sache, üblicherweise gibt's für FIQs nur eine einzige Ursache.