Hallo, beim Einsprung in den Interrupt ersetzt der ARM die Registerinhalte von SP und LR durch SP_irg und LR_irq. Der SP_irg zeigt auf den Interrupt-Stack, das ist klar. Unklar ist der Inhalt des LR_irq. Die Rücksprungadresse steht im (verborgenen) LR. Offenbar ist der Inhalt des LR_irq beim Einsprung in die ISR bedeutungslos ??? Erst wenn in der ISR zu Unterprogrammen verzweigt wird, erscheint der Inhalt sinnvoll (das schrittweise Durchsteppen ist nur teilweise möglich, d.h. bringt keine richtige Erklärung des CPU-Verhaltens). Der Rücksprung aus dem Interrupt erfolgt mit subs pc, lr, #4. Das wäre mir ebenfalls klar. Aber: das CrossStudio erzeugt nach dem Rücksprung weiteren Code. Wozu? Zum Auffüllen der Pipeline? Die Frage also, gibt es ein passendes Papier, indem des Verhalten des ARM im IRQ etwas ausführlicher beschrieben wird (nicht Assembler Manual und auch nicht das LPC-ARM-Buch von Hitex, das hilft nicht wirklich). MfG Jens
Ergänzung, die Frage nach dem Inhalt des LR_irq beim Einsprung in die ISR ist geklärt (zeigt auf das Ende des __ARMLIB_enableIRQ Makros). MfG Jens
Hast Du schon in die Datenblätter gesehen? http://www.arm.com/documentation/ARMProcessor_Cores/index.html
Falls ich mich nicht verzählt habe sind es 46 unterschiedliche Downloads. Eine sicher höchst interessante Lektüre. Ich bezweifle allerdings dort Erläuterungen zu meiner Frage zu finden. Für die meisten Anwender sollte dieses Thema auch nicht von belang sein, da sich normalerweise der Compiler um die Registerzuweisung kümmert. Ich möchte/will/brauche aber ein äußerst kompaktes und durchschaubares Multitasking für den ARM. Dazu muß ich (leider) an den Registern 'rumfummeln. Im konkreten Fall ist das Problem möglicherweise im Zusammenhang mit dem CrossStudio zu suchen, d.h. im Debugging Mode arbeitet mein Beispiel so wie es soll (also so wie ich meine, daß es funktionieren muß), ohne CrossStudio geht es halt nicht. MfG Jens
Die ARM-Dokumentation nach "nested Interrupts" zu durchsuchen, sollte brauchbare Information bringen. Im Moment leider keine konkrete URL zur Hand, aber die Funktion der Stackpointer und Linkregister bei den verschiedenen Interrupts wird in diesem Zusammenhang gut erklaert. FreeRTOS-Ansatz nicht kompakt genug? Nur aus Interesse: warum "muss" an den Registern "rumgefummelt" werden? Martin
@FreeRTOS und Co. zu aufwendig? Ich verwende sehr gern das Minimalmultitasking UEXC von Richard Man. Mittlerweile habe ich es auf weitere µC portiert. Das ist genau das was ich brauche. Nur leider ist die Portierung auf den ARM nicht (?) möglich/zu aufwendig. In praktisch allen meinen Embedded Applikationen kann die zu lösende Aufgabe in zwei Komponenten zerlegt werden; schnelle Funktionen mit harten Echtzeitanforderungen und Funktionalitäten mit hohem Rechenaufwand, meist in der Ausführungszeit deutlich unkritischer. Der erste Part landet entweder direkt in der ISR oder wird in kooperativ arbeitende zyklisch laufende Schnippselchen zerlegt, z.B. Aufruf in einem Raster von ca. 25 ms. Komplexe Algorithmen in kurze Sequenzen zu zerlegen ist in der Regel aufwendig; hier ist es schön, gelingt es die Arbeit in eine "endless loop" zu verpacken. Ist eine Kommunikation zwischen Funktionen nötig, werden die Schnittstellen entsprechend definiert, die Vorzüge von verfügbaren Semaphoren oder Message-Queues greifen nur bedingt. Nicht zu letzt ist die Sicherheit und Testbarkeit ein wichtiges Kriterium. Je nach Anforderung der Applikation muß ich bei Verwendung zusätzlicher Komponenten diese auch zusätzlich testen. Mit anderen Worten ich steige dann ziemlich tief in ein mir fremdes Programm ein. @Register fummeln Die Grundfunktionen eines Multitasking-Systems beinhalten das Starten eines neuen Tasks bzw. den Context-Switch zwischen zwei aktiven Tasks. Im Regelfall erfolgt dies in einer ISR. Zum Start eines neuen Tasks muß diesem im Minimum ein eigener Stackbereich zugewiesen werden. Oft "bastelt" man deshalb einen Interrupt-Return Stack, verläßt dann mit reti die ISR und der neue Task holt sich seine Werte vom Stack. Beim ARM geht dies nicht ganz so einfach. Ein reti gibt es dort nicht. Ich muß also den SP und das LR definiert setzen und dann das Prozessor-Mode-Register (CPSR) einstellen. Und genau da liegt der Hase im Pfeffer. Wenn ich das so mache wie ich der Meinung bin, es tun zu sollen, funktioniert es nur solange ich über JTAG debugge. Ohne Debugger gehts halt nicht. Im Context-Switch muß ich mich wieder an den Registern vergreifen. Zuerst werden die "alten" Register auf dem "alten" Stack gesichert, dann der neue Kram vom neuen Stack geholt - ISR verlassen und wie von Zauberhand ist der neue Task aktiv. So die Theorie. Gehen tuts halt nur mit Debugger... Bleibt die Frage zu klären warum ich mir dies antue? Ein fertiges RTOS und los gehts, oder nicht? Nun, um es ganz klar zu stellen, ich bin nicht gegen fertige Lösungen, aber lieber teste und suche ich die Fehler jetzt, als später mit Schweißperlen auf der Stirn ein riesen System umzugraben, weil es manchmal/immer/selten abschmiert ohne mir zu sagen warum. MfG Jens
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.