Ich habe versucht etwas mit Level0 und Level1 Interrupt im AVR128DB zu machen, aber ich bringe es nicht fertig dass der Level1 Interrupt den Level0 Interrupt unterbricht. Und zwar mache ich folgendes ich habe zwei Pin Change Interrupts. Einer auf Port B und der andere auf Port E. Mit einem Signal triggere ich den Pin Change Interrupt vom Port B. Die Interrupt Routine vom Port B setzt dann ein Signal dass den Interrupt auf Port E triggert. Die PC Interrupt Vector Addresse von Port E habe ich in das CPUINT_LVL1VEC register geschrieben, ich kann es auch auslesen und da steht 0x5C drin. Ich erwarte daher, dass die Interrupt Routine vom PC Interrupt des Port E die laufende Interrupt Routine vom PC Interrupt Port b unterbricht, aber dem scheint nicht der Fall zu sein. In beiden Interrupt Routinen wackle jeweils an einem Ausgang aber wenn ich mir das am LA anschaue wackelt der Ausgang der Port E Interrupt Routine erst nach dem Wackelkonzert der Interrupt Routine vom Port B. Dies wackelt etwas an einem Pin, setzt das Signal for den Port E interrupt und wackelt dann weiter am Pin, aber erst wenn diese Routine endet sehe ich die Aktion der Interrupt Routine vom Port E. Ich habe auch den CPUINT_STATUS in der Port E Routine ausgelesen und da ist aber LVL1EX nicht gesetzt. Das Ganze ist akutell in einem etwas komplexen Umfeld eingepflegt daher hier noch kein Schaltplan oder Code. Vielleicht kann mir ja trotzdem jemand einen Tip geben was ich vergessen habe könnte, bevor ich mir eine minimale Testumgebung aufbaue.
Eine laufende ISR verbietet Interrupts. Da hilft sei(), aber Vorsicht: Nun kann der Interrupt sich selber unterbrechen.
Justin S. schrieb: > Eine laufende ISR verbietet Interrupts. Da hilft sei(), aber Vorsicht: > Nun kann der Interrupt sich selber unterbrechen. Dann sind es keine unterschiedlichen Level. Der Sinn von unterschiedlichen Leveln ist es, dass ein laufender Interrupt durch einen mit höherer Priorität unterbrochen werden kann.
Das LVL1VEC hat kein configuration protect nur das CTRLA aber das ändere ich nicht der default passt.
Peter S. schrieb: > Und zwar mache ich folgendes ... Programmtext in Prosa ist nur selten verständlich und nie eindeutig. Hänge ein compilierbares *.c an, dann sehen wir weiter. 2 Interrupts mit Handler aufzusetzen, sollten ja nur wenige Zeilen sein.
Peter D. schrieb: > Peter S. schrieb: >> Und zwar mache ich folgendes ... > > Programmtext in Prosa ist nur selten verständlich und nie eindeutig. > Hänge ein compilierbares *.c an, dann sehen wir weiter. > 2 Interrupts mit Handler aufzusetzen, sollten ja nur wenige Zeilen sein. Kommt noch. Nur wird es nichts compilierbares sein :-)
Peter S. schrieb: > Nur wird es nichts compilierbares sein :-) Na dann kann es ja auch nicht funktionieren. Es wird kein Hex-File erzeugt und Du führst nur einen leeren Flash aus (0xFFFF = NOP).
:
Bearbeitet durch User
Angehängte Dateien:
-
Level1Test.png
7 KB
Es ist etwas Assemblierbares. Im Anhang habe ich auch einen Ausschnitt vom LA anghängt. Das erste weisse Signal ist der Wackelport vom Level0 interrupt Das zweite braune Signal ist der Wackelport vom Level1 interrupt Das dritte rote Signal wird vom Level0 interrupt gesetzt/gelöscht Das vierte orange Signal wird vom Level1 interrupt gesetzt/gelöscht Wie man sieht werden die Interrupts hintereinander ausgeführt, eigentlich erwarte ich, dass der Level0 interrupt vom Level1 interrupt unterbrochen wird den er ja selbst triggert.
Angehängte Dateien:
-
level1testb.png
6,5 KB
Habe gerade gesehen, das geht auch mit mehr Info vom LA und zwar noch mit den Pins LV0 (Port B Pin 4) und INTL (Port E Pin 2), dann sieht man auch den Status der Pins die die Interrupts auslösen und da sieht man dass der Level0 Interrupt INTL auf Low setzt was eigentlich sofort den Level1 Interrupt starten sollte aber da passiert nichts und der Level0 Interrupt macht fröhlich weiter.
Peter S. schrieb: > Kommt noch. Nur wird es nichts compilierbares sein :-) Warum nicht? Du solltest einen Beispiel-Code bereit stellen, der dein Problem zeigt. Nur dann kann man dir wirklich helfen, alles andere ist schlicht nur Stochern im Nebel.
Hab ich ja gemacht, nur eben keinen compilierbaren *.c Code sondern assemblierbarer *.asm
Hab ich gesehen, erscheint mir aber zu umfangreich (dabei fiel mir u.a. auf: CR bei 15 und LF bei 12? Typisch ist CR 13 und LF 10, warum der Offset von 2?). Runter brechen auf ein Minimum welches nur das Problem zeigt. ;)
M. K. schrieb: > Hab ich gesehen, erscheint mir aber zu umfangreich (dabei fiel mir u.a. > auf: CR bei 15 und LF bei 12? Typisch ist CR 13 und LF 10, Nein, 15 und 12 oktal stimmt schon. > warum der Offset von 2?). Das ist die Differenz zwischen 8 und 10 ;-)
M. K. schrieb: > Hab ich gesehen, erscheint mir aber zu umfangreich (dabei fiel mir u.a. > auf: CR bei 15 und LF bei 12? Typisch ist CR 13 und LF 10, warum der > Offset von 2?). Runter brechen auf ein Minimum welches nur das Problem > zeigt. ;) Das einzige was man noch runter brechen könnte sind die nicht benutzten Port Pins nicht zu initialisieren und den USART und das "Menue" entfernen und alles in einer Loop repetitiv ausführen, nur ich arbeite immer ganz gerne mit einer interaktiven Schnittstelle damit ich auch sehe dass es wirklich läuft. Ich denke das dürfte nicht das Problem sein oder?
M. K. schrieb: > Ah, ok. Ich hab das führende O als eine 0 gelesen ;) Das "führende O" ist eine 0. So werden Oktalzahlen dort angegeben.
Peter S. schrieb: > Es ist etwas Assemblierbares. Puh, das erschwert natürlich deutlich die Lesbarkeit. Die vielen Defines zwischen den Codezeilen stören doch sehr. Pack sie besser in ein extra *.h File. Ich bin von C gewohnt, daß man zusammengehörende Sachen in eine Funktion packt (int0_init, int0_handler usw.). Alles irgendwie hintereinander zu klatschen, läßt einen schnell den Faden verlieren.
Ohne das jetzt ausprobiert zu haben:
> ... 0x5C ...
Das ist die Vektoradresse - verlangt wird aber
"the number of the single vector with increased priority level 1" laut
'Interrupt Vector Mapping'.
S. Landolt schrieb: > Ohne das jetzt ausprobiert zu haben: > >> ... 0x5C ... > Das ist die Vektoradresse - verlangt wird aber > "the number of the single vector with increased priority level 1" laut > 'Interrupt Vector Mapping'. Danke das war's mit 0x2E klappts.
Peter D. schrieb: > Peter S. schrieb: >> Es ist etwas Assemblierbares. > > Puh, das erschwert natürlich deutlich die Lesbarkeit. > Die vielen Defines zwischen den Codezeilen stören doch sehr. Pack sie > besser in ein extra *.h File. > Ich bin von C gewohnt, daß man zusammengehörende Sachen in eine Funktion > packt (int0_init, int0_handler usw.). Alles irgendwie hintereinander zu > klatschen, läßt einen schnell den Faden verlieren. Ja das mag sein, dass du dir C gewohnt bist, ich bin mir Assembler gewohnt. Aber keine Angst im vollen Projekt sind das alles Header Files.
Steht im Eröffnungstext. Oder auch im File: ldi r18, PORTE_PORT_vect sts CPUINT_LVL1VEC, r18
Thread beobachten
Seitenaufteilung abschaltenBitte 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.