Gibt es beim ATmega168 auch Interrupt-prioitäten zum setzen.im Datenblatt nichts gefunden!!
Gibt es bei AVRs generell nicht! Die einzige Priorität ist die Reihenfolge der Interrupt-Vektor-Tabell, das mit der niedrigeren Adresse zuerst. Wenn während eines zeitkritisch "unwichtigen" Interrupts ein Zeitkritischer Interrupt erfolgen soll/muss dann in dem Interrupt mit "SEI" einfach Interrupts erlauben. MfG Andi
Gibt es schon.Habe nachgeguckt!!!Interrupts mit der niedrigeren Vektor-Adresse habe eine höhere Prioität!!
> Gibt es schon. Nein. > Interrupts mit der niedrigeren Vektor-Adresse habe eine höhere > Prioität!! Die Frage war aber, ob die Priorität einstellbar ist.
nun es ist auch dann keine Priorität. lediglich eine Interrupt Reihenfolge. Prioritäten sind es dann, wenn ein Interrupt einen anderen unterbrechen kann.
Ganz einfache Antwort für alle Standard AVR: Interrupt Prioritäten? ja Per Software einstellbar ? nein, da festverdrahtet über Tabelle. Ist aber per bei entsprechender Stückzahl wohl änderbar, neue "Verdrahtung" dieser Tabelle auf Chip-Ebene ;)
Nein es ist auch dann keine Priorität im Sinne was man unter Interruptpriorität versteht!
@mr_boetsch (fast) jeder µc sperrt nach dem Erkennen und Ausführen einer Interrupt Anforderung die Ausführung (wohlgemerkt nur Ausführen, nicht das Erkennen) weiterer Interrupts. Meistens via Interrupt-Flag Register im Prozessor-Status-Register. Die Ausführung weiterer Interrupt muß explizit durch programmtechnische Manipulation dieses Flags erlaubt werden. Vielleicht verwechselt du Int-Prioritäten mit im allgemeinen nicht blockkierbaren NMI (non maskable interrupt) über die einige Prozessorfamilien ja auch noch verfügen und die nicht blockierbar sind.
aber sicher gibt`s Prioritätslevel nur eben harwdwired und nicht per software änderbar! Datasheet lesen hilft weiter.
Hi, die Prioritäten bei den AVR geben nur an wer "drankommt", wenn mehrere Interrupts gleichzeitig anliegen. Wird in einer ISR der Interrupt wieder freigegeben, wird die ISR unterbrochen und es kommt wieder der zu diesem Zeitpunkt höchste anliegende dran. (Spezialfall "Reset" mal außen vorgelassen). Damit kann jeder Interrupt jeden anderen unterbrechen. Hat ein Prozessor "echte Interrupt-Prioritäten" dann kann eine ISR nur von einer ISR mit einer höheren Priorität unterbrochen werden (wenn in der ISR der Interrupt wieder freigegeben wurde). Beispiel: NEC V25, 2 UARTS mit Interrupts gleicher Priorität. Ich mußte nun erreichen, daß jeder UART Interrupt von dem anderen unterbrochen werden konnt. Das ging nur, indem die UART-Interrupts einen freien niedrig prioren Interrupt simuliert haben, in dem die eigentliche Arbeit erledigt wurde. Diese konnten dann natürlich von dem anderen UART unterbrochen werden. Natürlich nur EIN Mal - dann waren ggf. die beiden simulierten niedrigen ISR dran, die sich halt nicht gegenseitig unterbrechen können. Gunter
Was sollte denn auch passieren, wenn mehrere Interrupts gleichzeitig anstehen? Da müßte man ja schon extra einen Zufallsgenerator einbauen, um keine Prioritäten zu haben.
dies war für Mmerten bestimmt. Weiter stimme ich dem kommentar von Gunter bedingungslos zu.
Unter Interruptprioritäten versteht man üblicher Weise, daß ein Interrupt höherer Priorität einen mit niederer Priorität unterbrechen kann ohne jegliche Software. Der Witz dabei ist, daß dann der Interrupt höherer Priorität keinerlei Verzögerung (Latenz) erfährt, er fühlt sich so, als wäre er der einzige Interrupt auf der ganzen CPU. Und beim AVR geht das eben nicht. Beim AVR kann man nur tricksen, indem man es in Software nachbildet (umständlich die Interrutpregister laden, die entsprechenden Bits raus UNDieren und ORieren (SREG muß gesichert werden !) und wieder zurückschreiben, was dann je nach Komplexität einige 10...100 oder mehr Zyklen zusätzliche Latenzzeit bedeutet. Unter seltenen Umständen kann man nur mit einem SEI auskommen, wenn der nieder priorisierte ein Timerinterrupt ist und durch den Programmablauf gesichert ist, daß er sich nicht selbst unterbricht (genügend Zeit bis zum nächsten Überlauf). Leider ist aber oft genau der Timerinterrupt derjenige mit hoher Priorität (Software-PWM mit wenig Jitter) und z.B. die UART derjenige der nicht eilig ist und da bewirkt ein nur SEI, daß sofort der Stack überläuft. Peter
@gunter jetzt kommen wir der Sache schon näher, der V25 (so er denn noch produziert wir war ja nen x86 angelehntes Derivat mit einiges an Peripherie on chip, auch programmierbarer interrupt controller) Sowas hat der avr nicht und es gibt auch nur ein globales Interrupt disable Flag. Wenn ich nun innerhalb einer Int-Routine selektiv Interrupts höherer Priorität (gemäß Tabellenposition) oder auch nur einige wieder zulassen, geht dies zwar auch, erfordert aber einige "Handstände" auf der Softwareseite (Interrupt Maskenregister entsprechend bearbeiten)
Irgendwie werd ich das Gefühl nicht los, das hier alle ein wenig aneinander vorbei Reden. Jeder weis wie's funktioniert, aber wir diskutieren trotzdem.
@mmerten jo, Peter hat es ja schön erklärt. Nur bevor ich mir sowas antue, überlege ich doch lieber, ob ich nicht besser eine andere CPU nehmen sollte. Gunter
Hi, was passiert denn jetzt beim AVR wenn est ein Interrupt kommt, und während dieser ausgeführt wird, ein Interrupt kommt der höher priorisiert ist? 1. der 1. Interrupt wird abgearbeitet, dann der 2. Interrupt 2. der 1. Interrupt wird unterbrochen, und der 2. Interrupt wird zunächst abgearbeitet.? ????????
Salve, also ich kann das Fehlen dieser Prioritäten beim AVR durchaus verkraften. Wenn ich in einer ISR explizit andere Interrupts erlauben will, dann ist das doch mit dem Setzen bzw. Modifizieren von meistens zwei oder drei Interruptmasken-Registern getan. D.h. in + andi/ori + out, oder auch nur ldi + out. Für ein oder zwei Bits geht je nach Registeradresse evtl. sogar je ein cbi/sbi. Also zwei bis vier Zyklen pro Maskenregister, plus sei. In einem mir gerade vorliegenden Fall brauche ich gerade mal 12 Zyklen um TIMSK, SPCR und GICR anzupassen, im TIFR und GIFR ein paar Flags zu löschen, und die Interrupts global zu erlauben. Am Ende braucht's nochmal 8 Zyklen, um den Spaß wieder rückgängig zu machen. Ich finde, das kann man verkraften. Natürlich darf man nicht verschweigen, daß man bei dieser Art der Programmierung genau aufpassen muß, was man tut. Es ist also auf jeden Fall fehleranfälliger, unübersichtlicher und umständlicher zu warten. Aber die Funktionalität an sich bekommt man schon hin. Mark
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.