Guten Abend an alle, Ich habe da mal ein paar verständnisfragen. Es geht um ein PIC18. Also nehmen wir an, wir haben einen Timer der nach einer Zahl X einen Overflow einen Interrupt auslöst. Also wird nach dem Overflow die entsprechende ISR aufgerufen. Nach dem Kontrollieren wer das Interrupt ausgelöst hat, kann es losgehen. SO, sobald das ISR aufgerufen wurde, fängt mein Timer währenddem ja wieder an von vorne an zu zählen. Meine Frage ist jetzt ob ich mein CLEAR FLAG direkt am anfang der ISR setzen soll, oder erst zum schluss der ISR. Meine Vermutungen: 1) Cleare ich das FLAG Bit erst ganz zum Schluss, so ist die komplette ISR von nem erneuten Aufruf "beschützt". ABER der Timer läuft dennoch weiter, heisst dass wenn zumbeispiel genau in dem Moment wo wir in der letzten Zeile des ISR das Flag Bit clearen, der Timer überläuft, wird die ISR nach dem verlassen dann direkt wieder aufgerufen. 2) Cleare ich das FLAG Bit ganz am Anfang der ISR, könnte doch theoretisch die ISR, bevor diese fertig abgearbeitet ist, ja nochmal vom Timer aufgerufen werden? Das hängt dann normalerweise von den Priority Bits ab? Oder kann generell ein ISR nicht abgebrochen werden von dem gleichen Interrupt? Vielen dank
New D. schrieb: > Meine Vermutungen: > 1) Cleare ich das FLAG Bit erst ganz zum Schluss, so ist die komplette > ISR von nem erneuten Aufruf "beschützt". ABER der Timer läuft dennoch > weiter, heisst dass wenn zumbeispiel genau in dem Moment wo wir in der > letzten Zeile des ISR das Flag Bit clearen, der Timer überläuft, wird > die ISR nach dem verlassen dann direkt wieder aufgerufen. > > 2) Cleare ich das FLAG Bit ganz am Anfang der ISR, könnte doch > theoretisch die ISR, bevor diese fertig abgearbeitet ist, ja nochmal vom > Timer aufgerufen werden? Das hängt dann normalerweise von den Priority > Bits ab? Oder kann generell ein ISR nicht abgebrochen werden von dem > gleichen Interrupt? Meine Tipps: 1.) Wenn der Timer während der Abarbeitung der ISR tatsächlich erneut überlaufen kann, ist das ein Hinweis einen SW-Designfehler. 2.) Wenn du etwas über die Funktion und Wirkungsweise des GIE-Bits gelesen hättest, wäre die Frage überflüssig. 2.a) RTFM statt blind Vermutungen anzustellen, kann man nicht oft genug sagen. ;-)
New D. schrieb: > 2) Cleare ich das FLAG Bit ganz am Anfang der ISR, könnte doch > theoretisch die ISR, bevor diese fertig abgearbeitet ist, ja nochmal vom > Timer aufgerufen werden? Wenn sich eine ISR ohne Grenzen selbst unterbricht, hast du einen Stack Overflow gebaut.
Michael L. schrieb: > New D. schrieb: >> Meine Vermutungen: >> 1) Cleare ich das FLAG Bit erst ganz zum Schluss, so ist die komplette >> ISR von nem erneuten Aufruf "beschützt". ABER der Timer läuft dennoch >> weiter, heisst dass wenn zumbeispiel genau in dem Moment wo wir in der >> letzten Zeile des ISR das Flag Bit clearen, der Timer überläuft, wird >> die ISR nach dem verlassen dann direkt wieder aufgerufen. >> >> 2) Cleare ich das FLAG Bit ganz am Anfang der ISR, könnte doch >> theoretisch die ISR, bevor diese fertig abgearbeitet ist, ja nochmal vom >> Timer aufgerufen werden? Das hängt dann normalerweise von den Priority >> Bits ab? Oder kann generell ein ISR nicht abgebrochen werden von dem >> gleichen Interrupt? > > Meine Tipps: > 1.) Wenn der Timer während der Abarbeitung der ISR tatsächlich erneut > überlaufen kann, ist das ein Hinweis einen SW-Designfehler. Im Studium werden aber solche Aufgaben gemacht um genau zu verstehen was in solchen Fällen dann passiert. > > 2.) Wenn du etwas über die Funktion und Wirkungsweise des GIE-Bits > gelesen hättest, wäre die Frage überflüssig. > > 2.a) RTFM statt blind Vermutungen anzustellen, kann man nicht oft genug > sagen. Ja hab eben nochmal durchgelesen. Also wenn IPEN=1 ist, also die Prioritäten eingeschaltet sind, kann die ISR durch einen Interrupt mit höherer Priorität unterbrochen werden. Ist IPEN=0 so kann die ISR NICHT abgebrochen werden. Okay also spielt es eigendlich keine grosse Rolle wann das Flag bit gecleared wird, da es sich nicht selbst in der ISR nochmal aufrufen kann, da es die gleiche Priorität hat. Hab ich das jetzt richtig verstanden? lG
New D. schrieb: > Okay also spielt es eigendlich keine grosse Rolle wann das Flag bit > gecleared wird, da es sich nicht selbst in der ISR nochmal aufrufen > kann, ... ... solange du es nicht explizit erlaubst. Das Flagbit hat auch keinen direkten Einfluß darauf, ob ein Interrupt ausgeführt wird, sondern nur wann. Für das "ob" gibt es ein Interrupt-Enable-Bit, sowohl für einzelne Interrupte als auch global. Da das Rücksetzen des Flags gern vergessen wird, ist es gut das am Anfang zu machen. Dann sieht man schneller, daß es nicht vergessen wurde. MfG Klaus
Wenn du das Flag am Schluss zurücksetzt könnte es sein, dass du eine Interrupt verpasst. Grade bei einem Timer wo du vielleicht einen Tickcounter hochzählen willst. Wenn z.B. es selten vorkommt, das der Interrupt mal länger dauert. Also am Anfang ist immer besser.
Wenn der "Interrupt mal länger dauert" hast Du ebenso einen Designfehler...
Chriss X. schrieb: > Wenn der "Interrupt mal länger dauert" hast Du ebenso einen > Designfehler... Das kann man so pauschal nicht sagen. Man kann eine solche Prozedur auch "Wiedereintrittsfähig" gestalten. Muss dann allerdings darauf achten, dass der lang laufende Teil nicht mehrfach aufgerufen wird. Pseudocode:
1 | Merker isLong = false; |
2 | Merker ticks = 0; |
3 | IRS() |
4 | {
|
5 | ticks++; |
6 | wenn(ticks >= 500 && !isLong) |
7 | {
|
8 | ticks -= 500; |
9 | isLong = true; |
10 | erlaubeInts(); |
11 | tuLangLaufer(); // unterschiedliche Laufzeiten |
12 | isLong = false; |
13 | }
|
14 | }
|
Ticks sind hier irgendwelche eintreffenden Ereignisse. Alle 500 Ticks soll was länger dauerndes gemacht werden. Es werden alle ticks gezählt auch während der LangLäufer aktiv ist. Der LangLäufer sollte (im Durchschnitt) innerhalb von 500 Ticks fertig werden. Wenn er es ab und zu nicht schafft, ist es auch nicht schlimm, das wird aufgeholt. Probleme treten auf, wenn der Wertebereich des Merkers ticks überschritten wird.
Klaus schrieb: > New D. schrieb: >> Okay also spielt es eigendlich keine grosse Rolle wann das Flag bit >> gecleared wird, da es sich nicht selbst in der ISR nochmal aufrufen >> kann, ... > > ... solange du es nicht explizit erlaubst. Das Flagbit hat auch keinen > direkten Einfluß darauf, ob ein Interrupt ausgeführt wird, sondern nur > wann. Für das "ob" gibt es ein Interrupt-Enable-Bit, sowohl für > einzelne Interrupte als auch global. Disco schrieb: > Wenn du das Flag am Schluss zurücksetzt könnte es sein, dass du > eine > Interrupt verpasst. Grade bei einem Timer wo du vielleicht einen > Tickcounter hochzählen willst. Wenn z.B. es selten vorkommt, das der > Interrupt mal länger dauert. Wie meinst du verpassen? Ich dachte doch dass die ISR die gerade von nem Timer ausgelöst wurde, nicht nochmal von dem gleichen Timer unterbrochen werden kann, egal ob das Flag am Anfang oder am Ende zurückgesetzt wurde? Da ist noch irgendwo ein Denkfehler bei mir. Danke
Wenn das Flag gar nicht gelöscht wird, wird der Interrupt sofort nach Rückkehr wieder gestartet. Wenn ich es früher lösche kann es auch noch einmal gesetzt werden löscht man es später kann dieses 2. Setzen nicht mehr unterschieden werden. das schlechte Design steht übrigens nicht zur Debatte wenn es um die speziellen Abläufe geht.
New D. schrieb: > Wie meinst du verpassen? Ich dachte doch dass die ISR die gerade von nem > Timer ausgelöst wurde, nicht nochmal von dem gleichen Timer unterbrochen > werden kann, egal ob das Flag am Anfang oder am Ende zurückgesetzt > wurde? Nein, die ISR kann nicht durch den gleichen Timer unterbrochen werden, weil GIE beim Sprung in die ISR auf 0 gesetzt wird, und erst beim RETFIE wieder auf 1. Natürlich kannst du GIE auch in der ISR wieder auf 1 setzen, aber das zu tun ist ziemlich dämlich.
Michael L. schrieb: > aber das zu tun ist ziemlich dämlich. Ist es das? Immer? Das große, oder das kleine Immer? Die Alternative? In der ISR ein Flag setzen und dieses Flag dann in der main-loop pollen... Pollen ist dämlich, wenn man denn schon einen Interrupt nutzt. Hier das kleine dämlich, denn es kommt auf die Umstände an.... Wobei... PIC ist nicht so mein Ding... Wenn man Interrupts mindestens 2 Ebenen stapeln kann, gehts.
Ulrich F. schrieb: > Michael L. schrieb: >> aber das zu tun ist ziemlich dämlich. > > Ist es das? > Immer? > Das große, oder das kleine Immer? > > > Die Alternative? > In der ISR ein Flag setzen und dieses Flag dann in der main-loop > pollen... > Pollen ist dämlich, wenn man denn schon einen Interrupt nutzt. > Hier das kleine dämlich, denn es kommt auf die Umstände an.... Das liest sich so, als ob du keine Ahnung hast, was das GIE eigentlich ist und bewirkt. Dein obiges Geschreibsel von der wiedereintrittsfähigen ISR ist auch nicht wirklich sinnvoll. Damit kannst du Newbies beeindrucken, oder besser gesagt total verwirren. Hier noch mal zur Klarstellung: 1. Die ISR wird komplett abgearbeitet, und nicht durch einen Interrupt der gleichen Priorität unterbrochen. Warum, das habe ich schoon erklärt, und deswegen muss die ISR auch nicht wiedereintrittsfähig sein. 2. Wenn Interruptereignisse (z.B. vom Timer) in schnellerer Folge ausgelöst werden, als diese von der ISR abgearbeitet werden können, dann ist das ganz klar ein Desigenfehler, den man auch nicht mit einer wiedereintrittsfähigen ISR beheben könnte.
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.