Hallo, ich habe ein kleines Problem beim Interrupthandling. Bei den "kleinen" 8Bittern hat man doch am anfang des Interrupts das SREG Register gesichert und beim verlassen wieder zurück geschrieben, damit Berechnungen im Interrupt keine Änderungen an den Flags gemacht haben, oder? Muss man sowas auch bei dem At91Sam machen? Wenn ja, wie geht das. Es gibt dort doch dieses CPSR Register aber wie greife ich darauf zu? Wenn das bei einem normalen Interrupt noch nicht nötig ist, ist es dann vll erst bei einem nested Interrupt notwendig? Mein SAM7X sendet zwischendurch (sehr selten) ein Telegram aus dem Messageobjekt 0 obwohl er dafür garnicht aufgefordert wurde und dieses Messageobjekt ist eigentlich als Receive Programmiert. Da mehrere Interrupts bei dem Controller arbeiten dachte ich mir, dass vll dieses CPSR Register Probleme macht wenn Interrupts von Interrupts unterbrochen werden. Vielleicht kann mir ja jemand helfen und hat auch schon komische Fehler erlebt oder kennt sich etwas besser mit dem Interrupthandling von dem Controller aus. vielen Dank für die Hilfe
Da fällt mir übrigends noch eine wichtige Frage ein die ich hatte. Ich benutze einen Software Interrupt. Dieser ist ja ein SystemInterrupt. Gibt es Probleme beim Debuggen mit diesem Interrupt? Eigentlich nutze ich keine anderen Sachen die den Systeminterrupt nutzen. Wobei ich normal mit dem JTAG Debugge. Nutzt der dann automatisch auch den Software Interrupt?
Jens S. wrote: > Muss man sowas auch bei dem At91Sam machen? Wenn ja, wie geht das. Schreibst du ARM Interrupt Handler in Assembler? Wenn ja, dann sei dir dringend entsprechende Lektüre empfohlen. Vorneweg das ARM Architecture Reference Manual, und es gibt noch ein zweites für die Systemtechnik. Wenn nicht, dann überlass das dem Compiler. Ja nach Compiler steht sowas auch schon mal in dessen Handbuch drin. > Wenn das bei einem normalen Interrupt noch nicht nötig ist, ist es dann > vll erst bei einem nested Interrupt notwendig? Nested Interrupts sind auf ARMs ein ganz besonderes Kapitel, weil dieser Aspekt im Architekturentwurf schlicht übersehen wurde. Auch hier ist das für 2-3 Sätze zu komplex. Handbuch und Internet-Recherche helfen weiter.
> das ARM Architecture Reference Manual, und es gibt noch ein zweites für > die Systemtechnik. Sloss, Symes, Wright: ARM System Developer's Guide
Wenn man schon über "Nested Interrupts nachdenkt", sollte man schon die Architektur verstanden haben! Der SAM7 springt bei einem Interrupt normal in einen anderen Mode (ich habe momentan nicht den für Software Interrupt parat), aber ein Teil der Register wird dann automatisch gesichert, beim Umschalten in den originalen Mode wird wieder zurück gesichert. Besser ist, wenn man die Dokumentation über die Architektur liest, denn ein Interrupt Handling des SAM7 ist nicht gerade trivial.
Danke für die Antworten. Ich lass eignetlich alles vom Compiler machen und arbeite nicht in Assembler. Ich habe den Code nun so umgestellt das ich nicht mehr diesen Softwareinterrupt nutze. Ausserdem war das der Systeminterrupt den ich per Softwarepefehl angetriggert habe, das ist ja glaube ich eigentlich auch noch mal ein unterschied habe ich nun gemerkt. Bei dem recherchieren über das Interrupt handling haben sich noch viele offene Fragen gestellt. Ich arbeite mit KEIL µVision 3 und dem AT91SAM7XC256. Ich habe nun gesehen dass in dem Startupfile diese Spurious Interrupts garnicht abgefangen werden. Ist das nun weiter schlimm? Wenn man die abfängt(Wie überhaupt?) sollte man dort auch irgend etwas machen? Hatte ich das nun so richtig gelesen, dass bei den Atmels ein Spurious Interrupt garnichts macht? Bei anderen Controllern soll er ja dann Interruptvector 0 aufrufen aber bei Atmel doch nichts oder? Ausserdem habe ich was über diesen "Protect Mode" gelesen. Spielt das für mich auch eine Rolle? Ist mein Ulink2 dingen so gesehen ein Debugsystem? Wenn ja wie muss ich den Code dann umstellen das dort AIC_IVR geschrieben und nicht nur gelesen wird? Das Dokument zu ARM - Architecture Reference Manual hatte ich mir mal runter geladen und auch rein geschaut aber hatte nichts für mich brauchbares gefunden. Besonders weil ich ja eigentlich nicht in Assembler arbeiten wollte. Ich hoffe ihr könnt mir noch ein paar Tipps und Tricks zu den Punkte sagen. Vielleicht sogar in verbindung mit der Keil Oberfläche. Gruß, Jens
push :D kennt sich reinzufaellig jemand mit dem CAN Interrupt diese Controllers aus? Mein dickes Problem ist einfach, dass wenn ich Telegramme sende alles ok ist, aber wenn der Controller sendet und auch Telegramme empfängt (jeweils alle 10 ms 4 stück) dann sendet er irgendwann die Daten die in Messageobjekt 1 sind obwohl dieses als Receive Programmiert ist. Hat irgendwer eine Idee wie dies passieren kann? Ich bin für jeden erdenklichen Ratschlag dankbar.
push....vll antwortet ja doch nochmal jemand :(
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.