Forum: Mikrocontroller und Digitale Elektronik ARM AT91SAM7X Interrupthandling + CPSR + nested Interrupts


von Jens S. (Gast)


Lesenswert?

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

von Jens S. (Gast)


Lesenswert?

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?

von Andreas K. (a-k)


Lesenswert?

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.

von PS (Gast)


Lesenswert?

> das ARM Architecture Reference Manual, und es gibt noch ein zweites für
> die Systemtechnik.

Sloss, Symes, Wright: ARM System Developer's Guide

von Heiko S. (Gast)


Lesenswert?

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.

von Jens S. (Gast)


Lesenswert?

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

von Jens S. (Gast)


Lesenswert?

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.

von Jens (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.