Hallo, bekanntlich ist ein RTOS im Grundprinzip ein präemptiver Scheduler für Multithreading mit einem speziellen Algorithmus für Echtzeit-Unterstützung. Allerdings haben heutige RTOSe (z.B. Zephyr, RT-Thread usw) ja eine große Anzahl an zusätzlichen Komponenten und Middlewares wie z.B. Networking, Dateisysteme, Power Management, Treiber für externe interne & externe Peripherie, Kryptographie, OTA-Updates usw. "Eigentlich" sind diese Zusatz-Komponenten ja orthogonal zum Scheduler und nicht wirklich von diesem abhängig. Präemptives Multithreading ist außerdem schwierig sicher handzuhaben durch Race Conditions, Deadlocks & Co - es ist sehr leicht, subtile Fehler einzubauen, die nur sehr selten auftreten und kaum zu finden sind. Wenn ich also diese zusätzlichen Komponenten/Libraries nutzen möchte, aber eben kein präemptives Scheduling haben möchte, hat man kaum eine Option, richtig? Dinge wie Flash-Filesystems sind immer in synchron implementiert in der Annahme, dass ein präemptives Scheduling im Hintergrund läuft. Was gibt es für Möglichkeiten, solche Komponenten (Networking, Flash-Filesysteme, Peripherie-Treiber) ohne präemptives Scheduling zu nutzen? Neben der Flickschusterei für jeden Aspekt eine Bibliothek zu finden und diese irgendwie unter einen Hut zu bringen? PS: Interessanterweise scheint die Echtzeit-Fähigkeit von RTOSen in der Praxis eine geringe Rolle zu spielen. Welcher Scheduling-Algorithmus dort arbeitet, wie lange genau ein Task braucht usw. wird anscheinend selten betrachtet. Im Studium war das allerdings das Einzige, was über RTOSe gelehrt wurde... Der "RT"-Teil in "RTOS" scheint nur von akademischem Interesse zu sein?
Niklas G. schrieb: > Der "RT"-Teil in "RTOS" scheint nur von > akademischem Interesse zu sein? Nun ja, bei dem einem vielleicht. Gerüchteweise gibts aber doch noch mindestens ein zweites… Oliver
Niklas G. schrieb: > Was gibt es für Möglichkeiten, solche Komponenten (Networking, > Flash-Filesysteme, Peripherie-Treiber) ohne präemptives Scheduling zu > nutzen? Neben der Flickschusterei für jeden Aspekt eine Bibliothek zu > finden und diese irgendwie unter einen Hut zu bringen? Vielleicht sind dem Adam Dunkels seine Protothreads was für dich.
Niklas G. schrieb: > Wenn ich also diese zusätzlichen Komponenten/Libraries nutzen möchte, > aber eben kein präemptives Scheduling haben möchte, hat man kaum eine > Option, richtig? Nö. VxWorks kann diesen Anspruch erfüllen. Dort kann man den Scheduler entsprechend konfigurieren. Probiert hab ich diese Option selber nie. Und VxWorks kostet Geld, viel Geld ;) Und ich bin mir sicher dass es noch andere RTOS gibt die nur mit kooperativem Scheduler laufen können.
Niklas G. schrieb: > Wenn ich also diese zusätzlichen Komponenten/Libraries nutzen möchte, > aber eben kein präemptives Scheduling haben möchte, hat man kaum eine > Option, richtig? Dinge wie Flash-Filesystems sind immer in synchron > implementiert in der Annahme, dass ein präemptives Scheduling im > Hintergrund läuft. nicht immer, bei Mbed wurde das teilweise getrennt. In Mbed 2 war das OS nur ein API das Komponenten wie DitalIn/Out, Serial, I2C, CAN, Software Timer und mehr abstrahiert hat. Einen RT Scheduler konnte man optional dazubauen. Das hatte den Nachteil das die Basic OS Komponenten nicht threadsafe waren und diese Kombi mit Vorsicht zu geniessen war. In Mbed 5/6 wurde der Scheduler (RTX von ARM) fest eingebaut und Threads berücksichtigt. Mbed 5 wurde dadurch aber sehr fett und viele kleine Controller waren damit nicht mehr geeignet. Dann wurde Mbed 6 besser modularisiert und der RT Teil einfach konfigurierbar im Build gemacht. In der Variante baremetal hat man dann wieder nahezu alles an Treibern, aber eben ohne den Scheduler und die RTOS nötigen Dinge wie Semaphore, Mailboxen usw. Nur im Ethernet Code wird das RT und Features wie EventFlags verwendet, daher ist das nur in der RTOS Variante nutzbar. Obwohl, soviel wird da nicht mit Threads gemacht und es könnte auch ohne gehen. Aber bei Controllern mit EMAC hat man üblicherweise auch genug Resourcen für das RTX, und man muss ja keine weiteren Threads starten. Praktisch ist es aber schon. Bei ohne RTX gibt es im baremetal trotzdem die EventQueues, damit kann man kooperative Scheduling elegant lösen. In die EventQueue kann man Funktionen reinwerfen die dann in der mainloop ausgeführt werden, auch gut um Code aus ISR vom Interruptcontext zu entkoppeln. Hier wird der Komfort den C++ bietet genutzt, die EventQueues sind absolut genial.
900ss schrieb: > VxWorks kann diesen Anspruch erfüllen. Ich hab das so aus der Erinnerung geschrieben, die aber trügt (glaube ich jetzt). Es geht kein kooperatives Multitasking, sondern man kann dem Scheduler nur sagen, er soll Round Robin arbeiten, nicht kooperativ. Kann auch nicht mehr nachsehen ;)
Der Poster hat leider viel weniger wie gar keine Ahnung. Ein RTOS ist speziell fuer Echtzeit gemacht. Genau deswegen wird's verwendet, fuer nichts anderes. Allerdings sollte man einige Punkte beachten. Ein Echtzeit System muss nicht maximal schnell sein, sondern zuverlaessig schnell mit einer definierten maximalen Reaktionszeit. Also nichts mit zufaelligen Garbage collector, welcher wie auch immer lange braucht. Oder ein Systemupdate reinzieht und den Rechner auf irgendwelche Zeit blockiert. Je nach Einsatzumfeld reichen vielleicht 10ms Reaktionszeit. Bei einem Auto moechte man eher bei 1ms liegen. Ein Stueck Hardware ist eine Ressource und muss natuerlich richtig geshart werden. Resp man hat einen Thread pro Ressource und dieser bedient die Hardware Funktionalitaet. Ungeteilt. Also, die Ethernet Schnittstelle ist ein Thread. Andere Threads mit Bedarf werden von diesem bedient. Wann der seine Zeitscheibe bekommt ist weniger wichtig. Desgleichen das Filesystem. Allenfalls stellt das schon das RTOS sicher, und sonst muss man's eben selbst machen.
:
Bearbeitet durch User
Niklas G. schrieb: > Was gibt es für Möglichkeiten, solche Komponenten (Networking, > Flash-Filesysteme, Peripherie-Treiber) ohne präemptives Scheduling zu > nutzen? Neben der Flickschusterei für jeden Aspekt eine Bibliothek zu > finden und diese irgendwie unter einen Hut zu bringen? Selber schreiben. Wenn man kein Multithreading hat und dennoch verschiedenen Aufgaben parallel abzuarbeiten hat, dann muss man jede Aufgabe in kleinere Teilaufgaben zerstückeln und diese dann häppchenweise und/oder asynchron ausführen. Asynchrone Architekturen sind aber nicht jedermanns Sache, da muss man oft um die Ecke denken. Deswegen wird sehr oft einfach ein RTOS benutzt und es gibt nicht so viele fertige Libraries dafür. RTOS macht das einfacher, hat dafür aber auch Nachteile, jeder Thread benötigt einen eigenen Stack, Kontextwechsel und Synchronisation kosten Performance. Von der Laufzeit Seite her kann man "Parallelität" bzw Preämptive Systeme aber auch anders erreichen. Z.b mit Interrupten. Im Usermode führt man alles aus, was langsam ablaufen und damit synchron umgesetzt werden kann und im Interruptmode das wo es Zeitanforderungen gibt. Aber auch Polling kann eine Option sein und ist nicht unbedingt schlechter. Z.b. kann man eine "Aufgabe" in Teilaufgaben aufteilen und das in eine Zustandsmachine verpacken. Dann "pollt" man einfach in der Hauptschleife alle Zustandsmaschinen nacheinander. Das ist dann kooperatives Multitasking. Ich selbe nutze meist Queues mit Funktionspointern + Interrupte. Jede Teilaufgabe kommt in eine Funktion und wenn die halt ausgeführt werden muss, dann wird der Funktionspointer in die FIFO geworfen. Die "main" Funktion macht nichts weiter als auf die Queues (können mehrere sein, z.B. hochpriore und niederpriore) zu schauen und sich dort die Funktionsspointer rauszuziehen und auszuführen. Eine weitere Queue enthält dann noch die (Software)Timer...
Die Frage ist, was willst Du genau nutzen? Solche RTOS Betriebssystem sind halt in der Regel primär Taskswitcher, willst Du mehr musst Du das bei vielen woanders her holen. Es gibt zum Beispiel viele Dateisystemsroutinen welche Du, völlig unabhängig vom Betriebssystem, verwenden kannst. Zum Beispiel so was hier, falls Du FAT haben möchtest. https://github.com/FullFAT/FullFAT Für Spezialanwendungen kann es aber einfacher sein, mal eben selbst ein Minimalstdateisystem zu stricken. Willst Du Netzwerk haben, so wird es etwas schwieriger, da es im Allgemeinen sinnvoll ist, wenn Dein Netzwerkstack Dinge im Hintergrund machen kann. Damit kann beispielsweise die ARP-Anfrage rechtzeitig bevor der ARP-Cache ausläuft gemacht werden. Auch bei Protokollen wie TCP (eine Art 1-Stream SCTP) kann es sinnvoll sein, wenn der Stack einen Thread hat, der sich um Retransmissions u.Ä. kümmert.
Andreas M. schrieb: > Asynchrone Architekturen > sind aber nicht jedermanns Sache, da muss man oft um die Ecke denken. Ich denke mal, das ist das Grundproblem. Schlimmer noch: es muss noch nicht mal echte Asynchronität und die damit verbundenen Probleme sein. Viele Möchtegern-Programierer kommen ja nicht mal mit einem Ereignis-gesteuerten Programmierschema zurecht, was ordentlich innerhalb eines einzigen Threads/Tasks abgearbeitet wird, also simplen state machines. Wenn die Kontrollstruktur nicht als solche im Code steht, sind die aufgeschmissen und begreifen nicht mehr, was da eigentlich passiert. Nicht schlimm, nicht jeder ist zum Programmierer geboren. Aber: Die sollten dann auch einfach nicht programmieren. Es ist ihnen nicht gegeben.
Niklas G. schrieb: > Präemptives Multithreading ist außerdem schwierig sicher handzuhaben > durch Race Conditions, Deadlocks & Co - es ist sehr leicht, subtile > Fehler einzubauen, die nur sehr selten auftreten und kaum zu finden > sind. Vielleicht solltest Du 3 Dinge trennen: 1) Die verschiedenen Eigenschaften eines RTOS (z.B. verschiedene Arten von Schedulern) 2) Dein Nutzen des RTOS (Abhängig von Deinen Kenntnissen) 3) die "Zusatzfunktionen" des RTOS In Autosar z.B. sind "Basic Tasks" nichts anderes als Funktionen, die aufgerufen werden und ohne jedes Warten durchlaufen (müssen). Wenn Du mit einer Task auskommst, dann brauchst Du Dich um die allermeisten Dinge gar nicht zu kümmern und kannst trotzdem die "Zusatzfunktionen" nutzen, da die ja von Leuten implementiert wurden, die das RTOS kennen. Wenn Du mehrere Tasks brauchst, gibt es unzählige Pattern, um typische Fallstricke zu umschiffen. Die meisten haben auch vorher schon mehrere Tasks und Prioritäten gehabt und sie "Interrupt-Routine" genannt. Viele Probleme sind ähnlich oder gleich. Fang einfach an. Oft mit einer Loop und davon entkoppelter GUI. Spring ins kalte Wasser, je eher lernst Du schwimmen.
Ob S. schrieb: > Wenn die Kontrollstruktur nicht als solche im Code steht, sind die > aufgeschmissen und begreifen nicht mehr, was da eigentlich passiert. > > Nicht schlimm, nicht jeder ist zum Programmierer geboren. Das scheint mir doch eine recht seltsame Ansicht zu sein! Wenn irgendwas X mal gemacht werden soll, dann will ich da eine zählende for Schleife sehen. Ohne wenn und aber! Ebenso eine Endlosschleife, wenn irgendwas dauerhaft getan werden soll. z.B. so: while(not stromausfall) tuwas(); Alles andere widerspricht dem Prinzp der geringsten Verwunderung. Und ein Verstoß dagegen ist unter Programmierern doch eher ein NoGo.
:
Bearbeitet durch User
Arduino F. schrieb: > Wenn irgendwas X mal gemacht werden soll, dann will ich da eine zählende > for Schleife sehen. > Ohne wenn und aber! Wenn Deine Schleife auf einem System mit kooperativen Multitasking laufen soll und nicht das ganze System während der Ausführungszeit der Schleife blockiert sein soll, dann hast Du mit der Einstellung ein Problem. Ein schönes Beispiel für kooperatives Multitasking waren die 16-Bit-Versionen von Windows. Gut beschrieben in der zweiten Ausgabe von Charles Petzolds "Programming Windows" von 1990 oder in der dritten Ausgabe von 1992*. Wenn ich mich recht erinnere, gab es das Buch auch mal als Beigabe zu einer Version des 16-Bit-Borland-C/C++-Compilers (die mit dem guten halben Meter Papier) *) https://archive.org/details/programming-windows-31-3rd-ed
Harald K. schrieb: > Arduino F. schrieb: >> Wenn irgendwas X mal gemacht werden soll, dann will ich da eine zählende >> for Schleife sehen. >> Ohne wenn und aber! > > Wenn Deine Schleife auf einem System mit kooperativen Multitasking > laufen soll und nicht das ganze System während der Ausführungszeit der > Schleife blockiert sein soll, dann hast Du mit der Einstellung ein > Problem. Nein, habe ich nicht! Siehe: Arduino F. schrieb: > Vielleicht sind dem Adam Dunkels seine Protothreads was für dich. Habe mir eine Abwandlung davon gebaut, die auch auf kleinen AVR ganz gut zu nutzen ist.
:
Bearbeitet durch User
Niklas G. schrieb: > Allerdings haben heutige RTOSe (z.B. Zephyr, RT-Thread usw) ja eine > große Anzahl an zusätzlichen Komponenten und Middlewares wie z.B. > Networking, Dateisysteme, Power Management, Treiber für externe interne > & externe Peripherie, Kryptographie, OTA-Updates usw. > > "Eigentlich" sind diese Zusatz-Komponenten ja orthogonal zum Scheduler > und nicht wirklich von diesem abhängig. Auch wenn es eigentlich schon beantwortet wurde, hier nochmal am Beispiel von embOS. Gilt aber genauso für FreeRTOS, etc. Du kannst ein reines RTOS wie embOS benutzen. Das ist der Scheduler inkl. passender API, um Tasks laufen zu lassen, zu synchronisieren, usw. https://www.segger.com/doc/UM01001_embOS.html Daneben gibt es Embedded Software, wie TCP/IP Stack, USB Stack, Filesystem, usw. https://www.segger.com/products/rtos-embedded-software/ Aus Sicht des RTOS ist das alles Applikation, d.h., ob ein Filesystem läuft oder deine Applikation ist dem RTOS egal. Wenn z.B. das Filesystem in mehreren Tasks genutzt werden soll, muss es thread-safe sein. Die Embedded Software kannst du auch ohne RTOS, als bare metal, laufen lassen (oder auch mit jedem anderen RTOS). Dann ist aber deine Applikation dafür verantwortlich, dass alle Teile deiner Applikation den Echtzeitanforderungen entsprechen. Es gibt Embedded Software wie z.B. USB Host, die ohne RTOS nur schwer umsetzbar sind. Niklas G. schrieb: > Präemptives Multithreading ist außerdem schwierig sicher handzuhaben > durch Race Conditions, Deadlocks & Co - es ist sehr leicht, subtile > Fehler einzubauen, die nur sehr selten auftreten und kaum zu finden > sind. Natürlich kann es Probleme geben, aber dem würde ich nicht zustimmen. Ansonsten würden RTOS ja nicht in sicherheitskritischen Produkten eingesetzt werden. Was ich in der Praxis eher sehe, ist, dass manche Entwickler sich ihren eigenen Scheduler entwickeln, weil auch ihre komplexe Applikation Echtzeitanforderungen hat. Aber dann kann man auch direkt ein RTOS einsetzen
Arduino F. schrieb: > Nein, habe ich nicht! Dann zeig' doch mal Deine for-Schleife, die nicht Deine Protothreads blockiert. Sieht die so aus wie eine stinknormale for-Schleife? Oder eher doch nicht?
Til S. schrieb: > Aus Sicht des RTOS ist das alles Applikation, d.h., ob ein Filesystem > läuft oder deine Applikation ist dem RTOS egal. Wenn z.B. das Filesystem > in mehreren Tasks genutzt werden soll, muss es thread-safe sein. Diese Anforderung bedingt, dass für jede Task/Thread ein Stack Bereich reserviert werden muss. Damit ist der Speicher die begrenzende Ressource. Wenn da kein Mange herrscht, dann gut. Aber: 4 Tasks auf einem ATMega328p, da dürfte dann irgendwo die Grenze sein. Das ist nicht viel. Zudem sind die Unmengen Push und Pop nicht gerade ein Beschleuniger. Auch war die Eingangsfrage: Niklas G. schrieb: > aber eben kein präemptives Scheduling haben möchte,
Harald K. schrieb: > Dann zeig' doch mal Deine for-Schleife, die nicht Deine Protothreads > blockiert. Erstens: Du kennst die Protothreads nicht. Sonst wüsstest du das, wie das geht. Zweitens: Das interessiert dich überhaupt nicht! Denn sonst würdest du dir die Abhandlungen des Herren Dunkels mal durchgelesen haben, bevor du so ein dummes Zeugs blubberst. Offensichtlich glaubst du mir nicht. Das ist eigentlich ok. Aber schade, dass du das nicht selber gegenprüfen möchtest. Beispiel: For Schleife mit Adruino delay() Drop in Ersatz und dazu mit einer Endlosschleife garniert.
1 | // Grundsaetzliche Annahme (-: es "mag" Ausnahmen geben ;-)
|
2 | constexpr bool stromausfall {false}; |
3 | |
4 | class Piepser : public Task |
5 | {
|
6 | protected:
|
7 | int i; |
8 | bool &piepflag; |
9 | |
10 | public:
|
11 | Piepser(bool &piepflag):i(0),piepflag(piepflag){} |
12 | |
13 | virtual void run() override // 5 mal piepsen, wenn Flag gesetzt |
14 | {
|
15 | |
16 | TaskBlock
|
17 | {
|
18 | while(not stromausfall) |
19 | {
|
20 | taskWaitFor(piepflag); |
21 | for(i = 0; i < 5; i++) |
22 | {
|
23 | Serial.println(F("Piep")); |
24 | //taskSwitch();
|
25 | taskPause(200); / ms |
26 | }
|
27 | piepflag = false; // fertig mit piepsen (Flag konsumieren) |
28 | }
|
29 | }
|
30 | }
|
31 | };
|
1 bis 2 Dutzend Tasks auf einem Uno durchaus machbar. ca 100000 Durchläufe pro Sekunde bei 4 bis 5 Tasks
:
Bearbeitet durch User
Arduino F. schrieb: > Erstens: Du kennst die Protothreads nicht. > Sonst wüsstest du das, wie das geht. > > Zweitens: Das interessiert dich überhaupt nicht! Du bist irgendwo ganz, ganz falsch abgebogen. Und wirfst jetzt krampfhaft mit Beleidigungen und haltlosen Unterstellungen um Dich. Was Du da zeigst, ist halt keine simple for-Schleife mehr, sondern eine, die nach jedem Durchlauf eine zusätzliche Funktion ("taskPause") aufruft, um eben anderen Threads Rechenleistung zukommen zu lassen. Wenn Du das bei Deiner Programmierung berücksichtigst, ist ja alles gut, nur widersprichst Du Deinen Pauschalaussagen hier: Arduino F. schrieb: > Wenn irgendwas X mal gemacht werden soll, dann will ich da eine zählende > for Schleife sehen. > Ohne wenn und aber! > > Ebenso eine Endlosschleife, wenn irgendwas dauerhaft getan werden soll. > z.B. so: while(not stromausfall) tuwas(); Deine Endlosschleife funktioniert nur dann, wenn entweder zusätzlich zu "tuwas" eine Funktion analog zu "taskPause" aufgerufen wird, oder aber "tuwas" das macht. Das ist der essentielle Unterschied, auf den man eben achten muss.
Harald K. schrieb: > Beleidigungen und haltlosen Unterstellungen um Dich. Wie? Du hast doch gezeigt, dass du die Protothreads nicht kennst und dich nicht kundig gemacht hast. Wie kann das beleidigend sein, wenn man das klar so benennt? Ja, ich bin enttäuscht von dir, da hätte ich mehr erwartet.
:
Bearbeitet durch User
Arduino F. schrieb: > Wie? > Du hast doch gezeigt, dass du die Protothreads nicht kennst und dich > nicht kundig gemacht hast. Das habe ich nicht gezeigt. Das hast Du -völlig falsch- in meine Aussage hineininterpretiert. Wie wäre es, an Deinem Textverständnis zu feilen?
Arduino F. schrieb: > Diese Anforderung bedingt, dass für jede Task/Thread ein Stack Bereich > reserviert werden muss. > Damit ist der Speicher die begrenzende Ressource. > Wenn da kein Mange herrscht, dann gut. Ja, richtig, jede Task läuft auf ihrem eigenen Taskstack und dafür braucht man genügend Speicher. Die Größe des Taskstacks hängt von dem Code in der Task ab. Der Taskstack muss z.B. größer sein, wenn mehr lokale Variablen und Unterprogrammaufrufe genutzt werden. Wir haben Kunden, die embOS auf einem 8051 mit 2 kByte RAM einsetzen...da wundert man sich schon ein bisschen ;-). Arduino F. schrieb: > Zudem sind die Unmengen Push und Pop nicht gerade ein Beschleuniger. Du meinst wahrscheinlich den Taskwechsel. Dazu kommt dann auch noch die Laufzeit des Schedulers. Man muss das wahrscheinlich ein bisschen differenzieren. Nicht jede Applikation braucht ein RTOS und nicht jeder Mikrocontroller hat dafür genug Leistung und Speicher. Aber Mikrocontroller werden immer leistungsfähiger und haben mehr Speicher. Daher werden komplexere Applikationen ausgeführt, die mehr Echtzeitanforderungen haben. Der Overhead des RTOS ist dann im Vergleich zu den Vorteilen vernachlässigbar.
Wenn es dem TO um solche Komponenten geht: > Allerdings haben heutige RTOSe (z.B. Zephyr, RT-Thread usw) ja eine > große Anzahl an zusätzlichen Komponenten und Middlewares wie z.B. > Networking, Dateisysteme, Power Management, Treiber für externe interne > & externe Peripherie, Kryptographie, OTA-Updates usw. wird es ihm wohl kaum um kleine AVR gehen. Da würde ich allerdings auch nicht auf einen präemptiven Scheduler verzichten wollen. Ein RTOS zeichnet sich nicht nur durch garantierte Antwortzeiten aus, die Tasks/Threads haben auch verschiedene Prioritäten die eine Programmstruktur vereinfachen.
Arduino F. schrieb: > Harald K. schrieb: >> Dann zeig' doch mal Deine for-Schleife, die nicht Deine Protothreads >> blockiert. > Erstens: Du kennst die Protothreads nicht. > Sonst wüsstest du das, wie das geht. "taskPause", "taskWaitFor" sind nichts weiteres als in Deiner Applikation explizit gesetzte Unterbrechungspunkte an denen Du die Kontrolle zurück an den "Protothread Scheduler" übergibst. (Im Endeffekt steht da ein "return") Und das ist genau das, was Harald mit seiner Aussage meinte: Wenn man ein deartig implementiertes kooperatives Multitasking einsetzt, dann muss die Applikation dafür geschrieben sein, sonst funktioniert das nicht. Wenn du nämlich "taskPause" und "taskWaitFor" weg lässt, naja, den Rest weist Du sicher selbst. Und hier entsteht das Problem wenn man fertige Bibliotheken einsetzen will, z.b. fürs Dateisystem. Würde man einen Aufruf von "open(...)" in Deine Schleife einsetzen, dann würde er an der Stelle gemütlich alle I/O Operationen (z.B SPI) abwarten und durcharbeiten bevor er aus der "open" Funktion überhaupt zurückkommt. Und das würde mit read/write so weitergehen. Erst dann wenn die Applikation explizit die Kontrolle an den Protothread Scheduler zurückgibt würde überhaupt erst eine andere "Task" dran kommen können, die sogenannte Parallelität geht dann ganz schnell flöten (Kommt drauf an wie zeitkritisch die einzelnen Aufgaben sind) Im Gegensatz dazu kann ein echtes Multitasking OS eine Task zu jedem beliebigen Zeitpunkt unterbrechen und was anderes laufen lassen, dafür werden keine Unterbrechungspunkte gebraucht. Somit kann dann (im Prinzip beliebiger) Code dem System zugefügt werden ohne den Rest des Systems zu stören oder das Zeitverhalten zu beeinflussen.
Andreas M. schrieb: > echtes Multitasking OS Ich würde den Unterschied zwischen kooperativem und präemptiven Multitasking nicht verwenden, um zwischen "echtem" und "unechtem" Multitasking zu unterscheiden. Auch kooperativ ist sehr wohl echtes Multitasking möglich (entsprechende Disziplin und Sorgfalt seitens des Programmierers vorausgesetzt). Ja, ein präemptives Multitasking macht das ganze sehr viel leichter, wiederum vorausgesetzt, der Programmierer schafft es, bei der Synchronisation seiner Threads keine Verknotungen (Deadlock, Race Condition etc.) zu basteln.
Niklas G. schrieb: > Wenn ich also diese zusätzlichen Komponenten/Libraries nutzen möchte, > aber eben kein präemptives Scheduling haben möchte, hat man kaum eine > Option, richtig? Irgendwie ist die Frageform hier kacke. Aktuelle Forschungen gehen da wohl eher in Richtung Stromsparen? "In spite of this large application domain, most of the current real-time systems are still designed and implemented using low-level programming and empirical techniques, without the support of a scientific methodology. This approach results in a lack of reliability, which in critical applications may cause serious environmental damage or even loss of life." Würdest du sagen, dass diese Thematik mit den oben angesprochen Problemen eine passende in einem Lämpchen-Blinken-lassen-Forum ist? Mit solchen Fragen geht man an die Uni, fragt viele Leute, macht sich eine Leseliste zum Abarbeiten und macht sich selber ein paar Notizen und Gedanken - bis man merkt, dass man keine Ansprechpartner mehr hat, und ein Kommunikationsproblem. Falls man selber an der Uni lehrt, hätte man natürlich auch ein supergutes Thema zum Veröffentlichen. Früher hätte man sogar nach Pisa pilgern können, um die Vorlesungen von diesem Buttazzo zu besuchen. (Wenn man ein paar Wiki-Seiten zur Jupitersonde Juno durchliest, weiß man immer noch nicht, wer die Sonde wie und womit programmiert hat.)
Rbx schrieb: > "In spite of this large application domain, most of the current > real-time systems are still designed and implemented using low-level > programming and empirical techniques, without the support of a > scientific methodology. This approach results in a lack of reliability, > which in critical applications may cause serious environmental damage or > even loss of life." Welche Quelle hast Du da zitiert? Klingt ja gar nicht voreingenommen, das.
Harald K. schrieb: > Welche Quelle hast Du da zitiert? Klingt ja gar nicht voreingenommen, > das. https://link.springer.com/book/10.1007/978-1-4614-0676-1
Rbx schrieb: > "In spite of this large application domain, most of the current > real-time systems are still designed and implemented using low-level > programming and empirical techniques, without the support of a > scientific methodology. This approach results in a lack of reliability, > which in critical applications may cause serious environmental damage or > even loss of life." Das klingt mir sehr subjektiv und schlecht informiert/recherchiert vom ursprünglichen Autor dieser Zeilen. Wenn Menschenleben betroffen sind, gibt es sehr strenge Vorgaben für die Software in kritischen Applikationen wenigstens im Maschinenbau, Luft- & Raumfahrt. Ich vermute in der Autoindustrie oder gar Medizin ist es nicht anders. Da wird nichts empirisch programmiert. Das ist schlicht Unsinn.
:
Bearbeitet durch User
> This approach results in a lack of reliability, > which in critical applications may cause serious environmental damage or > even loss of life." Ich halte die Aussage auch für schwierig. 900ss schrieb: > Wenn Menschenleben betroffen sind, > gibt es sehr strenge Vorgaben für die Software in kritischen > Applikationen wenigstens im Maschinenbau, Luft- & Raumfahrt. Ich vermute > in der Autoindustrie oder gar Medizin ist es nicht anders. Ja, ist bei Automotive und Medizin nicht anders. In der ISO 26262 bzw. IEC 62304 sind die Anforderungen an die Software genau beschrieben. Ein RTOS wie z.B. embOS-Safe oder SafeRTOS müssen nach diesen Normen zertifiziert werden, um im Fahrzeug oder im Medizinprodukt genutzt werden zu können. Diese Zertifizierung muss aber der Entwickler nicht selber machen, sondern das machen oft bereits die RTOS Hersteller, so dass man ein "pre-certified" RTOS nutzen kann.
Wann und wofür benutzt ihr eigentlich ein RTOS? In 10 Jahren Arbeitswelt und auch privater Bastelleien hatte ich noch nie das Bedürfnis nach einem RTOS. Aber ich programmiere vermutlich auch keine HF Echtzeit Anwendungen.
Max M. schrieb: > Wann und wofür benutzt ihr eigentlich ein RTOS? In den letzten knapp 17 Jahren benutzen eher weniger...mehr das RTOS entwickeln ;-). Ein RTOS macht immer da Sinn, wo die Applikation komplexer ist, und mehrere Aufgaben quasi parallel mit unterschiedlichen Echtzeitanforderungen abgearbeitet werden sollen. Sagen wir, eine fiktive Anwendung soll irgendwelche Daten per TCP/IP austauschen und per GUI/Touch bedienbar sein. Der TCP/IP Stack und der Datenaustausch können in Tasks mit niedriger Priorität laufen, weil sie keine hohen Echtzeitanforderungen haben. Ob die Daten ein paar Millisekunden später ankommen, ist in dieser fiktiven Anwendung egal. Die GUI Task hat aber hohe Echtzeitanforderungen und sollte eine hohe Taskpriorität bekommen. Wenn der Benutzer das Touch bedient und auf dem Display passiert nichts, weil gerade Code des TCP/IP Stacks abgearbeitet wird, ist das suboptimal. Das RTOS hilft einem ungemein bei dem Timing und den Echtzeitanforderungen. Natürlich geht das auch irgendwie ohne RTOS, aber ab einer gewissen Komplexität der Anwendung nur mit sehr viel mehr Aufwand. Dazu kommen noch andere Aspekte wie z.B. Energie sparen aber das führt hier zu weit.
Oh je... Wer schon für eine ausreichende Schwuppdizität eines Guis ein Rtos benötigt, macht irgend etwas sehr grundlegend verkehrt. Multithreading und Multitasking haben erstmal gar nichts mit "real time" zu tun. Selbst das selige Windows 3.1 konnte TCP/IP und Gui "gleichzeitig", obwohl das nun wirklich gar nichts von sich aus gleichzeitig konnte. Oliver
Oliver S. schrieb: > obwohl das nun wirklich gar nichts von sich aus > gleichzeitig konnte. Das konnte kooperatives Multitasking, damit hat es seine GUI verwaltet. TCP lief irgendwo im schmutzigen Hintergrund, mit Interrupts oder wie auch immer.
900ss schrieb: > Das klingt mir sehr subjektiv und schlecht informiert/recherchiert vom > ursprünglichen Autor dieser Zeilen. Fass dich an deine eigene Nase, bevor du hier auf andere zeigst. Ein paar Beispiele hat der Autor auch, die dann aber eher in Richtung Bugs aufgrund der Komplexität des schlecht wartbaren Codes gehen.
Harald K. schrieb: > Das konnte kooperatives Multitasking Bei Windows 3.1 ist die Aussage aber doch eher ein Euphemismus. Aber egal, es ändert nichts daran, dass selbst preemtives Multitasking erst einmal nichts mit Real time zu tun hat. Oliver
Oliver S. schrieb: > Bei Windows 3.1 ist die Aussage aber doch eher ein Euphemismus. Nein, ganz und gar nicht. Das ist kein Euphemismus, sondern echtes kooperatives Multitasking. Wenn man das (auf 386ern verfügbare) Multitasking von DOS-Prozessen parallel zur Windows-GUI meint - das ist kein kooperatives Multitasking, das ist präemptives Multitasking. Kooperatives Multitasking über die Windows-Message-API haben schon viel ältere Windows-Versionen betrieben. Wenn es gehakelt hat, dann lag das an schlecht geschriebenen Programmen - und nichts gibt es in der Windows-Welt mehr als schlecht geschriebene Programme. Das war zu 16-Bit-Zeiten so (wo es den kompletten Betrieb lahmlegen konnte), das ist aber auch heute noch so, nur wird heute viel, viel mehr Aufwand betrieben, die Auswirkungen abzufangen. Kooperativ war übrigens auch das Multitasking der alten MacOS-Varianten (alles vor OS X).
Rbx schrieb: > Fass dich an deine eigene Nase, bevor du hier auf andere zeigst Ich habe bzw. arbeite in zwei von den von mir genannten Bereichen und habe deshalb "etwas" Wissen. Deshalb fällt es mir schwer die Aussage des Autors als glaubhaft anzuerkennen. Selbst wenn mal etwas "durchrutscht" trotz aller Regelarien, ist das noch länger nicht zu verallgemeinern, so wie in den Buch geschehen. Trotz möglicher Beispiele... Und immer freundlich bleiben gelle :) Nase und so....
Oliver S. schrieb: > Aber egal, es ändert nichts daran, dass selbst preemtives Multitasking > erst einmal nichts mit Real time zu tun hat. Tatsächlich kommen hier erst die Problem ins Spiel. Ein verlässliches Timing wie beim Atari ST oder wie bei DOS gab es jetzt nicht mehr - wie auch die einfache Hardwarezugänglichkeit/Schnittstelle nicht mehr. Und ohne richtiges DOS ist die Hardwarezugänglichkeit teilweise noch schlimmer. Teilweise deswegen, weil die DOS-Emulation in Vista doch recht gut ging und bei alten Programmen weniger Probleme machte als die alten Kisten. Damals gab es aber noch andere potentielle Sorgenkinder wie z.B. DPMI - und ähnlich wie bei der Frage "welches Linux nehme ich denn?" drehten sich die Fragen damals um VGA oder FPU oder was immer - Und aktuell steht ja auch so ein wenig Directx in Frage oder die Windowsversion selber. Toll, wenn dann die hochqualititative Audiokarte keinen Direktx-Treiber oder Directx-Funktionalität mitbringt. -> Da kam dann damals Ubuntu-Studio - und auf die RTOS brauchte man dann auch nicht mehr lange warten. Ein Cubase für FreeDOS wäre eigentlich auch ganz nett gewesen. https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel
Harald K. schrieb: > Nein, ganz und gar nicht. Das ist kein Euphemismus, sondern echtes > kooperatives Multitasking. So ist es und das gab es sogar noch sehr viel länger als Windows3.x in Form der diversen Varianten von "embedded Windows", die ich mal (vereinfachend) als "WindowsCE" zusammen fassen würde. Da hat das auch einen Sinn ergeben, denn das lief auf teils wirklich recht mickrigen Architekturen und in vielen der damaligen Anwendungen braucht es obendrein tatsächlich RT-Eigenschaften. Noch heute sind weltweit mindestens zehntausende, wenn nicht gar hunderttausende kleine Werkzeugmaschinen mit WindowsCE-Steuerung im Einsatz.
Rbx schrieb: > Tatsächlich kommen hier erst die Problem ins Spiel. Ein verlässliches > Timing wie beim Atari ST oder wie bei DOS gab es jetzt nicht mehr - wie > auch die einfache Hardwarezugänglichkeit/Schnittstelle nicht mehr. Und > ohne richtiges DOS ist die Hardwarezugänglichkeit teilweise noch > schlimmer. DOS hatte gar kein Timing, und "Hardwarezugänglichkeit" scheiterte sehr oft schon am technischen Verständnis der Programmierer. Was ich an vergurkten Interpretationen der Ansteuerung einer seriellen Schnittstelle gesehen habe, geht auf keine Kuhhaut. Rbx schrieb: > Ein Cubase für FreeDOS wäre eigentlich auch ganz nett gewesen. > https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel Und womit sollte das mit welcher Hardware reden?
Oliver S. schrieb: > Aber egal, es ändert nichts daran, dass selbst preemtives Multitasking > erst einmal nichts mit Real time zu tun hat. Oliver S. schrieb: > Wer schon für eine ausreichende Schwuppdizität eines Guis ein Rtos > benötigt, macht irgend etwas sehr grundlegend verkehrt. RTOS wird im embedded-Bereich als Synonym für Multitasking verwendet. Egal ob preemtiv, kooperativ, mit und ohne Prioritäten oder Round Robin. Dein Begriff von RTOS wird meist mit "hart" qualifiziert. Das nutzen relativ wenige.
Harald K. schrieb: > DOS hatte gar kein Timing Falsch! Es hat(te) einen 18,xxHz timer tick. In dem man sich z.B. per TSR einhängen kann/konnte/musste
Bruno V. schrieb: > Dein Begriff von RTOS wird meist mit "hart" qualifiziert. Das nutzen > relativ wenige. Genau. Ein RTOS im embedded Bereich ist Regel erstmal "nur" ein OS. Ob dessen realtime Fähigkeiten wirklich ausgenutzt /gebraucht werden hängt halt vom Anwendungsfall ab.
Arduino F. schrieb: > Falsch! > Es hat(te) einen 18,xxHz timer tick. Wenn Du das schon als "Timing" betrachten willst, bitte. Das war halt der Timerinterrupt des 8254.
Arduino F. schrieb: > Harald K. schrieb: >> DOS hatte gar kein Timing > Falsch! > Es hat(te) einen 18,xxHz timer tick. > In dem man sich z.B. per TSR einhängen kann/konnte/musste Wenn du das als MT rechnest, war DOS tatsächlich ein MT-System. Schließlich konnte sich jede Anwendung in jeden Interrupt einhängen. Nur halt: ohne jede Unterstützung von DOS selber. Deswegen neige ich doch eher dazu DOS nicht als MT-OS zu betrachten...
Ob S. schrieb: > tatsächlich ein MT-System. > Schließlich konnte sich jede Anwendung in jeden Interrupt einhängen. Interrupts sind die Emulation von MT und RT. Der Ticker für zyklische Tasks, Scheduler über SW-Interrupts, HW-Interrupts als Semaphoren etc. Oft braucht man erst dann ein MT, wenn man an verschiedenen Stellen warten will.
Bruno V. schrieb: > Interrupts sind die Emulation von MT und RT. Der Ticker für zyklische > Tasks, Scheduler über SW-Interrupts, HW-Interrupts als Semaphoren etc. So ein vollendeten Quatsch habe ich je selten zuvor jemals gehört. Nein, es ist natürlich genau anders herum: Interrupts sind das, was REAL existiert. Zu was MT-OS die dann verwursten, hängt vom OS ab. Recht typisch für alle Ernstzunehmenden ist allerdings, dass sie Anwendungen nicht mehr direkt an die Interrupts ranlassen. Weil: wäre es anders, könnte sowas wie etwa RT-Anforderungen nur schwerlich garantiert werden.
Ob S. schrieb: > Nein, es ist natürlich genau anders herum: Interrupts sind das, was > REAL existiert. Ich kenne Deine Embedded Erfahrung nicht. Wenn Du Dir ein paar Deiner Projekte ohne MT ansiehst und Dir anschaust, wie Du es mit machen würdest, siehst Du oft die 1-1 Relation.
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.