mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Kooperatives Multitasking und Interrupt?


Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
wenn ich kooperatives Multitasking fahre, kann die aktuell laufende Task 
durch einen Interrupt (nicht vom Timer, aber z.B. ein Interrupt von 
einem angeschlossenen Gerät) unterbrochen werden?

Eigentlich heißt kooperativ ja, dass es keine Unterbrechung gibt, die 
die Task nicht selbst verursacht, aber wie funktioniert ein System sonst 
ganz ohn Interrupts?

MfG
Jan

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kooperatives MT heisst, dass keine Task durch eine andere Task 
unterbrochen wird, ausser an den Stellen wo dies ausdrücklich zugelassen 
wird.

Interrupts sind davon nicht betroffen und unterbrechen auch da an den 
unmöglichsten Stellen. Der Unterschied liegt genau darin, dass bei 
kooperativem MT der Interrupt stets dorthin zurückkehrt wo er herkam, 
bei präemptivem MT hingegen an dieser Stelle ein Taskwechsel erfolgen 
kann.

Autor: EGS_TI (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, der Thread ist alt. Aber so kann ich das nicht stehen lassen.

In einem reinen kooperativen Multitasking Betriebssystem für 
Mikrocontroller wird ein Task auf keinen Fall von einem Interrupt 
unterbrochebn.
In einem solchen System ist nur ein einziger Interrupt aktiv und das ist 
ein beliebiger Timer-Interrupt, der für die Tick-Erzeugung zuständig 
ist.
Alles andere wird gepollt und auf keinen Fall mit Interrupts gehandhabt.

Autor: xfr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nö. Gegenbeispiel: TinyOS.

Autor: gnd3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, aber...?
Der Timer-Interrupt unterbricht die Tasks nicht?
Und ein anderer Interrupt (z.B. UART) würde sich wie genau von einem 
Timer-Interrupt unterscheiden?
Und vor allem: warum, wer verbietet andere Interrupts?

Autor: EGS_TI (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weil die Vorhersagbarkeit des Systems darunter leidet.

Autor: EGS_TI (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gnd3 schrieb:
> Ja, aber...?
> Der Timer-Interrupt unterbricht die Tasks nicht?
> Und ein anderer Interrupt (z.B. UART) würde sich wie genau von einem
> Timer-Interrupt unterscheiden?
> Und vor allem: warum, wer verbietet andere Interrupts?

Es wird ein fester Intervall mit dem Timer erzeugt, z.B. 10 ms.
Jeder Task muss dann kürzer als diese 10 ms + OS-Overhead sein.

Dann unterbricht sich nämlich überhaupt nichts.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
EGS_TI schrieb:
> Jeder Task muss dann kürzer als diese 10 ms + OS-Overhead sein.
>
> Dann unterbricht sich nämlich überhaupt nichts.

Kooperatives Multitasking impliziert aber keine maximalen Taskdauern. 
Außerdem verbrät Dein Modell Rechenzeit, wenn viele sehr "kurze" Tasks 
abgearbeitet werden.

Nicht, daß diese Vorgehensweise nicht ihre Daseinsberechtigung hätte, so 
kann man Echtzeitkriterien einhalten, so macht es jede SPS, aber 
kooperatives Multitasking ist was anderes.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. Firefly schrieb:
> Kooperatives Multitasking impliziert aber keine maximalen Taskdauern.

Eben, das ist ja das Problem daran - ein nicht kooperierender Task kann 
das System zum Stillstand bringen. So ist echtes Real Time unmöglich.

Logisch ist: Interrupts stören das kooperative Multitasking überhaupt 
nicht, sie begrenzen nur die Real Time Fähigkeit. Da kMT-Systeme aber 
sowieso nicht realtimefähig sind, spielt das keine Rolle, 
hardwareorientierte Interrupts wie Bedienung von Schnittstellen sind 
ohne weiteres möglich, und in Bezug auf die Laufzeit müssen sie auch 
nicht besser sein als die Zeitscheiben der Tasks.

Gruss Reinhard

PS im Gegenteil, ein gut designtes Interruptsystem kann dafür sorgen, 
dass Wartezeiten in den Tasks nicht auftreten und das System viel 
flüssiger läuft - ohne wirklich Real Time zu werden.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
EGS_TI schrieb:
> In einem reinen kooperativen Multitasking Betriebssystem für
> Mikrocontroller wird ein Task auf keinen Fall von einem Interrupt
> unterbrochebn.

Wo hast du denn diese Weisheit her?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik)

>Eben, das ist ja das Problem daran - ein nicht kooperierender Task kann
>das System zum Stillstand bringen. So ist echtes Real Time unmöglich.

Dann ist dein Task buggy.

>Logisch ist: Interrupts stören das kooperative Multitasking überhaupt
>nicht, sie begrenzen nur die Real Time Fähigkeit. Da kMT-Systeme aber
>sowieso nicht realtimefähig sind,

So ein Käse.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Dann ist dein Task buggy.

Natürlich, aber im echten Leben kommt das halt vor. Du hast den 
Unterschied zwischen kooperativ und präemptiv offensichtlich nicht 
verstanden, vor allem nicht wozu das gut sein soll. Aber das kann hier 
in diesem Task nicht geklärt werden, das ist ein Thema für sich.

Gruss Reinhard

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik)

>> Dann ist dein Task buggy.

>Natürlich, aber im echten Leben kommt das halt vor.

Sicher, genauso wie dein präemtiver Scheduler buggy sein kann. Blue 
Screen & Co.

> Du hast den
>Unterschied zwischen kooperativ und präemptiv offensichtlich nicht
>verstanden,

Wenn du meinst.

> vor allem nicht wozu das gut sein soll. Aber das kann hier
> in diesem Task nicht geklärt werden, das ist ein Thema für sich.

Die Frage des OP wirde doch schon in der 1. Anwort hinreichend geklärt, 
und das vor 5 Jahren

Beitrag "Re: Kooperatives Multitasking und Interrupt?"

Der Leichenfledderer hat nur Verwirrung gestiftet und zusätlich falsche 
Aussagen getroffen.

>In einem reinen kooperativen Multitasking Betriebssystem für
>Mikrocontroller wird ein Task auf keinen Fall von einem Interrupt
>unterbrochebn.

Quark.

>In einem solchen System ist nur ein einziger Interrupt aktiv und das ist
>ein beliebiger Timer-Interrupt, der für die Tick-Erzeugung zuständig
>ist.

Viel zu spezieller Fall eines kooperativen Multitasking.

>Alles andere wird gepollt und auf keinen Fall mit Interrupts gehandhabt.

Quark die IIte.

Naja, und das der Begriff "echtes Real Time" dehnbarer als ein Kaugummi 
ist, macht die Sache nicht einfacher.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
>>Natürlich, aber im echten Leben kommt das halt vor.
>
> Sicher, genauso wie dein präemtiver Scheduler buggy sein kann.

Das ist es eben, was du nicht verstehst: eine Task ist NICHT Bestandteil 
des Betriebssystems, das BS soll aber weiterlaufen auch bei einer 
fehlerhaften Task. Wer unter 16bit-Windows kooperativ entwickelt hat und 
bei jeder unbeabsichtigten Endlosschleife den Rechner neu booten musste, 
weiss was das wert ist.

Ich glaube auch nicht, dass ich mit dieser Meinung allein stehe, 
auffallenderweise gibt es praktisch kein BS mit kooperativem MT mehr. 
Oder sind alle Windows-, Linux-, Solaris usw. Entwickler bloss zu blöd?

Der wesentliche Punkt bei Real Time ist übrigens nicht die Zeit, trotz 
der Namensgebung, sondern die Garantie dafür, und da gibt es nichts zu 
dehnen. Ein kooperatives System kann garnichts garantieren.

Gruss Reinhard

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik)

