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
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.
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.
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?
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.
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.
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.
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?
@ 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.
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
@ 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.
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
@ 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/Multitasking#Verbesserter_Ansatz
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.
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
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.
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?
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.
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.
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?
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.
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
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).
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.
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.
>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.
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.
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
> > 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.
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
>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.
>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 ?
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
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.
@ 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.
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)
MCUA schrieb: > Doch. Echtzeit ist es dann Echtzeit ja, Echtzeit-BS nein. Bitte Begriffe auseinanderhalten.
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!
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 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. ;)
@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.
Was ich meinte war ein "einfaches" kooperatives Multitasking System für 8 Bit Controller. Natürlich muss man seine Tasks dann auch entsprechend gestalten.
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.
>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.
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.
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 ;-)
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.
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?
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.