preemptive und Interrupt
-
Hallo,
es gibt zwei Software-Module auf einem XC164: Applikation und Kommunikation. Das RTOS RTX166 Tiny wird dafür eingesetzt. Zwei Mitarbeiter sollen jeweils an einem Modul arbeiten. Der initiale Wunsch ist eine Trennung der Entwicklung dieser beiden Mitarbeiter. D.h. einer konzentriert sich nur auf Applikation und der andere nur auf Kommunikation. Dieses RTOS ist nicht preemptive. Ich verstehe dies wie folgt:
Befehle können nicht von anderen Interrupt abgebrochen werden. Ist das korrekt?Wenn so ist, braucht man sich um die Integrietät der Variablen nicht zu kümmern.
MfG
Senmeis
-
Senmeis schrieb:
Befehle können nicht von anderen Interrupt abgebrochen werden. Ist das korrekt?
nee, die tasks werde nicht durch 'nen taskswitcher irgendwann unvorhersehbar umgeschaltet (wie bei preemtivem, timergesteuerten multitasking), sondern müssen selber rechenzeit abgeben. interrupts können aber jede task trotzdem unterbrechen.
Senmeis schrieb:
Wenn so ist, braucht man sich um die Integrietät der Variablen nicht zu kümmern.
wenn du variablen hast, die sowohl von interrupt-routinen als auch ausserhalb benutzt werden, musste sicherstellen, dass da nix schiefgeht. wenn du nur variablen hast, auf die verschiedene tasks zugreifen können, dann nicht (weil du ja selbst bestimmen kannst, wann ein taskwechsel erfolgen soll).
-
Vielen Dank für die Erklärung.
Eigentlich haben wir bereits alle nötigen Treiber für die Kommunikationsseite (CAN um genau zu sein) fertiggeschrieben. Nun denke ich mal muss das RTOS das CAN Treiben übernehmen. D.h. unser Treiber muss neu angepasst werden. Wie aufwendig ist diese Anpassung?
MfG
Senmeis
-
Senmeis schrieb:
D.h. unser Treiber muss neu angepasst werden. Wie aufwendig ist diese Anpassung?
ich schätze mal sehr gering. welche aufgabe soll denn das RTOS beim CAN-treiber übernehmen?
-
;fricky schrieb:
Senmeis schrieb:
Senmeis schrieb:
Wenn so ist, braucht man sich um die Integrietät der Variablen nicht zu kümmern.
wenn du variablen hast, die sowohl von interrupt-routinen als auch ausserhalb benutzt werden, musste sicherstellen, dass da nix schiefgeht. wenn du nur variablen hast, auf die verschiedene tasks zugreifen können, dann nicht (weil du ja selbst bestimmen kannst, wann ein taskwechsel erfolgen soll).
wichtig ist es auch, dass wenn man den Interrupt behandelt, der Kontext der laufenden Task (zumindest die Register) gesichert werden, denn sonst kann man nicht garantieren, dass Variablen ihre Werte behalten.
Nun denke ich mal muss das RTOS das CAN Treiben übernehmen. D.h. unser Treiber muss neu angepasst werden. Wie aufwendig ist diese Anpassung?
ich würde sagen, es hängt von der bereits verwendeten API im Code als auch von der Tiny RTOS API ab. Da wir den Code vom Tiny RTOS nicht kennen, noch euren CAN-Code, können wir sehr schlecht beurteilen.
-
supertux schrieb:
wichtig ist es auch, dass wenn man den Interrupt behandelt, der Kontext der laufenden Task (zumindest die Register) gesichert werden, denn sonst kann man nicht garantieren, dass Variablen ihre Werte behalten.
was aber meistens der compiler übernimmt. der fügt in interrupt-routinen entry- und exit-code ein, der die benutzten register sichert und wiederherstellt (deshalb müssen ISRs ja auch als solche deklariert werden).
-
;fricky schrieb:
supertux schrieb:
wichtig ist es auch, dass wenn man den Interrupt behandelt, der Kontext der laufenden Task (zumindest die Register) gesichert werden, denn sonst kann man nicht garantieren, dass Variablen ihre Werte behalten.
was aber meistens der compiler übernimmt. der fügt in interrupt-routinen entry- und exit-code ein, der die benutzten register sichert und wiederherstellt (deshalb müssen ISRs ja auch als solche deklariert werden).
echt? welcher Compiler macht das?
-
supertux schrieb:
echt? welcher Compiler macht das?
fast alle, mit compilerspezifischen erweiterungen, iar, metrowerks, keil usw. das sieht dann etwa so aus:
// z.b. so ... __interrupt void ISR(void) { ... } // oder so... #pragma INTERRUPT void ISR(void) { ... }^^ ich glaub selbst die alten DOS-compiler (turbo-C usw.) konnten das schon.