>> Sicher, genauso wie dein präemtiver Scheduler buggy sein kann.

>Das ist es eben, was du nicht verstehst: eine Task ist NICHT Bestandteil
>des Betriebssystems, das BS soll aber weiterlaufen auch bei einer
>fehlerhaften Task.

Das ist mir schon klar, nichts desto trotz kann ein blockierender Fehler 
AUCH im Betriebssystem stecken, wenn gleich die Wahrscheinlichkeit mit 
der Zeit der Entwickung und Nutzung selbigem kleiner wird.

> Wer unter 16bit-Windows kooperativ entwickelt hat und
>bei jeder unbeabsichtigten Endlosschleife den Rechner neu booten musste,
>weiss was das wert ist.

Weiß ich auch, geht aber am Problem vorbei. PCs sind heute nicht mehr 
Nutzer kooperativen Multitaskings, kleine Mikrocontroller schon.

>Ich glaube auch nicht, dass ich mit dieser Meinung allein stehe,
>auffallenderweise gibt es praktisch kein BS mit kooperativem MT mehr.

Eben.

>Der wesentliche Punkt bei Real Time ist übrigens nicht die Zeit, trotz
>der Namensgebung, sondern die Garantie dafür, und da gibt es nichts zu
>dehnen. Ein kooperatives System kann garnichts garantieren.

