Interrupt-Priorität

hi,
du kannst einfach während des Interrupts Interrupts Global "verbieten".

am anfang des Ints: __asm("cli");//Interupts verbieten
am ende des Ints :  __asm("sei");//Interupts wieder erlauben.

mfg chrisu

Hm. Wenn Swen recht hat, wäre das also kein Problem.
Wenn ich aber mal einen AVR hätte, der die Interrupts nach Priorität 
abarbeitet und ich Chrisus lösung nehme, sehe ich ein anderes Problem.

Es könnte dann ja passieren , das ein zweiter , anstehender IRQ 
ausgelöst wird, genau zwischen dem SEI und dem RETI der laufenden 
IRQ-Routine 1.
Der Programmablauf würde dann ja folgendermaßen aussehen :


cli     ;IRQ-Routine 1
div. Befehle
sei     ;IRQ-Routine 1
        ;Auslösen der IRQ-Routine 2
cli
div. Befehle
sei     ;IRQ-Routine 2
reti    ;IRQ-Routine 2

ein befehl des Hauptprogramms

reti    ;IRQ-Routine 1

weiter im Hauptprogramm

Oder mach ich da einen Denkfehler ?

Hans Imglück schrieb:
> Oder mach ich da einen Denkfehler ?

Nein, weshalb das von Ch D. Vorgeschlagene nicht nur unnötig, sondern 
sogar potenziell gefährlich ist.

Bei allen AVRs sind Interrupts allgemein automatisch gesperrt, so lange 
eine ISR abgearbeitet wird.

spess53 schrieb:

> Abgesehen davon, das das bei AVRs nicht geht (bei anderen schon)

Natürlich geht das. Das sei im Vorschlag von chriso öffnet die 
Möglichkeit für verschachtelte Interrupts.

spess53 schrieb:
> Hi
>
>>Natürlich geht das. Das sei im Vorschlag von chriso öffnet die
>>Möglichkeit für verschachtelte Interrupts.
>
> Nein. Er versucht das unnötigerweise zu verhindern.

Du hast den Zusammenhang offenbar überhaupt nicht mitbekommen.

Ch D.:
Unsinniger Vorschlag mit den cli/sei in der ISR.

Hans Imglück:
Wenn man das benutzt, kann dann nicht das passieren:
(Beschreibung von verschachtelten Interrupts wegen dem sei am Ende der 
ISR)

Dein Kommentar zu dieser Befürchtung:
geht bei AVRs gar nicht

Sven schrieb:
> Sicher, dass ein SEI in der ISR greift und das nicht anderweitig
> geblockt wird?

Ja. Man kann definitiv mit einem SEI die Interrupts innerhalb einer ISR 
freigeben.

Stefan Ernst schrieb:
> Sven schrieb:
>> Sicher, dass ein SEI in der ISR greift und das nicht anderweitig
>> geblockt wird?
>
> Ja. Man kann definitiv mit einem SEI die Interrupts innerhalb einer ISR
> freigeben.

Wenn das so ist muss ich dann am Ende des interrupts wieder cli machen? 
oder würde ich mit einem cli am Ende die Interrupts komplett abschalten?

Also ich möchte z.B. bei einem Interrupt an einem Pin andere Interrupts 
zulassen bei einem Timer Interrupt aber nicht. So dass praktisch das 
Timer Interrupt eine höhere Priorität hat.

Thomas Frosch schrieb:

> Wenn das so ist muss ich dann am Ende des interrupts wieder cli machen?

Nein.

> oder würde ich mit einem cli am Ende die Interrupts komplett abschalten?

Nein. Ein cli am Ende der ISR hat praktisch keinen Effekt. Die 
Interrupts wären nur für eine kurze Zeit gesperrt, denn das reti danach 
gibt sie gleich wieder frei.

> Also ich möchte z.B. bei einem Interrupt an einem Pin andere Interrupts
> zulassen bei einem Timer Interrupt aber nicht. So dass praktisch das
> Timer Interrupt eine höhere Priorität hat.

Gerade bei Interrupts an einem Pin ist ein sei() in der ISR allerdings 
eine riskante Sache. Wenn das Signal an dem Pin nämlich prellt (z.B. 
Taster), oder einfach nur häufiger kommt als erwartet, hast du ruck-zuck 
sich selbst unterbrechende Interrupts.

genau, und der stack läuft über und dann ist schicht
deshalb finger weg von sei in einer isr!!!

Das Thema Interrupts und Priorität scheint ja ein nie mehr endendes 
Problem zu sein.

Habe schon so viel im Internet gelesen darüber und leider auch viel 
Unsinn.
Habe gerade selber das "Problem", dass ich eine Priorität brauche, weil 
ich einige kurze aber häufig auftretende Interrupts habe und dann wieder 
lange aber seltener auftretende.

Hatte auch überlegt, die langen Interrupts durch ein Flag zu ersetzen 
und dann im Main die eigentliche Arbeit zu machen.
Das geht aber nur, solange die Main klein genug ist um das in der 
nötigen Zeit zu schaffen. Schließlich kommt ja in die Main alles 
"unwichtige" rein, was halt irgendwann mal bearbeitet werden soll. Das 
kann dann schon recht viel werden.

Daher habe ich mich entschlossen, einen Interrupt-Handler zu schreiben, 
der Prioritäten verwaltet.
Dazu springe ich in der Vectortabelle nicht direkt auf das 
Unterprogramm, sondern auf das Label für die Priorität. Dort wird dann 
ein Prioritätenregister gesetzt.
Anschließend wird der Interrupthandler aufgerufen und arbeitet nach 
Priorität alle Interrupts ab, bei denen das Flag sitzt.
Natürlich werden alle vom Interrupt-Handler benutzen Register im Stack 
gesichert.

Das ganze funktioniert tadellos. Selbst wenn ich einen bereits laufenden 
Interrupt erneut auslöse, wird dieser erst beendet und anschließend 
gleich nochmal bearbeitet.

Einziger Nachteil ist, man braucht etwas extra Rechenzeit für den 
Interrupt-Handler.