Folgende Frage: Man kann nicht zufällig beim GCC ISRs doppelt definieren? D.h. wenn sie in einer CDatei.c Datei schon definiert sind, sie in einer anderen andereCDatei.c ergänzen?
Wie soll das funktionieren? Parallel abarbeiten? Wenn die eine früher fertig ist, soll sie dann auf die andere warten oder schonmal mit dem Hauptprogramm weitermachen? Die übliche Frage ist: Wofür glaubst du das zu brauchen?
Dafür, dasss ich den entsprechenden Code, nicht in das andere C File reinkopieren muss. "Der Übersichtlichkeit halber", gerade in meinen speziellen Fall. Ist aber auch kein Problem. Kopiere ich meinen Code in die andere ISR. Danke Dussel!
Der Aufruf einer Funktion geht nicht? So können AUfruf und Funktion in verschiedenen Dateien stehen.
Stefan schrieb: > Dafür, dasss ich den entsprechenden Code, nicht in das andere C File > reinkopieren muss. "Der Übersichtlichkeit halber", gerade in meinen > speziellen Fall. ???
Dussel schrieb: > Wie soll das funktionieren? Parallel abarbeiten? Viel interessanter ist die Frage, welche der beiden Routinen im Falls eines Interrupt Service Requests angesprungen werden soll. Erst die eine und dann die andere? Oder besser andersrum? Oder vielleicht mal die eine und mal die andere, je nach gut Dünken? Da wird man dem Prozessor eine Entscheidungshilfe geben müssen. Die Interrupt-Vektor Tabelle hat nur Platz für einen Eintrag.
Ich glaube er hat sich nur falsch ausgedrückt und will das zwei interrupts in den gleichen Handler springen. Das sollte definitiv gehen.
Nee, die Frage zielt schon auf irgend eine hintereinandergleichzeitig parallel - Magie ab, die der Compiler irgendwie handeln soll. Oliver
NN schrieb: > Viel interessanter ist die Frage, welche der beiden Routinen im Falls > eines Interrupt Service Requests angesprungen werden soll. Beide, auf einem nichtdeterministischer Turingcontroller. Christopher B. schrieb: > Ich glaube er hat sich nur falsch ausgedrückt und will das zwei > interrupts in den gleichen Handler springen. Das glaube ich nicht. Ich habe das so verstanden, dass bei einem Interrupt beides irgendwie ausgeführt werden soll. Deine Interpretation funktioniert auf jeden Fall in Assembler. Das müsste man dann nur dem Compiler irgendwie mitteilen.
@christopher: Das ist Bestandteil der AVRLibc, interrupt.h Beispiel:
1 | #include <avr/interrupt.h> |
2 | ISR(INT0_vect) |
3 | {
|
4 | PORTB = 42; |
5 | }
|
6 | |
7 | ISR_ALIAS(INT1_vect, INT0_vect); |
:
Bearbeitet durch User
Stefan schrieb: > Man kann nicht zufällig beim GCC ISRs doppelt definieren? > > D.h. wenn sie in einer CDatei.c Datei schon definiert sind, sie in einer > anderen andereCDatei.c ergänzen? Eine ISR ist aus Sicht des C-Compilers eine hundsgewöhnliche Funktion ohne Parameter und ohne Rückgabewert. Das besondere an einer ISR ist, daß sie in einer Vektortabelle eingetragen werden muß. Entweder muß da die Startadresse der Funktion in der Tabelle stehen oder ein Sprungbefehl zur Funktion. Die meisten C-Toolchains lösen das Problem dahingehend, daß sie "magische" Namen (richtiger: Signaturen) für die ISR festlegen. Die Auflösung der entsprechenden Symbole macht dann der Linker. Wenn du jetzt eine C-Funktion für eine bestimmte ISR mehrfach in deinem Programm hast, dann wird der Compiler sie auch erstmal brav übersetzen und zwei Funktionen mit der gleichen Signatur erzeugen. Das Problem hat dann der Linker, der eine Referenz auf eine Signatur hat (in der Vektortabelle) und zwei Ziele dafür findet. Das Ergebnis ist eine Fehlermeldung des Linkers über ein duplicate symbol. Langer Rede kurzer Sinn: nein, geht nicht. Was du statt dessen machen mußt: eine einzelne ISR definieren, die dann mehrere Funktionen aus verschiedenen Modulen aufrufen kann. Das kannst du nach Belieben verkomplizieren, z.B. indem sich solche Funktionen als Callback registrieren müssen.
Es geht natürlich schon, nur nicht durch Mehrfachdefinition der ISR-Funtion mit dem fest vorgegebenen Namen, sonder durch eine ISR, die Callbacks verwaltet/ruft, die die Applikation einhängen kann. Damit können unabhängige Software-Teile über das selbe "Ereignis"informiert werden. Allerdings wäre ein typischer Kandidat ein TimerInt und da wären "virtuelle", unabhängige Timer die bessere Lösung. Andere Dinge, wie UART hätten dann eh einen Treiber, der allein mit den INT's zu tun hat.
Oliver S. schrieb: > Nee, die Frage zielt schon auf irgend eine hintereinandergleichzeitig > parallel - Magie ab, die der Compiler irgendwie handeln soll. Dachte ich auch erst. Aber: Stefan schrieb: > Dafür, dasss ich den entsprechenden Code, nicht in das andere C File > reinkopieren muss. "Der Übersichtlichkeit halber", gerade in meinen > speziellen Fall. > > Ist aber auch kein Problem. Kopiere ich meinen Code in die andere ISR. > Danke Dussel! Das kopieren in die andere ISR machte mich stutzig.
Christopher B. schrieb: > Ich glaube er hat sich nur falsch ausgedrückt und will das zwei > interrupts in den gleichen Handler springen. Das sollte definitiv gehen. Ich glaube, es geht genau um den umgekehrten Fall. Ein Interrupt soll zwei Handler haben. Axel S. schrieb: > Stefan schrieb: >> Man kann nicht zufällig beim GCC ISRs doppelt definieren? >> >> D.h. wenn sie in einer CDatei.c Datei schon definiert sind, sie in einer >> anderen andereCDatei.c ergänzen? > > Eine ISR ist aus Sicht des C-Compilers eine hundsgewöhnliche Funktion > ohne Parameter und ohne Rückgabewert. Das besondere an einer ISR ist, > daß sie in einer Vektortabelle eingetragen werden muß. Und dass sie alle Register, die sie benutzt, sichern muss, und dass sie einen anderen Rücksprungbefehl nutzen muss (auf einem AVR, den hier offenbar jeder implizit annimmt, z.B. RETI statt RET). Christopher B. schrieb: > Stefan schrieb: >> Dafür, dasss ich den entsprechenden Code, nicht in das andere C File >> reinkopieren muss. "Der Übersichtlichkeit halber", gerade in meinen >> speziellen Fall. >> >> Ist aber auch kein Problem. Kopiere ich meinen Code in die andere ISR. >> Danke Dussel! > > Das kopieren in die andere ISR machte mich stutzig. Warum? Meine Glaskugel versteht das so, dass er zwei Module hat, die beide auf den selben Interrupt reagieren müssen. Er wollte nun wissen, ob er in beiden Modulen irgendwie separate ISRs für diesen einen Interrupt definieren kann, eben damit das ganze schön modularisiert bleibt. Jetzt hat er sich aus irgendeinem Grund aber wohl doch dazu entschieden, den Code in einer gemeinsamen ISR zusammenzufassen. Er hat also den Code der einen ISR in die andere rüberkopiert und die eine dann komplett rausgeworfen.
:
Bearbeitet durch User
Rolf M. schrieb: > ... und dass sie einen anderen Rücksprungbefehl nutzen muss (auf einem > AVR, den hier offenbar jeder implizit annimmt, z.B. RETI statt RET). Das sagtest du bereits ;-) RETI sichert das Statusregister zurück.
W.A. schrieb: > RETI sichert das Statusregister zurück. Nicht beim AVR8. RETI macht dort primär exakt das gleiche wie RET: 2..3 Bytes (je nach device) vom Stack holen, diese in den PC laden und SP entsprechend inkrementieren. Das einzige, was RETI zusätzlich zu RET tut, ist, das I-Flag im Statusregister zu setzen und damit global (wieder) Interrupts zu erlauben. Die restlichen Bits des Statusregisters werden hingegen von RETI überhaupt nicht angefasst, insbesondere also auch nicht "zurückgesichert". Das ist ein logische Folge der Tatsache, dass sie bei Interruptauslösung auch nicht automatisch "vorwärtsgesichert" werden. Für die Sicherung und Wiederherstellung des Statusregisters ist der Code der ISR selber verantwortlich. Und das ist auch gut so, denn es kann Rechenzeit in erheblichem Umfang sparen, ISRs so zu schreiben, dass der Code darin den Inhalt des Statusregisters erst garnicht nicht ändert, denn dann entfällt komplett die Notwendigkeit, das Statusregister zu sichern.
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.