Nested Vectored Interrupt Controller

Datenblatt (bei st gibt es drei davon) lesen ist auch sehr hilfreich...

Gut danke :)

Wenn du vorher z.B. mit AVR programmiert hast, ist es schon ein 
riesengroßer Unterschied. Beim AVR wird in einer ISR (üblicherweise) als 
erstes cli() aufgerufen und als letztes sei(). Damit kann man dann 
sicher sein, daß innerhalb einer laufenden ISR keine weitere ISR 
dazwischenhaun kann. Das hat man als AVR-Nutzer schnell und tief 
verinnerlicht, da es das Programmieren (besonders der ISRen) deutlich 
vereinfacht.
Der NVIC mit seinem ersten Buchstaben haut allerdings (üblicherweise) 
jederzeit (proritätenabhängig) dazwischen. Da muß man schon enorm mehr 
beim Programmieren berücksichtigen, besonders wenn man es ganz anders 
gewohnt war/ist. Bin ich am Anfang auch schön mit auf die Schnauze 
gefallen, zumal Interruptprogrammierung (z.B. bei EXTIs) meistens nicht 
so schön reproduzierbar ist.

A. K. schrieb:
>> Beim AVR wird in einer ISR (üblicherweise) als
>> erstes cli() aufgerufen und als letztes sei().
>
> Quark. Das macht die Hardware selbst. sei() unmittelbar am Ende der ISR
> hat sogar die gegenteilige Wirkung und kann zum Stack-Overflow führen.

Nun hätte ich ja geschworen, daß das mal anders war? Schön zu Fuß SREG 
sichern, cli(), wasauchimmer, SREG zurück (und damit den Status des I). 
Pauschal sei() am Ende ist natütlich quatsch; haste recht. Die avr-libc 
hat das ja irgendwann auch so gemacht (meine ich zumindest). Hat Atmel 
das mal geändert?

A. K. schrieb:
>> Damit kann man dann
>> sicher sein, daß innerhalb einer laufenden ISR keine weitere ISR
>> dazwischenhaun kann.
>
> Was beim NVIC nicht wesentlich anders ist, bezogen auf Interrups
> gleicher oder geringerer Priorität.

Genau deshalb schrieb ich

Lutz schrieb:
> Der NVIC mit seinem ersten Buchstaben haut allerdings (üblicherweise)
> jederzeit (proritätenabhängig) dazwischen.

Wobei im NVIC allerdings die Prioritäten (neben der 
defaultpriorisierung) einstellbar sind, was man dann ja auch gerne tut. 
Und genau das kann dann noch zu weiteren Quereffekten führen, die man 
berücksichtigen muß.

Danke für das "entrosten" meiner Erinnerungen.

Peter Dannegger schrieb:
> Lutz schrieb:
>> Beim AVR wird in einer ISR (üblicherweise) als
>> erstes cli() aufgerufen und als letztes sei().
>
> Quark mit Soße. Sieht man allerdings bei Anfängern öfters.
> Irgendwie scheint man sich immer nur die Fehler von anderen abzugucken.

Das mit dem falschen sei() hatten wir ja schon geklärt.

Peter Dannegger schrieb:
> Lutz schrieb:
>> Der NVIC mit seinem ersten Buchstaben haut allerdings (üblicherweise)
>> jederzeit (proritätenabhängig) dazwischen.
>
> Nö.
> Prioritäten würfelt man ja nicht aus, sondern vergibt sie mit Absicht.
> D.h. man benötigt es, daß ein schneller Interrupt einen langsamen
> unterbrechen soll. Und nur dann programmiert man es so.

1.) Was ist an der Aussage falsch?
2.) Na klar, wenn man alles richtig macht, kann man per Definition auch 
keinen Fehler machen. Mit der Betrachtungsweise kann man so ziemlich 
jede Diskussion abwürgen.
Nur steigt mit der Zahl der Stellschrauben auch die Wahrscheinlichkeit, 
etwas falsch zu machen. Und gerade Interrupts bieten sich dazu an. Und 
das ganz besonders, wenn das ganze Interruptkonstrukt auch noch anders 
funktioniert, als man es verinnerlicht hat.
Gerade beim Interruptkonzept ist der Unterschied zum AVR enorm und der 
NVIC ist weitaus komplexer und hat viel mehr Möglichekiten, als man auf 
den ersten oder sogar zweiten Blick erkennt. Da ist letztendlich fast 
die Phantasie des Programmierers der limitierende Faktor. Vorgenanntes 
Beispiel mit dynamischer Priorisierung veranschaulicht das ganz gut.

Beim AVR läuft die ISR durch und Ende. Es sei denn, man ist so verwegen, 
und zündet zwischendrin mit sei() die Lunte an. Na klar, wenn man weiß, 
was man macht ...
So kann man beim AVR sicher sein, daß eine autonome Peripherie (z.B. 
Timer) in der ISR nur das macht, was vorher schon eingestellt war oder 
in dieser ISR geändert wird. Schön einfacher, linearer Gedankengang. Der 
NVIC kann da aber, je nach Einstellung, zwischenhaun. Und aus der Traum. 
Beispiel: Man nutzt in einer ISR einen Timer. Sofern da nicht vorher 
schon was eingestellt war, können nur meine Änderungen in der ISR was 
verändern. Kommt nun aber ein höher priorisierter Interrupt dazwischen, 
der über weißnichwas für Umwege auch diesen Timer beeinflußt, ist schon 
Essig. Und diese möglichen Querbeziehungen werden schnell sehr komplex 
und natürlich wird da ein vernüftiges Softwaredesign viel wichtiger als 
beim AVR. Insofern ist es natürlich richtig, daß Prios nicht 
ausgewürfelt werden.

Übrigens stimme ich der Aussage
> D.h. man benötigt es, daß ein schneller Interrupt einen langsamen
> unterbrechen soll. Und nur dann programmiert man es so.
so nicht zu. Die Dauer einer ISR ist ein wichtiges Kriterium für die 
Prioritätenvergabe, die Bedeutung des Prozesses aber eine weitere, 
mindestens genauso wichtige. Beides zusammen muß zur Bestimmung der 
Priorität herangezogen werden. Keine Ahnung: Eine 3 Sekunde lange 
shutdown-ISR für Notfälle würde ich nun kaum von einer banalen 1 ms "I'm 
still alive"-ISR unterbrechen lassen.