Es ist schon ein paar Tage her, daß ich hier einmal das Thema Spurious Interrupts ansprach. Ich bin noch am Setup des Default Interrupt Handler dran. Zum Thema Spurious Interrupts bei den Philips LPC2000 Serien hätte ich noch ein paar Fragen: Arbeite mit Keil Tools, und überlege gerade eine Handhabung der Spurious Interrupts, wie auch in der Philips AN10414 beschrieben. Die Surprise Interrupts habe ich bereits in der Startup.s direkt an den Interrupt-Vektoren, mit ein wenig Assemblercode, gemanagt. Das funktioniert gut. Jetzt die Spurious Interrupts: Interrupts können ja hier sowohl als reguläre Interrupts als auch als Default-Interrupts auftreten. Meine Idee ist, alle Interrupt-Funktionen jetzt als normale C-Funktionen zu deklarieren, die von 2 Quellen (Interrupts) angesprungen werden können, und zwar aus dem regulären Interrupt als auch aus dem Default-Interrupt-Handler, also aus 2 Quellen. Dazu rufe ich sowohl aus dem regulären Interrupt als auch aus dem Default-Handler, also von 2 verschiedenen Seiten, die Funktion auf. Im Test funktioniert das gut. Die reguläre Interrupt-Funktion, so wie sie ist, kann nicht aus dem Default-Handler aufgerufen werden. Es entstehen zwar keine Kompilier-Fehler, aber nach einem Aufruf des regulären Interrupts aus dem Default-Handler entsteht ein Undef-Abort. Ist ja auch klar, auf Grund der unterschiedlichen Rücksprungadressen und Regenerierung des Betriebsmodes. Hat da jemand Einwände, bzw. einen anderen (besseren) Vorschlag? Sehe ich was kompliziert, was auch einfach geht? Gruß Dietmar
Unentschieden scheint mir weiterhin, ob man sich die Mühe überhaupt machen muss. Ich habe bislang kein Szenario erkennen können, in dem es notwendig scheint, im Spurious Interrupt Handler auf derartige Interrupts zu testen. Wenn der Interrupt verschütt ging, weil ihn jemand bewusst ausgeschaltet hat, warum sich die Mühe machen? Wenn er verschütt ging, weil die Ursache nicht mehr besteht, warum dann.? Die UART-Beispiele von Philips jedenfalls sehen mir so aus, als ob man zwar einen Spurious Interrupt kaum vermeiden kann, aber sich das Ganze von selbst erledigt wenn man im Handler schlicht garnichts tut. Führt allenfalls zu einer geringen Verzögerung empfangener Bytes, aber das liegt sowieso in der Natur vom CTI.
"von selbst erledigt wenn man im Handler schlicht garnichts tut" So hatte ich das zuerst auch aufgefasst. Nur darf man eben den Interrupt in der Default-Routine nicht bestätigen, sonst ist er weg. Mit der Delayzeit muß man dann eben leben. Mir steht noch die Anpassung einer UART Software aus einem älteren System mit 8051 bevor. Und ein Kollege hatte bereits das Problem mit verlorenen Daten am UART (ca. jedes tausendste Byte). Gruß Dietmar
Nichtvektorierte Interrupts mal aussen vor gelassen, wird der Default Handler doch bloss dann aktiv, wenn zu dem Zeitpunkt kein Interrupt mehr anliegt. Was kann dann verloren gehen? War's ein CTI der von einem passend eintreffenden Byte gelöscht wurde, dann kommt der doch einen Timeout später wieder. Oder in Form vom RDA wenn hinreichend voll.
Ich will's mal andersrum ausdrücken: Kannst du mir ein Szenario beschreiben, indem etwas verloren geht? Das ist nämlich der Teil, den ich nicht verstehe. Philips legt das in der AN auch nahe, jedoch ohne ein nachvollziehbaren Szenario anzubieten. Dort ist nur dokumentiert, wie es zum Spurious Interrupt kommt, nicht jedoch wie dadurch etwas verloren gehen kann.
A.K.: Danke nochmal für die Hinweise. Nun, meine Anwendung läuft mittlerweile einwandfrei, wenn auch erst nach einigen Spezialitäten im Setup. Die LPC2000 sind damit durchweg eine gute Sache. Gruß Dietmar
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.