|
Anzeige
|
Interrupts deaktiviert, ISR wird trotzdem benötigt?Hallo, Ich habe eine kleine Funktion die auf einen Interrupt von INT1 wartet um die Pulszeit am INT1 zu messen.
Nun resetet sich der AVR aber immer. Sobald ich die ISR einfüge läuft es:
Dann wird sie aber trotzdem aufgerufen, oder? Ich habe mir gedacht, dass nach dem cli() die ISR nicht gebraucht werden, oder? Wie kann ich die ISR "wegoptimieren"? Ich habe AVR Studio 5.1 mit AVR/GCC. Weil der Interrupt "pending" ist und sobald Du die Interrupts mit sei() wieder global einschaltest, der Int ausgelöst wird, weil das entsprechende Flag noch gesetzt ist Hugo P. schrieb: > Ich habe mir gedacht, dass nach dem cli() die ISR nicht gebraucht > werden, oder? Sofern nach dem cli() nie wieder ein sei() aufgerufen wird, geht das auch. Hugo P. schrieb: > Wie kann ich die ISR "wegoptimieren"? Einfach nicht den zugehörenden Interrupt freigeben. Hugo P. schrieb: > EIMSK = (1 << INT1); Warum aktivierst du den Interrupt überhaupt, wenn du ihn nicht nutzen willst? Das INTF1 wird unabhängig, ob du einen Interrupt auslösen willst, gesetzt wenn die hier
aufgeführte Bedingung erfüllt wird. Die Frage ist eher, warum überhaupt einen ext. Interrupt einschalten, wenn man ihn nicht haben will. Im grunde wird ja ein Polling gemacht, dann braucht man keine Interrupts.
Gast
#5416868
Wobei sich natürlich die Frage stellt warum du Interrupts aktiviert hast aber dann nicht nutzen willst. Falscher Ansatz bzw. Denkfehler? Hugo P. schrieb: > Wie kann ich die ISR "wegoptimieren"? Indem du keine Interrupts benutzt. Das löschen von
ist die Lösung. Somit wird die ISR nicht aufgerufen.
Gast
#5416964
@ Hugo Also, mich würde ja auch mal interessieren, ob es einen vernünftigen Grund gibt, das so zu machen. Das Verfahren hat aus meiner Sicht nur Nachteile. 1. Zusätzlicher Aufwand um EICRA, EIMSK und EIFR zu bedienen. 2. Ein Busy-Waiting auf die jeweilige Flanke. Den Zweck könnte man auch ohne 1. erreichen, selbst wenn man Busy-Waiting verwendet. Und Busy-Waiting wendet man, meiner Meinung nach, auch nur in den ersten Programmen an, um das Prinzip der Erkennung von Flanken mal zu lernen. Oder, falls definitiv klar ist, dass die nachfolgende Änderung in einem Zeitabstand kommt, der nicht gemessen werden muss und kürzer ist, als es bräuchte, um einen Timer zu konfigurieren. (Also etwa Status-Abfragen in der UART). Ausserdem kann das, wenn man schon soweit ist, der Timer von alleine - ohne Busy-Waiting, so dass die CPU nebenbei noch anderes tun kann. Magst Du das mal erklären? Mal Code ohne EICRA und Konsorten (mit irgendeinem Pin der auf Eingang konfiguriert ist).
> Ich habe eine kleine Funktion die auf einen Interrupt von INT1 wartet um
die Pulszeit am INT1 zu messen.
Ist ganz schlechter Stil. Man sollte nie in einer Funktion warten. Das
nennt sich blockierend. Und ist sehr schwer zu debuggen. Mach alle
Funktionen nicht blockierend und warte ausschliesslich im Main.
Mach eine Zustandsvariable im Main und benutze diese zum Reagieren und
auch zum Debuggen
Gorch F. schrieb: >> Ich habe eine kleine Funktion die auf einen Interrupt von INT1 wartet um > die Pulszeit am INT1 zu messen. > > Ist ganz schlechter Stil. Naja, Stil ist für manche ja das Ende des Besens ... > Man sollte nie in einer Funktion warten. Das > nennt sich blockierend. Und ist sehr schwer zu debuggen. Ich sehe überhaupt keinen Grund, warum das schwer zu debuggen sein sollte. > Mach alle > Funktionen nicht blockierend und warte ausschliesslich im Main. Oh, nun ist main() blockierend ... ups Oftmals kann bei simplen Anwendungen die Variante ohne Interrupts sinnvoller sein: der Compiler kann besser optimieren und so manche push/pop-Orgien sind auch unnötig. Also: ob polling in simplen µC Anwendungen ohne OS schlecht oder gut ist, hängt von einigen Faktoren ;-) Antwort schreiben |
Anzeige
|
