Hallo, wie veranlasse ich den MSP430 innerhalb einer ISR, direkt nach Beendigung selbiger, in den LPM0 zu gehen? Setzt man die LPM0-Bits vor dem RETI, legt er sich in der ISR schlafen, womit dann keine anderen IR mehr bearbeitet werden können... Gruß Fabian
> wie veranlasse ich den MSP430 >>> innerhalb einer ISR, >>> direkt nach Beendigung selbiger >, in den LPM0 zu gehen? Eins geht nur ! Und nach der ISR gehts weiter mit der letzten TASK oder einer anderen ISR ... Ergo: in der TASK in den LPM0 !
Mit IAR geht's so:
1 | __bis_SR_register_on_exit( __SR_GIE | __SR_CPU_OFF); |
Statusregister wird nach Verlassen der ISR geändert. Benutzt man aber eigentlich nur dann innerhalb einer ISR, um einen vor der ISR aktiven LPMx nach Verlassen der ISR nicht automatisch erneut zu aktivieren (__low_power_mode_off_on_exit())
Kann der MSP das von Haus aus oder wird das in Software realisiert ? Sorry, bin von einer "normalen" CPU ausgegangen...
>Kann der MSP das von Haus aus...
Ja, das ist ein kleiner Trick des MSP ;-)
Vor dem Eintritt in eine ISR wird nicht nur der PC (also die
Rücksprungadresse) sondern auch das SR (Statusregister) auf'm Stack
gesichert.
1.)Setzt man nun direkt im SR die jeweiligen Bits für LPMx,
dann geht der MSP sofort schlafen.
2.)Modifiziert man jedoch die Sicherung des SR auf'm Stack,
wird der LPMx erst nach Beendigung der ISR aktiviert.
Der Hauptsinn der Stack-Sicherung des SR besteht darin, dass ein
Interrupt den MSP automatisch aus einem LPMx aufweckt, die ISR ausführt
und danach den zuvor gewählten LPMx ohne weiteres Zutun wieder
aktiviert, weil ja diese gewählte Einstellung im SR auf dem Stack
gesichert wurde und nach der ISR einfach wieder hergestellt wird.
Andere µC werden ähnliche Mechanismen parrat haben...?!
Ich seh das eher von der RTOS Seite. Wird ein Interrupt ausgelöst, der
keine Task weckt, geht die CPU wieder schlafen. Das hörte sich nicht
schlecht an !
> Andere µC werden ähnliche Mechanismen parrat haben...?!
Die müssen (von den mir bekannten) den Sleep wieder neu initialisieren.
> Ich seh das eher von der RTOS Seite. Wird ein Interrupt ausgelöst, der > keine Task weckt, geht die CPU wieder schlafen. Das hörte sich nicht > schlecht an ! >> Andere µC werden ähnliche Mechanismen parrat haben...?! >Die müssen (von den mir bekannten) den Sleep wieder neu initialisieren. Ja, so ein MSP430 ist schon eine coole Sau.
Stefan wrote:
> Andere µC werden ähnliche Mechanismen parrat haben...?!
Die ich kenne, nicht.
Es erscheint mir auch äußerst unpraktisch.
In der Regel will man ja erstmal nachsehen, warum man aufgeweckt wurde
und hat dann einiges zu tun.
Und das möchte man ja nun nicht alles in den Interrupt verfrachten,
vielleicht werden ja noch andere Interrupts gebraucht.
Ich habs daher lieber, wenn der C-Compiler mit möglichst wenig (am
besten keiner) Stack-Rumpfuscherei auskommt. Sowas ist gerne ne
potentielle Fehlerquelle.
Peter
@Peter Dannegger: >Es erscheint mir auch äußerst unpraktisch. Finde ich nicht, warum auch? >In der Regel will man ja erstmal nachsehen, warum man aufgeweckt wurde Kann man doch. In der ISR weiß man ja, warum und durch was man aufgeweckt wurde. >und hat dann einiges zu tun. >Und das möchte man ja nun nicht alles in den Interrupt verfrachten, Wenn man z.B. in der ISR feststellt, dass man eben nichts zu tun hat, braucht man sich um nichts weiter zu kümmern, das ist ja das Praktische! Und wenn doch, beendet man eben in der ISR den LPMx, setzt ein Flag wie üblich und arbeitet im normalen Programm den jeweiligen Task ab, fertig! Danach kann man den MSP bei Bedarf wieder schlafen legen. >vielleicht werden ja noch andere Interrupts gebraucht. Jeder IRQ weckt den MSP aus einem LPMx auf. Und falls ein IRQ Veranlassung dazu gibt den LPMx zu verlassen, sind alle anderen IRQ's danach ja auch aktiv. Ich seh' da jetzt kein Problem. >Ich habs daher lieber, wenn der C-Compiler mit möglichst wenig (am >besten keiner) Stack-Rumpfuscherei auskommt Wenn man den LPMx nicht verlassen will, muss man den Stack gar nicht anfassen. Ansonsten ist das Ändern der SR-Sicherung auf'm Stack kein gepfusche sondern eine gewollte Aktion, die zumindest vom IAR-Compiler perfekt umgesetzt wird. Ich habe da noch nie ein Problem damit gehabt. Generell kann man doch sagen, dass jeder µC irgendwie seine "Eigenarten" hat. Solange diese bekannt und reproduzierbar sind, kann man sich darauf einstellen und richtig darauf reagieren. Das ist das Entscheidende.
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.