Mann hat du einen Tunnelblick!

Einfacher Gegenbeweis.

http://www.mikrocontroller.net/articles/Multitaski...

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> Rufus Τ. Firefly schrieb:
>> Kooperatives Multitasking impliziert aber keine maximalen Taskdauern.
>
> Eben, das ist ja das Problem daran - ein nicht kooperierender Task kann
> das System zum Stillstand bringen.

Beim präemptiven Multitasking mit Realtime gilt das auch, sofern es 
keine anderen Tasks mit gleicher oder höherer Priorität gibt. Mit 
hochprioren Tasks, die sich in irgendeine Schleife verrennen, kannst du 
auch jedes präemptive Realtime-System zum Sterben bringen. Das geht ja 
auch gar nicht anders. Wenn hochpriore Tasks einfach so durhc 
niederpriore unterbrochen werden können (was bei 
Desktop-Betriebssysstemen auch der Fall ist), ist tatsächlich kein 
Realtime möglich.

> So ist echtes Real Time unmöglich.

Daß ein fehlerhaftes Programm nicht so funktioniert, wie gewünscht, 
verwundert nicht besonders. Daraus kann man aber nicht schließen, daß 
dann gar keins so funktioniert, wie gewünscht.

Reinhard Kern schrieb:
> Falk Brunner schrieb:
>>>Natürlich, aber im echten Leben kommt das halt vor.
>>
>> Sicher, genauso wie dein präemtiver Scheduler buggy sein kann.
>
> Das ist es eben, was du nicht verstehst: eine Task ist NICHT Bestandteil
> des Betriebssystems, das BS soll aber weiterlaufen auch bei einer
> fehlerhaften Task.

Was ist denn "das Betriebssystem"? Auch nix anderes als Tasks, und noch 
ein paar ISRs.

> Wer unter 16bit-Windows kooperativ entwickelt hat und
> bei jeder unbeabsichtigten Endlosschleife den Rechner neu booten musste,
> weiss was das wert ist.

Und wer unter Linux+Xenomai (also einem präemptiven System) 
Realtime-Software entwickelt, weiß den Xenomai-Watchdog zu schätzen, der 
hängende Tasks nach einer wählbaren Anzahl von Sekunden abschießt, eben 
auch, damit man nicht immer das System neu booten muß. Denn alle 
Betriebssystem-Tasks, bis hin zur Auslagerung, sind natürlich 
niederpriorer als alle Realtime-Tasks.

> Der wesentliche Punkt bei Real Time ist übrigens nicht die Zeit, trotz
> der Namensgebung, sondern die Garantie dafür, und da gibt es nichts zu
> dehnen. Ein kooperatives System kann garnichts garantieren.

Das System alleine kann sowieso nichts garantieren, und Programme kann 
man immer so schreiben, daß sie die Echtzeit-Anforderungen nicht 
erfüllen. Das hat aber nichts damit zu tun, ob der Scheduler kooperativ 
oder präemptiv ist.

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
EGS_TI schrieb:
> Ja, der Thread ist alt. Aber so kann ich das nicht stehen lassen.
>
> In einem reinen kooperativen Multitasking Betriebssystem für
> Mikrocontroller wird ein Task auf keinen Fall von einem Interrupt
> unterbrochebn.
> In einem solchen System ist nur ein einziger Interrupt aktiv und das ist
> ein beliebiger Timer-Interrupt, der für die Tick-Erzeugung zuständig
> ist.
> Alles andere wird gepollt und auf keinen Fall mit Interrupts gehandhabt.

