Also mein Programm. Hauptprogramm... <---Interrupt löst aus Interrupthandler I-Flag wird gesetzt, damit Interrupts erlaubt sind ... ... ... Rücksprung zum Hauptprogramm So, meine Frage: Im Hauptprogramm wird mit dem Register R1 gearbeitet. Beim Interruptaufruf werden ja alle Register gesichert, darum auch R1. Im Interrupthandler wird ebenfalls mit R1 gearbeitet. Beim Rücksprung zum Hauptprogramm werden die Register wieder zurückgesetzt und der alte Werte vom Hauptrpgramm ist wieder im R1. Doch ich setzt nach dem Interruptaufrug sofort wieder das I-Flag, damit höherwertige Interrupts diesen aktuellen Interrupt unterbrechen können. Werden die register beim Rücksprung zum Hauptprogramm zurückgesichert oder schon beim setzen des I-Flags???
:
Verschoben durch Admin
sie werden erst am ende der ISR zurück geschrieben. Aber das ganze ist ja egal. Wenn inerhalb der ISR noch ein Interupt auftritt Ist das ja nichts anderes als ob der der main der interupt auftritt.
ja, danke. Wollt nur sicher gehen. Suche schon seit langer zeit die Ursache für einen Fehler. Folgendes Scenarie: im hauptprogramm wird mit float-zahlen gerechnet. dabei habe ich durch intensive Recherche herrausgefunden dass mein Controller dabei eine Optimierungsmethode verwendet und diese verwendet das Register R1. Während im Hauptprogramm gerechnet wird, tritt ein Interrupt auf. In diesem Interrupt wird ein DMA-Controller konfiguriert. Um diesen zu konfigurieren muss ich ASM verwenden und dieser ASM-Code verwendet ebenfalls das Register R1. Ich habe mir gedacht, dass bei einem Interrupt die Register eh alle gesichert werden und so kommt es zu keinen Problemen. Leider ist dem nicht so, ein Kollege hat mir gesagt, dass mein Interrupt anscheinend ein High-Speed-Interrupt ist, dass heißt, dass dieser keine sicherung der Registerzustände durchführt. Habe jetzt mal zu Testzwecken das Register R1 im Interrupt bevor ich es modifiziere gepusht. dann kommt der ASM-Code und werde pop ich es wieder zurück. HUI HUI, es funktioniert. Werd jetzt mal das Datenblatt nochmal studieren, was es da mit der Sicherung von Registerzuständen und mit dem High-Speed-Interrupt auf sich hat. lg
da du ja überhaupt nicht geschieben hast um welchen Prozessor es geht, konnte ich bloss mein wüssen über die kleinen Amtels preisgeben. Und da weden die Register in Software gesichert. Bei dir scheint es ja in Hardware gemacht zu werden.
Highspeed interrupt toent nach 6809 oder so. Eine Grossvaterschwarte.
Und "Nebliger Pfad" klingt nach Kindergarten-Fasching. Berwertungen sind hier völlig irrelevant. Lass es bitte.
oh sorry, freu mi grad nur so, dass ich den Grund dafür gefunden habe. :) Renesas 32c84 Renesas NC308 Compiler (=C-Compiler) Wenn wer Tipps hat, bitte mitteilen ;)
Das klingt auch alles nach einem C-Assembler (oder irgendeine andere sonstige Hochsprache) Mischmasch. Da gelten dann zum Teil wieder andere Gesetze und man sollte besser genau wissen was man tut. Je nach Prozessor wäre ein Compiler schön blöd, wenn er alle Register sichern würde. Er wird sich natürlich nur auf die Register beschränken, die er selbst in der ISR benutzt. Pfuscht du da jetzt mit Assembler direkt in die Registerbenutzung rein, dann kann es natürlich schon sein, dass du ein Register benutzt, welches der Compiler standardmässig nicht sichert und du dich darum selbst kümmern muss.
Josef schrieb: > Wenn wer Tipps hat, bitte mitteilen Gerne. Den Prozessor bitte ohne Aufforderung mitteilen. Siehe http://www.mikrocontroller.net/articles/Netiquette
Josef schrieb: > Doch ich setzt nach dem Interruptaufrug sofort wieder das I-Flag, damit > höherwertige Interrupts diesen aktuellen Interrupt unterbrechen können. Nö, der kann sich sogar wieder selber unterbrechen. Prioräten in Software nachzubilden, wenn die CPU selber keine Prioritäten hat, ist ziemlich tricky und gefährlich. CPUs mit Prioritätslogik brauchen kein Enablen im Interrupt. Die Prioritätslogik disabled beim Eintritt nur die Interrupts gleicher oder niederer Priorität. Alle höheren bleiben weiterhin enabled. > Werden die register beim Rücksprung zum Hauptprogramm zurückgesichert > oder schon beim setzen des I-Flags??? Dazu müßtest Du erstmal die CPU nennen. Peter
Peter Dannegger schrieb: > Dazu müßtest Du erstmal die CPU nennen. Josef schrieb: > Renesas 32c84
Ein C-Compiler ist nochmal ne völlig andere Baustelle. Da gehen Dich die Register rein garnix an, da kümmert sich der Compiler drum. Pappst Du aber Assembler rein, kann das der Compiler nicht mehr verfolgen, d.h. Du mußt Deine Assemblerregister natürlich auch selber sichern. Für den Compiler ist alles Assemblerreingepappe nur ne Blackbox. Peter
Mir bleibt keine andere Möglichkeit als mit ASM zu arbeiten. Möchte den DMA-Controller konfigurieren und dabei muss ich auf Bank1 wechseln usw. Also, laut Datasheet und meines Wissens unmöglich. Aber Danke für die Kommentare. Habe mir gedacht, es werden alle Register gesichert, dem ist anscheindend nicht so.
Zum Schluss möchte ich jetzt mein Problem mit den soeben gewonnen Erkenntnissen beschreiben. Im Hauptprogramm wird mit float-Zahlen gerechnet. uC verwendet dazu eine Optimierungsmethode mit dem Namen Ofloat_to_Inline, welche das Register R1 verwendet. Im Interrupthandler wird der DMA-Controller konfiguriert. Die Konfiguration erfolgt aber nur mit Assembler. Um den DMAC zu konfigurieren wird das Register R1 benötigt. Nicht der Inhalt sonder der Speicherbereich. Bei einem Interruptaufruf werden nicht alle Register gesichert. Es werden nur die Register gesichert, die der C-Compiler im Interrupthandler erkennt. Da der C-Compiler Assembler-Befehle nicht interpretieren kann, erkennt er auch nicht die Register, die in den Assembler-Befehlen verwendet werden. Somit wird auch nicht das Register R1 beim Interruptaufruf gesichert. LÖSUNG: Man muss sich selbst für die Sicherung der Register, die im Assembler-Code verwendet werden, kümmern. push/pop DANKE an alle für diese schnellen aber für mich sehr wichtigen Antworten. lg
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.