Ich glaube da hat @EGS_TI kooperatives Multitasking mit Time-Triggered 
Systemen verwechselt, was er beschreibt passt genau dazu... 
(http://www.tte-systems.com/technology)

Gruß,
Bernhard

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ein Echtzeitsystem nur mittels koopMT zu machen halte ich (wie 
erwähnt) für äusserst kritisch, denn nur ein Übeltäter-Task kann (wie 
erwähnt) schnell alles lahm legen.
Wenn man kein complett preemt.MT machen will, kann man aber doch 
kooperative (typ.weise nicht zeitkritische) Tasks mit niedriger INT-Prio 
laufen lasssen,
und zeitkritischere 'Tasks' über ISRs abhandeln. Je höher die 
Zeitanforderung, desto höher die INT-Prio.

Autor: Peter Binder (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:
> und zeitkritischere 'Tasks' über ISRs abhandeln. Je höher die
> Zeitanforderung, desto höher die INT-Prio.

kann man die INT-Prio eigentlich verändern? Die Rangfolge der 
Auslösungen ist ja statisch festgelegt und die Sprungadressen auch, also 
nicht änderbar?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Binder schrieb:
> kann man die INT-Prio eigentlich verändern?

Man kann sie in Teile gliedern. Nicht unüblich: Der erste hoch 
priorisierte Handler macht nur das absolut Nötigste und löst den zweiten 
niedriger priorisierten Interrupt aus. Je nachdem was grad pending ist 
kommt der gleich nach dem Return dran, oder später.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein kooperative MT System ist schneller, da der Preemptive Mechanismus 
wegfaellt. Denn
-da keine Task geswappt werden brauchen die Task auch keinen eigenen 
Stack
-Man muss nicht alle Variablen mit Semaphoren schuetzen, denn man weiss 
ja wann gewechselt wird.
-Jeder Semaphorenschutz einer Variablen kann zu einem Taskwechsel 
fuehren.

kooperative MT Systeme brauchen einen besseren Ueberblick, und eine 
bessere Optimierung, sodass kein Task alles blockiert.

Deshalb schreibe ich jede Zeitscheibe
-nur einen Character auf's LCD.
-wird nur ein ADC kanal verarbeitet, gesampelt wird eh mit einem 
langsameren timing.
-dynamisches Memory gibt's nicht
+Fehler gibt's nicht, dh muessen alle weg.

Daher gibt es eine Obergrenze an Komplexitaet mit der ein kooperatives 
MT System sinnvoll einsetzbar ist. Oberhalb waere dann preemptive MT 
angesagt.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:
> Also ein Echtzeitsystem nur mittels koopMT zu machen halte ich (wie
> erwähnt) für äusserst kritisch, denn nur ein Übeltäter-Task kann (wie
> erwähnt) schnell alles lahm legen.

Allerdings löst sich (wie erwähnt) dieses Problem bei präemptivem 
Multitasking nicht einfach in Luft auf.

> Wenn man kein complett preemt.MT machen will, kann man aber doch
> kooperative (typ.weise nicht zeitkritische) Tasks mit niedriger INT-Prio
> laufen lasssen,
> und zeitkritischere 'Tasks' über ISRs abhandeln. Je höher die
> Zeitanforderung, desto höher die INT-Prio.

Das finde ich unsauber. ISRs und Tasks sollten sauber getrennt bleiben, 
und ISRs sollten so kurz wie möglich sein. D.h. wenn irgendwo Daten 
ankommen, die zur Auslösung eines Interrupts führen, wird in der ISR 
z.B. über eine Semaphore ein Task "ent-blockiert", der dann die 
angekommenen Daten verarbeitet. Über die Prioritäten der Tasks kann man 
dann einstellen, in welcher Reihenfolge diese Verabeitung erfolgt, wenn 
mehrere Interrupts quasi gleichzeitig ausgelöst werden. Das geht dann 
auch bei Prozessoren, die keine einstellbaren Interrupt-Prioritäten 
haben.

Peter Binder schrieb:
> MCUA schrieb:
>> und zeitkritischere 'Tasks' über ISRs abhandeln. Je höher die
>> Zeitanforderung, desto höher die INT-Prio.
>
> kann man die INT-Prio eigentlich verändern?

Das hängt vom Prozessor bzw. Interrupt-Controller ab.

> Die Rangfolge der Auslösungen ist ja statisch festgelegt und die
> Sprungadressen auch, also nicht änderbar?

Sagt wer?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieben von Neun schrieb:
> -da keine Task geswappt werden brauchen die Task auch keinen eigenen
> Stack

Auch bei kooperativem MT werden Tasks umgeschaltet. Der Unterschied 
besteht nur darin, wo genau das stattfindet. Es gibt zwar Systeme mit 
kooperativem MT, die wie etwa Dunkels Protothreads ohne Stack pro Task 
auskommen, das sind aber die Ausnahmen, die zudem mit beträchtlichen 
Einschränkungen daher kommen. Bei den üblichen Systemen ist weiterhin 
pro Task ein Stack erforderlich, da der Taskswitch zwar nicht an jeder 
Stelle im Programm stattfinden kann, aber an so ziemlich jeder Stelle im 
Stack.

Autor: heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber bei kMT bestimmt die Task wann umgeschaltet wird und weiss deshalb 
was sie retten muss. Uch mach ab znd zu mal Echtzeit und finde da 
eigentlich kMT besser zu händeln. Das funktioniert aber nur solange wie 
jedes Stück Software das läuft von mir ist bzw. einsehbar ist.

>Bei den üblichen Systemen ist weiterhin
pro Task ein Stack erforderlich, da der Taskswitch zwar nicht an jeder
Stelle im Programm stattfinden kann, aber an so ziemlich jeder Stelle im
Stack.

versteh ich den 2. Teil nicht

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
heinz schrieb:
>>Bei den üblichen Systemen ist weiterhin
> pro Task ein Stack erforderlich, da der Taskswitch zwar nicht an jeder
> Stelle im Programm stattfinden kann, aber an so ziemlich jeder Stelle im
> Stack.
>
> versteh ich den 2. Teil nicht

Es wird dabei u.U. bei bestimmten System-calls (z.B. blockierendes 
Lesen, und auf das Gerät muss gewartet werden) auch ein Taskwechsel 
gemacht. D.h. es passiert nicht an jeder Stelle (man weiß genau bei 
welchen calls), kann aber an jeder Stelle im Stack passieren (in 
beliebiger Unterprogramm-Aufruftiefe).

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
heinz schrieb:
> Aber bei kMT bestimmt die Task wann umgeschaltet wird und weiss deshalb
> was sie retten muss.

Die Umschaltung erfolgt in der Regel in irgendwelchen API-Funktionen des 
Systems. Die wissen aber nichts davon, was der Aufrufer noch so alles 
auf dem Stack liegen hat.

> Uch mach ab znd zu mal Echtzeit und finde da eigentlich kMT besser zu
> händeln. Das funktioniert aber nur solange wie jedes Stück Software das
> läuft von mir ist bzw. einsehbar ist.

Dann mag das gehen, aber eine saubere Trennung von Programm und 
Scheduler kann ich mir so nicht recht vorstellen.

Autor: heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
okay - ich hab den stack als Speicher verstanden.

>bei bestimmten System-calls (z.B. blockierendes
deshalb sag ich ja
>jedes Stück Software das läuft

1. kann ich sowas vermeiden (zumindest versuchen)
2. wenn der handler von mir ist, ist der auch kooperativ

Anderes beispiel malloc - die gibts in Echtzeit nicht. Alles statisch

Oder wie schon oben geschrieben - SPS.
Die ist zumindest weiche Echtzeit und kann relativ hart programmiert 
werden.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das finde ich unsauber. ISRs und Tasks sollten sauber getrennt bleiben,
>und ISRs sollten so kurz wie möglich sein. D.h. wenn irgendwo Daten
>ankommen, die zur Auslösung eines Interrupts führen, wird in der ISR
>z.B. über eine Semaphore ein Task "ent-blockiert", der dann die
>angekommenen Daten verarbeitet. Über die Prioritäten der Tasks kann man
>dann einstellen, in welcher Reihenfolge diese Verabeitung erfolgt, wenn
>mehrere Interrupts quasi gleichzeitig ausgelöst werden. Das geht dann
>auch bei Prozessoren, die keine einstellbaren Interrupt-Prioritäten
>haben.
- Ein Interrupt-Controller (sofern vorhanden) ist gerade dazu da, 
niedriger prio INTs von der Hardware fern zuhalten. Aus diesem Grund 
macht es gerade keinen Sinn bei eintreffen eines INTs nur den passenden 
Task anzuwerfen und sofort die aktuelle INT-Prio zurück zu setzen.

- Je 'sauberer' man es programmiert desto mehr Overhead ist auch 
vorhanden. Wenn schon eine Task nur bei Eintreffen eines bestimmten INTs 
aufgerufen werden soll, und man diese Task direkt von dem INT ausführen 
lässt, kann man sich die explizite Zuweisung der Task-Priorität an den 
Task eigentlich ersparen, weil der INT sowiso schon die betreffende Prio 
hat.

>Oder wie schon oben geschrieben - SPS.
Die ist norm total simpel, weil nur eine Zeitscheibe erforderlich. Für 
typ. SPS-Programme bräuchte man nichtmal INT-Funktion, geschweige denn 
verschiedene INT-Prioritäten.

Autor: DO-178C (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> Der wesentliche Punkt bei Real Time ist übrigens nicht die Zeit, trotz
>
> der Namensgebung, sondern die Garantie dafür, und da gibt es nichts zu
>
> dehnen. Ein kooperatives System kann garnichts garantieren.

Falsch.

Gegenbeispiel: Wir verwenden für ein Flight Control System (großes 
Flugzeug, Zulassung) kooperatives non-preemtive multitasking. Abgesehen 
davon wird bis auf einen Timer-Interrupt kein weiterer verwendet.
Die formalen Nachweise, die für eine Zertifizierung erbracht werden 
müssen sind bei der Verwendung von Interrupts schwer bis unmöglich 
nachzuweisen.

Autor: heinzh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nochmal SPS
Nehmen wir mal an ich programmier in der keine Sprünge und keine Alarm 
Bausteine ( = Interupt) Dann ist deren Laufzeit komplett voraussagbar. 
Das ist ein BS in dem nur eine Task läuft.

nochmal preempetiv gegen kooperativ
Wenn die Task die Kontrolle freiwillig abgibt dann kann sie vorher ihren 
Zustand selbst retten und entlastet den Scheduler (sofern vorhanden.

ich hab das schon so realisiert
6 Tasks - jede hat genau ein Doppelwort DD TASKn
wenn Task1 beendet ist rettet sie ihren Zustand und springt zu Task2

push ..
push..
mov ebx,[offs1]
mov TASK1,ebx

mov ebx,TASK2
jmp ebx
offs1:

ich denk mal das ist der "Scheduler" mit den geringst möglichen Kosten

und die Laufzeit ist zumindest halbwegs berechenbar (worst case)
ist beim 80x86 eh nicht richtig machbar weil zB. cache miss usw.

im Gegensatz dazu muß beim Taskwechsel über einen Timer alles gerettet 
werden
das ist beim 80x86 ne Menge

Autor: casud (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>
> im Gegensatz dazu muß beim Taskwechsel über einen Timer alles gerettet
> werden
> das ist beim 80x86 ne Menge

Naja 8 Register + 3-5 die automatisch gepusht werden sind im vergleich 
zu anderen Architekturen geradezu lächerlich.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DO-178C schrieb:
> Gegenbeispiel: Wir verwenden für ein Flight Control System (großes
> Flugzeug, Zulassung) kooperatives non-preemtive multitasking.

Also ihr schreibt die ganze Software - davon rede ich nicht, sondern 
davon, dass BS aus einer und die Apps aus anderen Händen kommen, und 
dann sollte das BS möglichst nicht von fehlerhaften Apps in 
Mitleidenschaft gezogen werden.

Schön wenn ihr so erfolgreich zusammenarbeitet, aber das ist nicht immer 
der Fall, nicht einmal in derselben Firma muss das so sein. Und generell 
schadet Fehlertoleranz ja nicht, ausser dem nötigen Aufwand.

Gruss Reinhard

Autor: Hondo Schnell (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Also ihr schreibt die ganze Software - davon rede ich nicht, sondern
davon, dass BS aus einer und die Apps aus anderen Händen kommen, und
dann sollte das BS möglichst nicht von fehlerhaften Apps in
Mitleidenschaft gezogen werden.

Unbekannte Apps... ja. Dann ist das kooperative MT schon weg.
kMT bedeutet zwingend alles aus einem Guss.

Schwierig wird es mit dynamischem Speicher. Denn der besteht nur einmal, 
und ist daher eine Resource, deren Zugriff gelock werden muss. Das kann 
man umgehen, indem man jedem Task einen eigenen Heap aus dem grosszuegig 
bemessenen Speicher fest zuweisen kann.

Autor: heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Naja 8 Register + 3-5
+ float
+ ein paar flags +++

>Schwierig wird es mit dynamischem Speicher.
Daher wenn iw machbar statisch.

@Reinhard Kern
wie erhöhst Du die Fehlertoleranz bei einem Echtzeitsystem ?

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
heinz schrieb:
> wie erhöhst Du die Fehlertoleranz bei einem Echtzeitsystem ?

wieso erhöhen, verglichen womit? das BS darf einer Task natürlich nur 
eine maximale Zeitscheibe erlauben - so "echtzeitig" ist eben dann das 
System. Das ist doch wohl fester Bestandteil jedes ernstzunehmenden 
RTOS, und im übrigen ja die Definition von Präemptiv. Die Task kann ja 
ruhig in einer Endlosschleife laufen, sie wird halt nach der 
garantierten maximalen Latenzzeit abgebrochen und darf ihre 
Endlosschleife irgendwann später fortsetzen. Dieses Zeitverhalten gehört 
ja zu den wesentlichen technischen Daten, die der RTOS-Hersteller 
garantieren muss.

Ist ja eigentlich sehr einfach: kann das BS eine Task, die sich nicht 
freiwillig selbst unterbricht, nicht mit Gewalt beenden (ist das BS also 
nicht präemptiv), so kann vom BS auch keine maximale Reaktionszeit 
garantiert werden - es ist also nicht echtzeitfähig.

Man kann ja, wenn man die gesamte Software erstellt, schon ein 
bestimmtes Zeitverhalten erreichen (oder wenigstens dran glauben), aber 
dadurch wird das Betriebssystem ja kein Echtzeit-BS.

Gruss Reinhard

Autor: heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hab das auf deine Aussage
>Und generell schadet Fehlertoleranz ja nicht, ausser dem nötigen Aufwand.
bezogen.

Das was Du beschreibst ist ein BS für ein Desktop

Ein RTOS hat ganz andere Anforderung. Nicht nur das Einhalten von 
Deadtime
Und ja wenn ich die Software komplett schreibe kann ich immer ein 
Zeitverhalten errechnen. Wenn ich nur zyklische Tasks hab ist das 
relativ einfach. Bei azyklischen hab ich dann eben einen worst case. Ob 
man das aber ein BS nennen kann???

Mir gings eigentlich um den overhead den RTOS bei der Taskumschaltung 
bringt.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik)

Na, suchst du mal wieder krampfhaft nach Ausreden für deine 
Falschaussagen? Echte Männer (tm) würden einfach ihren Fehler zugeben.

Und nein, es gibt durchaus kooperative Multitasking Betriebssystem, wo 
Applikationen und Betriebssystem nicht aus einer Hand kommen, und die 
dennoch sehr gut echtzeitfähig und sicher sind. Dein Tunnelblick, der 
nur PCs und dein begrenztes Erfahrungsfeld kennt, lässt das aber nicht 
zu.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, bei einem wirklich rein kooperativenMultitaskingBetriebssystem 
(bei dem sonst wirklich nichts zugelassen ist) kann in der Tat ein 
falscher Task das Ding lahm legen. Das muss aber nicht zwingend heissen, 
dass dort auch ein fehlerhafter Task vorhanden ist. Je nach BS ist die 
Wahrscheinlichkeit mehr oder weniger gross. (Bei Win98 war es extrem, 
aber das interessiert nat in der uC Welt keinen). (Aber auch jedes 
andere BS kann Fehler haben -wo auch immer- weshalb es dann doch hängen 
bleibt.


>Man kann ja, wenn man die gesamte Software erstellt, schon ein
>bestimmtes Zeitverhalten erreichen (oder wenigstens dran glauben), aber
>dadurch wird das Betriebssystem ja kein Echtzeit-BS.
Doch. Echtzeit ist es dann, wenn der Schreiber (oder Entwickler) der das 
Gerät rausbringt garantieren kann, dass die Zeitbedingungen erfüllt 
werden, völlig wurscht wie die BS-Architektur ist (Selbst wenn überhaupt 
kein uC drin sitzt). (So wie der Barkeeper inner Disco garantieren muss, 
spätestens nach 2 Minuten das Bier zu bringen, egal nach welchem 
Algorithmus)

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:
> Doch. Echtzeit ist es dann

Echtzeit ja, Echtzeit-BS nein. Bitte Begriffe auseinanderhalten.

Autor: Fritz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> Echtzeit ja, Echtzeit-BS nein. Bitte Begriffe auseinanderhalten.

Bevor man sie auseinanderhalten kann, sollte man sie erst definieren, 
dann diskutiert es sich viel leichter!

Autor: EGS_TI (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

DO-178C schrieb:
> Falsch.
>
> Gegenbeispiel: Wir verwenden für ein Flight Control System (großes
> Flugzeug, Zulassung) kooperatives non-preemtive multitasking. Abgesehen
> davon wird bis auf einen Timer-Interrupt kein weiterer verwendet.
> Die formalen Nachweise, die für eine Zertifizierung erbracht werden
> müssen sind bei der Verwendung von Interrupts schwer bis unmöglich
> nachzuweisen.

;)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Fritz (Gast)

>>Reinhard Kern schrieb:
>> Echtzeit ja, Echtzeit-BS nein. Bitte Begriffe auseinanderhalten.

>Bevor man sie auseinanderhalten kann, sollte man sie erst definieren,
>dann diskutiert es sich viel leichter!

Bloß nicht! Sachkenntnis kann jede lebhafte Diskussion nur behindern.

Autor: EGS_TI (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ich meinte war ein "einfaches" kooperatives Multitasking System für 
8 Bit Controller.
Natürlich muss man seine Tasks dann auch entsprechend gestalten.

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
EGS_TI schrieb:
> Was ich meinte war ein "einfaches" kooperatives Multitasking System für
> 8 Bit Controller.
> Natürlich muss man seine Tasks dann auch entsprechend gestalten.

Trotzdem ist das, was Du beschrieben hast, eine Sonderform, nämlich ein 
"Time Triggered" System.
"Kooperatives Multitasking" Sagt nichts darüber aus, wie und welche 
nterrupts verwendet werden, es definiert nur, daß eine Task "kooperativ" 
Rechenzeit abgeben muß und nicht zwangsweise beendet wird.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Echtzeit ja, Echtzeit-BS nein. Bitte Begriffe auseinanderhalten.
Wenn es ein System ist (egal welcher BS-Architektur) (und ohne System 
wird wohl nix laufen) und Echtzeit-Bedingungen garantiert werden können, 
muss man es wohl automatisch Echtzeit-BS nennen, sonst wird es 
Haarspalterei.

Autor: EGS_TI (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard M. schrieb:
> EGS_TI schrieb:
>> Was ich meinte war ein "einfaches" kooperatives Multitasking System für
>> 8 Bit Controller.
>> Natürlich muss man seine Tasks dann auch entsprechend gestalten.
>
> Trotzdem ist das, was Du beschrieben hast, eine Sonderform, nämlich ein
> "Time Triggered" System.
> "Kooperatives Multitasking" Sagt nichts darüber aus, wie und welche
> nterrupts verwendet werden, es definiert nur, daß eine Task "kooperativ"
> Rechenzeit abgeben muß und nicht zwangsweise beendet wird.

Ja natürlich. Aber das ist doch eine der sichersten Formen, wenn nicht 
sogar die sicherste.
Ich gehe davon aus, dass die Luftfahrtindustrie nicht umsonst eine 
solche Architektur verwendet.

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
EGS_TI schrieb:
> Ja natürlich. Aber das ist doch eine der sichersten Formen, wenn nicht
> sogar die sicherste.
> Ich gehe davon aus, dass die Luftfahrtindustrie nicht umsonst eine
> solche Architektur verwendet.

Ja, stimmt, aber du hast das als "reines kooperatives Multitasking" 
beschrieben, womit viele meinten, Du siehst das als Grundvoraussetzung 
für kooperatives Multitasking an. Dabei ist es eher eine Sonderform, 
darauf wollte ich nur Hinweisen.
Dass es ein Multitasking ist, das sehr gute Wartbarkeit und 
Vorhersagbarkeit ermöglicht ist unbestritten.

Nur noch mal als Klarstellung ;-)

Autor: Michael L. (michaelx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anfangs wollte ich hier konstruktiv mitwirken, hatte nur nicht gleich 
Zeit. Aber angesichts dessen, wie sich das Ganze entwickelt hat, möchte 
ich nur folgendes sagen:

Ich finde es echt schade, dass dieser Thread wieder ausgegraben, und die 
von Andreas K. gemachte kurze wie gute und richtige Aussage unnötig in 
Frage gestellt wurde! Dafür habe ich kein Verständnis.

Für mich riecht solches Treiben stark nach Langeweile gepaart mit 
"gesundem" Halbwissen, und ein schwaches Ego.

Dem "Leichenschänder" EGS_TI empfehle ich das Studium der Bedeutung der 
entsprechenden Fachbegriffe, welche sich sich meines Wissens in den 
letzten 20 Jahren nicht geändert haben. Anderenfalls mag er los ziehen, 
und auch all die anderen Orte im Web missionieren und mit seinen 
"Weisheiten" zu bekehren versuchen, gibt sicher viele Hundert davon und 
noch mehr. Wenigstens richtet er dann hier weniger Schaden an.


Sorry, aber das musste mal gesagt werden.

Autor: Bronco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DO-178C schrieb:
> Gegenbeispiel: Wir verwenden für ein Flight Control System (großes
> Flugzeug, Zulassung) kooperatives non-preemtive multitasking. Abgesehen
> davon wird bis auf einen Timer-Interrupt kein weiterer verwendet.

Wie behandelt Ihr dann UART & Co?
Per DMA oder habt Ihr so etwas gar nicht?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.