Hallo, es gibt diverse Betriebssysteme (OS), die sich als Real-time OS bezeichnen. Dazu gehören VxWorks, Zephyr, RT-Linux, FreeRTOS, um mal ein paar zu nennen. Meine Frage ist, in wie weit diese OS nun wirklich echtzeitfähig sind? Was zeichnet diese RTOS aus im Gegensatz zu anderen OS, wie z.b. Ubuntu oder Windows? Bevor diese Fragen beantwortet werden aber noch ein paar Worte zur Definition der Echtzeit. Mir ist bewusst, dass es viele Echtzeit-Begriffe gibt, die alle nicht wirklich definiert sind: firm-real-time, soft-real-time, hard-real-time... jeder versteht unter diesen Begriffen immer etwas leicht unterschiedliches. Bei meiner Frage geht es mir um die ursprüngliche Definition der Echtzeit: man kann eine Zeitperiode T angeben, in der die Ausführung einer bestimmten Funktion garantiert ausgeführt wird. -> die Zeit kann auch, wenn es Sinn macht, T=1h sein, solange man garantieren kann, dass die Ausführung innerhalb dieser Zeit ausgeführt wird. Vor diesem Hintergrund habe ich folgende Fragen: 1. Sind nicht alle Systeme letztendlich echtzeitfähig (selbst Windows auf einem gewöhnlichen x86 system)? Letztendlich müsste man nur alle möglichen Events/Funktionen kennen, die von Windows ausgeführt und die auf chipebene des x86 eingetaktet werden könnten. Hierbei müsste man den worst case ermitteln und könnte so die maximale Zeit berechnen, die für die Ausführung einer bestimmten Funktion benötigt wird. Wenn dieser z.b. T=3min wäre, könnte man Windows doch als RTOS einsetzen, wo eben diese Zeitperiode ausreicht. -> ist somit jedes beliebige OS auf beliebigem Prozessor echtzeitfähig? -> es ist nur ziemlich aufwendig, das zu machen (man müsste windows vollkommen reverse-engineeren und den kompletten x86 chip kennen). Sind also OS nicht echtzeitfähig, wenn es einfach nur in der Praxis zu teuer/aufwendig ist, eine garantierte Ausführungszeit zu berechnen? 2. Ein RTOS kann doch gar nicht von sich selber behaupten, dass es echtzeitfähig ist. Maßgeblich ist doch auch, auf welchem Prozessor dieser läuft. -> Ab wann ist somit ein RTOS echtzeitfähig? Wenn man alle Berechnungsschritte des RTOS angeben kann, die für eine Aufgabe benötigt werden? die genaue ausführungsdauer hängt dann vom verwendeten Prozessor ab. -> Kann ein RTOS seine Echtzeitfähigkeit verlieren, wenn man einen Prozessor verwendet, der nicht echtzeitfähig ist? 3. Das ist eine Folgefrage zu 2. -> Sind nicht alle Prozessoren letztendlich echtzeitfähig? Man muss nur alle funktionen/events kennen, die auf chipebene ablaufen können. -> Oder sagt man hier, dass es eben wieder viel zu kompliziert ist, alle Effekte auf chipebene zu kennen, die die Rechenzeit beeinflussen könnten? Sind also nur die Prozessoren echtzeitfähig, die man der Praxis unter dem Gesichtspunkt der Echtzeitfähigkeit handlen kann? Wer entscheidet dann, ab wann das zu kompliziert wird? -> Ein Cortex-M7 Prozessor ist auf jeden fall von einer Person zu überblicken, um Echtzeitfähigkeit garantieren zu können. würdet ihr sagen, dass ein Cortex-A9 Prozessor noch zu den echtzeitfähigen Prozessoren zählt? -> ein x86 würde ich auf jeden fall als zu kompliziert erachten, um hier Echtzeitfähigkeit anbringen zu können. Sind dann alle Geräte, die einen x86 verwenden und von sich behaupten echtzeitfähig zu sein, überhaupt nicht echtzeitfähig? Vielen Dank schonmal fürs lesen sinapse
Eine finale Antwort auf so eine schwammige Frage gibt es nicht, schon gar nicht hier.
Welchen Sinn und Zweck hat es, alles grundsätzlich als echtzeitfähig zu betrachten, wenn mir das System keine Garantien oder Angaben geben will? Das ist hier der entscheidene Unterschied. Ein Echtzeitbetriebssystem macht das. Das Thema ist kein Selbstzweck. Nach dem nächsten Windows Update, wurde die Implementierung nochmal angefasst und plötzlich werden die Echtzeitbedingungen verletzt. Was hat der ganze Aufwand des Testens dann gebracht?
Ordne mal deine Gedanken. Stand jetzt lautet die Antwort Ja oder nein oder vielleicht...
Sina A. schrieb: > echtzeitfähig Echtzeit bedeutet doch nur das eine Antwort innnerhalb einer definierten Zeitspanne stattfindet. Also ist Deine Frage nicht zu beantworten. Sind 10min okay, ist so ziemlich alles Echtzeitfähig. Müssen es 5us sein, dürfte kein Realtime OS auf dem Markt genügen.
TL;DR. Ist das was akademisches? Ansonsten verweise ich mal auf die Begriffe "guaranteed latency and jitter". Die gibt man als Randbedingung vor, danach sucht man sich sein System aus. Kann ein x86 mit Windows sein, aber muss vielleicht auch bei strengeren Bedingungen ein DSP oder ein FPGA sein. Es gab mal eine Zeit, da waren "Echtzeit" und "Multitasking" tolle Schlagworte. Heute ist es "AI", "Edge Computing", vielleicht habe ich auch inzwischen wieder eine Menge verpasst.
Max M. schrieb: > Sina A. schrieb: >> echtzeitfähig > > Echtzeit bedeutet doch nur das eine Antwort innnerhalb einer definierten > Zeitspanne stattfindet. Also ist Deine Frage nicht zu beantworten. > Sind 10min okay, ist so ziemlich alles Echtzeitfähig. > Müssen es 5us sein, dürfte kein Realtime OS auf dem Markt genügen. so ist es, wie echtzeitfähig willst du denn sein?
Der Begriff der Echtzeit ist ein technischer und kein mathematischer , auch kein philosophischer. D.h. nicht alles was in die formale Definition passt ist auch Echtzeit. Es kommt auch auf den vorgesehenen Zweck an und man darf auch den zugrunde liegenden Begriff nicht ganz ausblenden, der ja die "Sofortigkeit" beschreibt. Das ist wie mit der technischen Dichtheit. Kein Gefäß ist hundert Prozent dicht, es gibt immer Diffusion, Leckage. Die technische Dichtheit ist dann letztlich das "Dicht-Genug". Und trotzdem würde man ein Netz oder Sieb nicht als "dicht" bezeichnen, auch wenn es für den Zweck eine vorteilhafte Stauung mitbringt. Weil der Zweck des Siebs der Durchlass ist. Und so ist der Zweck eines PC-Betriebssystems Programme möglichst schnell abzuarbeiten und nicht einzelne Zeiten zu garantieren. Erst wenn Maßnahmen implementiert werden, um Zeiten zu garantieren, kann man von einem Echtzeitbetriebssystem sprechen.
Sina A. schrieb: > -> die Zeit kann auch, wenn es Sinn macht, T=1h sein, solange man > garantieren kann, dass die Ausführung innerhalb dieser Zeit ausgeführt > wird. Theoretisch ja, praktisch nein. Ich kann auch als Fußlahmer an den Olympischen Spielen im 100m Sprint teilnehemen, ich komm halt nur bissel langsamer an ;-) Wenn RTOS was bedeuten soll, dann daß es was kann, was die Nicht-RTOS eben nicht können. > 1. Sind nicht alle Systeme letztendlich echtzeitfähig (selbst Windows > auf einem gewöhnlichen x86 system)? Nein! > Letztendlich müsste man nur alle > möglichen Events/Funktionen kennen, die von Windows ausgeführt und die > auf chipebene des x86 eingetaktet werden könnten. Eben diese kennt man nicht! Diese Komplexität ist nicht beherrschbar und kann nicht garantiert werden. Einfaches Beispiel. Meine PS4 hat eine 8-Kern CPU und noch viel fettere GPU. Trotzdem schafft es die Software auf dem Desktop, eben diese durch irgendwelche schwachsinnigen Netzwerkzugiffe oder sonstwas auszubremsen, sodaß sie für mehrere Sekunden stehen bleibt oder echt zäh reagiert. Und dort liegt ein Linux darunter! > Hierbei müsste man den > worst case ermitteln und könnte so die maximale Zeit berechnen, die für > die Ausführung einer bestimmten Funktion benötigt wird. Kann man praktisch nicht. > Wenn dieser z.b. > T=3min wäre, könnte man Windows doch als RTOS einsetzen, wo eben diese > Zeitperiode ausreicht. Nein. > -> ist somit jedes beliebige OS auf beliebigem Prozessor echtzeitfähig? Nein. > -> es ist nur ziemlich aufwendig, das zu machen (man müsste windows > vollkommen reverse-engineeren und den kompletten x86 chip kennen). Siehst du. > Sind > also OS nicht echtzeitfähig, wenn es einfach nur in der Praxis zu > teuer/aufwendig ist, eine garantierte Ausführungszeit zu berechnen? Nicht ganz. Es braucht noch ein wenig mehr, vor allem auf der Softwareebene, um eben diese deutlich bessere, "echte" Echtzeitfähigkeit zu erreichen. > 2. Ein RTOS kann doch gar nicht von sich selber behaupten, dass es > echtzeitfähig ist. Doch, wenn es das nachweisen kann. > Maßgeblich ist doch auch, auf welchem Prozessor > dieser läuft. Auch das kann man für die jeweilige Version bzw. Implementierung prüfen. > -> Ab wann ist somit ein RTOS echtzeitfähig? Wenn bestimmte Tasks/Threads/Interrupts GARANTIERT innnerhalb einer eher kleinen Zeit abgearbeitet werden, komme was wolle. Und wenn dieses Verhalten eher einfach für den Anwender erreichbar ist. > Wenn man alle > Berechnungsschritte des RTOS angeben kann, die für eine Aufgabe benötigt > werden? die genaue ausführungsdauer hängt dann vom verwendeten Prozessor > ab. Das ist nicht das Problem. > -> Kann ein RTOS seine Echtzeitfähigkeit verlieren, wenn man einen > Prozessor verwendet, der nicht echtzeitfähig ist? Nur, wenn man ein RTOS planlos auf eine neue, ggf. untaugliche Plattform transferiert. > 3. Das ist eine Folgefrage zu 2. > -> Sind nicht alle Prozessoren letztendlich echtzeitfähig? Ja. Aber was nützt dir die reine Hardware ohne passende Software? Und gerade größere CPUs bzw. SOCs brauchen ein Betriebssystem, um die Komplexität der Hardware handhaben zu können. Bare Metal macht da keiner mehr was. > Man muss nur > alle funktionen/events kennen, die auf chipebene ablaufen können. Da gibt es keine Funktionen und Events, bestenfalls Interrupts. Und mit der Hardwareebene der Pipelines, Threads etc. will sich ein Programmierer nicht rumplagen. Das wäre auch Irrsinn. > -> Oder sagt man hier, dass es eben wieder viel zu kompliziert ist, alle > Effekte auf chipebene zu kennen, die die Rechenzeit beeinflussen > könnten? BINGO! > Sind also nur die Prozessoren echtzeitfähig, die man der Praxis > unter dem Gesichtspunkt der Echtzeitfähigkeit handlen kann? Das Problem hängt zu 99% am Betriebssystem (Software), nicht der CPU (Hardware). > -> Ein Cortex-M7 Prozessor ist auf jeden fall von einer Person zu > überblicken, um Echtzeitfähigkeit garantieren zu können. würdet ihr > sagen, dass ein Cortex-A9 Prozessor noch zu den echtzeitfähigen > Prozessoren zählt? Kann sein, muss nicht. > -> ein x86 würde ich auf jeden fall als zu kompliziert erachten, um hier > Echtzeitfähigkeit anbringen zu können. Ein 286er eher nicht, aktuelle I-whatever sicher schon. > Sind dann alle Geräte, die einen > x86 verwenden und von sich behaupten echtzeitfähig zu sein, überhaupt > nicht echtzeitfähig? NEIN! Das hängt von der Software ab!
Echtzeit läßt sich nicht einfach so überstülpen, sondern sie muß ermittelt werden. Dazu müssen die relevanten Funktionen durchlaufen werden, welche Zeit sie im worst case benötigen. Ein RTOS erlaubt es, den Zeitverbrauch zu nivellieren, d.h. länger dauernde Funktionen in mehrere Zeitscheiben zu unterteilen, damit kurze Funktionen schneller ausgeführt werden. Bzw. wichtige Funktionen können sogar eine höhere Priorität bekommen und langsame Funktionen weiter abbremsen (kleinere Zeitscheiben). Garantieren kann ein RTOS aber überhaupt nichts. Die Verantwortung liegt weiterhin beim Programmierer. Es kann sogar sein, daß eine Mainloop mit Interrupts viel echtzeitiger reagiert, da sie eine definierte Ausführungsreihenfolge und viel weniger Verwaltungsaufwand hat.
Sina A. schrieb: > Wenn dieser z.b. T=3min wäre, könnte man Windows doch als RTOS einsetzen, > wo eben diese Zeitperiode ausreicht. > -> ist somit jedes beliebige OS auf beliebigem Prozessor echtzeitfähig? Blöd ist aber, dass Echtzeit aufgrund des Einsatzes in Maschinensteuerungen in der echten Welt irgendwas mit ms zu tun hat und zwar im 1 oder höchstens 2-stelligen ms Bereich. > Letztendlich müsste man nur alle > möglichen Events/Funktionen kennen, die von Windows ausgeführt und die > auf chipebene des x86 eingetaktet werden könnten. Hierbei müsste man den > worst case ermitteln und könnte so die maximale Zeit berechnen, die für > die Ausführung einer bestimmten Funktion benötigt wird. Der Witz ist, dass dann auf einmal solche Sachen wie Prioritätsinversionen oder sonstige Deadlocks auftreten können, weil sich mal wieder ein Treiberprogrammierer nicht an die "üblichen" Regeln gehalten hat. Falk B. schrieb: > Das Problem hängt zu 99% am Betriebssystem (Software), nicht der CPU > (Hardware). Wir haben hier ein Echtzeitsystem, das im schlechtesten Fall 200µs Jitter erzeugt und zu tausenden im Feld läuft und produziert. Ich weiß also garantiert, dass meine Hardware schnell genug ist. Jetzt steht aber eine Portierung auf ein anderes OS an und auf einmal kommt die Aussage: die Hardware ist zu langsam. Dann kommen die Spezis aber ein wenig ins Straucheln, wenn ich frage: Warum?
Peter D. schrieb: > Garantieren kann ein RTOS aber überhaupt nichts. Die Verantwortung liegt > weiterhin beim Programmierer. Das passt m.E. nicht richtig zusammen. Natürlich garantiert ein Echtzeitbetriebssystem nicht, dass ein Anwendungsprogramm echtzeitfähig ist. Aber es garantiert, dass die nächste Zeitscheibe, die der Anwendungen zugeteilt wird, nie länger wie eine definierte Zeit auf sich warten lässt. Außerdem, dass gewisse Peripherie wie Ethernet auch solche definierten Maximalzeiten hat.
Sina A. schrieb: > Bei meiner Frage geht es mir um die > ursprüngliche Definition der Echtzeit: man kann eine Zeitperiode T > angeben, in der die Ausführung einer bestimmten Funktion garantiert > ausgeführt wird. > -> die Zeit kann auch, wenn es Sinn macht, T=1h sein, solange man > garantieren kann, dass die Ausführung innerhalb dieser Zeit ausgeführt > wird. Naja, dann wende deine Definitino doch mal auf deine eigenen Fragen an: Sina A. schrieb: > 1. Sind nicht alle Systeme letztendlich echtzeitfähig (selbst Windows > auf einem gewöhnlichen x86 system)? Letztendlich müsste man nur alle > möglichen Events/Funktionen kennen, die von Windows ausgeführt und die > auf chipebene des x86 eingetaktet werden könnten. Hierbei müsste man den > worst case ermitteln und könnte so die maximale Zeit berechnen, die für > die Ausführung einer bestimmten Funktion benötigt wird. Wenn dieser z.b. > T=3min wäre, könnte man Windows doch als RTOS einsetzen, wo eben diese > Zeitperiode ausreicht. > -> ist somit jedes beliebige OS auf beliebigem Prozessor echtzeitfähig? > -> es ist nur ziemlich aufwendig, das zu machen (man müsste windows > vollkommen reverse-engineeren und den kompletten x86 chip kennen). Sind > also OS nicht echtzeitfähig, wenn es einfach nur in der Praxis zu > teuer/aufwendig ist, eine garantierte Ausführungszeit zu berechnen? Ist denn irgendwo garantiert, daß Windows überhaupt antwortet? Wenn deine Echtzeitanforderung bei 1h liegt, wird auch ein lahmer Windowsrechner wahrscheinlich sehr oft rechtzeitig eine Antwort liefern. Es garantiet dir aber niemand, daß Windows nicht z.B. zwischendurch ein Update fährt und sogar den Rechner zwischendrin neustartet (ja, das tut Windows 10 seit einiger Zeit tatsächlich, wenn man das Update oft genug aufschiebt und Windows sich lange genug unbeobachtet fühlt). Selbst wenn dein Programm beim Systemstart neustartet ist nicht garantiert, daß es nach dem Update noch funktioniert. Du mußt den Begriff "Garantie" schon wortwörtlich nehmen. "Meist paßt dat schoa iwie" ist keine Garantie. Sina A. schrieb: > 2. Ein RTOS kann doch gar nicht von sich selber behaupten, dass es > echtzeitfähig ist. Maßgeblich ist doch auch, auf welchem Prozessor > dieser läuft. > -> Ab wann ist somit ein RTOS echtzeitfähig? Wenn man alle > Berechnungsschritte des RTOS angeben kann, die für eine Aufgabe benötigt > werden? die genaue ausführungsdauer hängt dann vom verwendeten Prozessor > ab. > -> Kann ein RTOS seine Echtzeitfähigkeit verlieren, wenn man einen > Prozessor verwendet, der nicht echtzeitfähig ist? Einen Prozessor, der nicht echtzeitfähig wäre, gibt es so eigentlich nicht. Das Betriebssystem steuert, wann was gemacht wird und besitzt insofern auch eine gewisse Kontroller darüber, was wann abgearbeitet wird. Das Betriebssystem hat natürlich auch seine Grenzen. Es kann einem Programm einen gewissen Anteil der Rechenzeit garantierten. Wenn das Programm selber aber nicht sicherstellen kann daß es innerhalb einer Frist mit seiner Verarbeitung fertig ist, kann das BS auch nichts mehr machen. Sina A. schrieb: > 3. Das ist eine Folgefrage zu 2. > -> Sind nicht alle Prozessoren letztendlich echtzeitfähig? Man muss nur > alle funktionen/events kennen, die auf chipebene ablaufen können. > -> Oder sagt man hier, dass es eben wieder viel zu kompliziert ist, alle > Effekte auf chipebene zu kennen, die die Rechenzeit beeinflussen > könnten? Sind also nur die Prozessoren echtzeitfähig, die man der Praxis > unter dem Gesichtspunkt der Echtzeitfähigkeit handlen kann? Wer > entscheidet dann, ab wann das zu kompliziert wird? > -> Ein Cortex-M7 Prozessor ist auf jeden fall von einer Person zu > überblicken, um Echtzeitfähigkeit garantieren zu können. würdet ihr > sagen, dass ein Cortex-A9 Prozessor noch zu den echtzeitfähigen > Prozessoren zählt? > -> ein x86 würde ich auf jeden fall als zu kompliziert erachten, um hier > Echtzeitfähigkeit anbringen zu können. Sind dann alle Geräte, die einen > x86 verwenden und von sich behaupten echtzeitfähig zu sein, überhaupt > nicht echtzeitfähig? So aus der Hüfte geschossen würde ich mal sagen, daß Prozessoren immer echtzeitfähig sind. Solange man sie frei programmieren kann und die Aufgabe in einer maximalen Zeitspanne immer berechenbar ist, müßte sich Echtzeitfähigkeit herstellen lassen. Aber wie gesagt – es kommt vor allem auf die Software (sowohl BS als auch das Programm selbeR) an, die darauf laufen.
Maxe schrieb: > Aber es garantiert, dass die nächste Zeitscheibe, die der > Anwendungen zugeteilt wird, nie länger wie eine definierte Zeit auf sich > warten lässt. Außerdem, dass gewisse Peripherie wie Ethernet auch solche > definierten Maximalzeiten hat. Nein. Ein RTOS kann Dir Mittel bereitstellen, dass Du das garantieren kannst. Aber ein RTOS berechnet nicht die Maximallaufzeit aller Interrupts die verschachtelt auftreten können oder bewertet DI-Zeiten, um irgendwas zu garantieren.
Hier findest Du viele Antworten: (dei nicht ChibiOS spezifisch sind) http://www.chibios.org/dokuwiki/doku.php?id=chibios:documentation:books:rt:start
Zu windows: Windows ist nicht echtzeit fähig, das hat wenn mich nicht alles täuscht selbst ms gesagt. - Bluescreens, Windows hat eine gewisse komplexität erreicht, in der abstürtze des ganzen systems immer mal wieder auftauchen. zwar seltener geworden, aber treten immer noch auf. und die kommen wenn aus heiterem Himmel und meist nicht reproduzierbar. - Es ist durch aus möglich mit amoklaufenden Prozessen ein Windows system so weit in die kniehe zu zwingen, das es fast nicht mehr bedienbar ist. einen aktuellen x86 echtzeitfähig zu machen, ist durch aus möglich. Linux liefert entsprechende Patche, und auch für windows gibt es "lösungen". NI hat da was. (da läuft dann windows in einer Task des Echtzeit OS von NI, ... oder NI und windows teilen sich die cors entsprechend auf.) und auch ein EmbeddedRealTime OS kann ein Programmieruer kaput programieren. - In irgend einem Interrupt irgend welche langwieren operationen durchführen. egal wie die Interrupt logik aussieht kann das über kurz oder lang zum StackOverflow oder miss timing führen, ... - In eiem loop programm ist der längste programmzweig länger als die mindest reaktionsszeit
Fitzebutze schrieb: > Heute ist es "AI", "Edge Computing" Cloud Computing: Oller Hut. Begann ja mal alles mit dummen Terminals die kaum mehr als IO Geräte waren. Aber Cloud hört sich einfach extrem scharf und total neu an. Niemand will ein dummes Terminal, aber so ein hochmodernes Chromebook ist ja eine ganz andere Nummer. Und das ich keine Ahnung habe in welchem Rechtsraum meine Daten nun möglichst effizient ausgespäht und gewinnbringend vermarktet werden, wird euphemistisch als 'Wolke' bezeichnet. Edge Computing: Daten werden lokal verarbeitet. Krasser neuer Scheiss. Also damals, als man die doofen Terminals in den Container warf weil es brauchbare und bezahlbare Computer gab, die keine mittlere Turnhalle als Stellplatz brauchten und sich über schneckige Datenleitungen quälen mussten. AI: Früher hieß das Mustererkennung. Da AI einfach nicht wirklich intelligent werden will, gibt es YT um das fortschreiten der ND (natürliche Dummheit) zu fördern, damit der Gap zwischen AI und ND kleiner wird. AI wird sicher cleverer als Menschen werden. Aber nicht unbedingt cleverer als kluge Menschen. Ein strunzdoofer, restalkoholisierter Vollpfosten würde vielleicht eine Fahradwegbegrenzung rammen, auf eine Staßenbahnspur wechseln wollen und rote Ampeln überfahren. Das bekommt eine 'full self driving AI' im Tesla ja schon ganz gut alleine hin. 'Autopiloten' die zu schnell in eine enge Kurve fahren, Panik bekommen und ohne Vorwarnung mitten in der Kurve die Kontrolle an den Fahrer übergeben. Ein Volvo Fussgänger Kollisionsvermeidungssystem das im Kreis kotzt wenn in Australien Kängurus am Strassenrand hoppeln, AIs die behinderte Sportler mit Schrittgeschwingigkeit anfahren oder gleich den Fahrradschiebenden Fussgänger mit full speed übermangeln, weil sie zwar das Hinderniss erkannt haben aber ständig neu entscheiden was für eines es denn wohl ist. Eine dressierte Taube hätte intelligenter reagiert. Bremsassistenten, Kollisionsvermeidungssysteme die bei Vmax auf der Autobahn bei völlig freier Spur eine Notbremsung hinlegen und den Fahrer ins Amaturenbrett beissen lassen während der Hintermann ihm reinkachelt. Krasse Leistung! Schon toll was AIs heute alles so alleine schaffen. Einfachste Sachverhalte in einem sehr eng begrenzten Rahmen unter idealen Bedingungen und unter strenger menschlicher Aufsicht. Das ist ja wie eine Höhensicherung die jederzeit reissen kann wenn ich mich nicht gut festhalte. Nutzlos, gefährlich und im besten Fall ganz interessant und unterhaltsam. Was habe ich Tränen gelacht, als der Staubsaugerbot mich ständig angebettelt hat 'Ich brauche Hilfe'. Wenn ich meine Bude nicht Bot konform einrichte und nach seinem Scan unverändert lasse, kann der nix ausser rumheulen. Alexa versteht auch nur was sie verstehen will und ist nur sehr begrenzt von einer gewisse Nützlichkeit. Aber man kann Alexa gut verarschen und den Stolz ihrer Besitzer ein wenig erden. Schon lustig wenn Alexa minutenlang PI auf 100 Stellen runterbetet und sich nicht für Geld und gute Worte stoppen lässt. Also wenn AIs die Lösung sind, hätte ich gerne das Problem zurück. Realtime: Mein Code auf dem 8085 MFA System war schon Realtime. Höchst zweifelhaft ob ich das gleiche Zeitverhalten heute mit einem GHz Raspi und Realtime OS erreiche. Was ist eigentlich aus Fuzzi Logic geworden? 3D Displays und Brillen sind nun schon ca. 3mal der ganz neue heiße Scheiss gewesen den jeder braucht. Nur das man jedes mal einsehen musste das es eigentlich niemand braucht und man sprichwörtlich das Kotzen bekommt wenn man damit wirklich arbeiten will. Augmented Reality: Wow, was war das für ein Hype! Google Glass sollte die Welt verändern. Aber letztendlich doch nur ein Nische für sehr spezielle Aufgaben. Nur ständig eine neue Sau die durchs Dorf getrieben wird und solange der Begriff nur verdengschlischt wird, klingt jeder alte Hut irgendwie ganz schick und der trendbewusste Hippster muss es einfach haben. Früher traf ich mich mit Kumpels zum Fussi WM gucken. Heute gehe ich zum Public Viewing... Vollbart und ölige Langhaarmatte auf der Rübe aber rasierte Genitalien. Hauptsache einem Trend folgen auf der Suche nach einer eigenen Identität. Sich selbst als Individuum definieren indem ich Medienschlampen nacheifer und denen ein schönes leben finanziere weil ich jeden Kack kaufe den diese laufenden Verkaufsauslagen mir andienen. Hauptsache Trend und bloß nicht drüber nachdenken. Da bilden die technikaffinen keine Ausnahme.
Echtzeit bedeutet: 1. definiere die Zeitanforderungen deines Einsatzzwecks, die nicht verletzt werden dürfen, ggf. durch gesetzliche Vorgaben 2. implementiere ein System, von dem du denkst, das es diese Vorgaben erfüllt 3. beweise, das diese Vorgaben tatsächlich eingehalten werden durch a) Verwendungen von bereits erprobten Software-/Hardwarekkombinationen mit harter Ecktzeit Funktion b) eigene nachvollziebaren Tests des Laufzeitverhalten c) Tests / Hardware/Software Review eines qualifizierten externen Labors 4. fasse a,b,c in die Produktspezifikation zusammen 5. hafte bei Folgeschäden falls in 1,2,3,4 Fehler gemacht wurden Gerade Punkt 5 ist die größte Hürde bei der Implementierung eines harten Echtzeitsystems. Da trennt sich Spreu von Weizen. Siehe Medizinprodukte im Bereich Lebenserhaltung oder Fahrzeugtechnik - Elemente der Fahrzeugsicherheit Echtzeit bedeutet nicht, ein System aus echtzeitfähigen Einzelkomponenten ergibt ein echtzeitfähiges System. VG, dasrotemopped.
Bisher wurde oft gesagt, was Echtzeit definiert. - Innerhalb einer definierten Zeit zu antworten, immer -> hart RT - Innerhalb einer definierten Zeit zu antworten, meist -> soft RT Was sind die noetigen Richtlinien ? - Ein GUI wird ausgelagert. Mit einem GUI kann man die Prozesse bedienen, parametriesieren, kontrollieren, aber nie Echtzeit erfuellen. Deswegen laesst man ein GUI als niedrig priorisierten Thread nebendran laufen. Wenn's abstuerzt muss man's neu starten koennen, ohne den Rest zu unterbrechen. Das koennen die PC Betriebssysteme alle nicht. Linux koennte zumindest das, aber sobald ein Garbagecollektor auf Betriebssystem Ebene mitlaeuft war's das. Ich mach Echtzeit jeweils mit Controllern und habe ein PC GUI per Schnittstelle angehaengt zur Visualisierung, Parametrisierung und Kontrolle. Die kann man dann anstecken und abstecken, das ist dem Controller und seiner Echtzeit egal. Die laeuft weiter.
:
Bearbeitet durch User
> Hätte gerne eine finale Antwort
42
Wühlhase schrieb: > Das Betriebssystem hat natürlich auch seine Grenzen. Es kann einem > Programm einen gewissen Anteil der Rechenzeit garantierten. Wenn das > Programm selber aber nicht sicherstellen kann daß es innerhalb einer > Frist mit seiner Verarbeitung fertig ist, kann das BS auch nichts mehr > machen. Das ist eigentlich der Kern der ganzen Echtzeit-Sache in zwei schmalen Sätzen zusammengefaßt. Das Witzige ist: auf bare metal ohne jegliches RTOS ist's im Prinzip exakt dasselbe, bloß dass hier das RTOS durch die Hardware und deren Konfiguration "ersetzt" wird. Soll heissen: durch ein RTOS wird eigentlich nichts einfacher (zumindest nicht in Hinsicht auf die Sicherstellung der Echtzeitbedingung), aber alles langsamer durch den zusätzlichen Overhead des RTOS selber. Für eine gegebene Echtzeitspezififikation und eine gegebene Hardware wird es also durch ein RTOS schwieriger, die Spezifikation zu erreichen.
Ich hab hier viel mit ARINC-653 zu tun. Das ist eine Industrienorm aus der Luftfahrt für so eine Art RTOS. Der Scheduler arbeitet nach einem fest vorgegebenen Zeitschema, an dem sich zur Laufzeit nichts ändert. Hard- und Software zusammen müssen garantieren, dass Applikationen, die auf dem System laufen, den Scheduler und andere Applikationen nicht stören können. "Robust partitioning" nennt man das da. Wird eine Applikationen in der vorgegebenen Zeit nicht fertig, wird sie einfach abgeschossen und je nach Kopnfiguration neu gestartet oder nicht. Deshalb macht man sich vorab ganz viel Gedanken über die WCET (worst-case execution time) aller Routinen, meistens mit automatischen Tools. Weil sicherheitskritische Applikationen im Flugzeug heutzutage in der Regel modellbasiert entwickelt werden, d.h. der Quelltext automatisch erzeugt wird, ist ein einigermaßen sinnvoller Programmablauf sichergestellt. Also ohne Rekursion und ohne Schleifen mit Parametern, die von Eingaben abhängen. Ein solches System ist dann wirklich "fast garantiert" echtzeitfähig. Was vielleicht noch fehlt, ist ein 100% Schutz davor, dass in der Hardware mal einzelne Bits umkippen (zum Beispiel durch hochenergetische Teile). Aber dagegen gibt es auch erprobte Mechanismen.
Sina A. schrieb: > Meine Frage ist, in wie weit diese OS nun wirklich echtzeitfähig sind? Um diese Frage zu beantworten, müsstest du erstmal erzählen, was für dich "wirklich echtzeitfähig" bedeutet. Normalerweise bedeutet "echtzeitfähig", dass innerhalb einer garantierten Zeit auf externe Ereignisse reagiert wird. Wie lang diese Zeit ist, steht auf einem anderen Blatt.
Wühlhase schrieb: > Das Betriebssystem hat natürlich auch seine Grenzen. Es kann einem > Programm einen gewissen Anteil der Rechenzeit garantierten. Wenn das > Programm selber aber nicht sicherstellen kann daß es innerhalb einer > Frist mit seiner Verarbeitung fertig ist, kann das BS auch nichts mehr > machen. Du MUSST ja auch keine echtzeitfähige Anwendung auf einem RTOS implementieren. Auf einem RTOS KANNST du es tun. Deshalb spricht man hier von RTOS und nicht von RTS.
Wolfgang schrieb: > Normalerweise bedeutet "echtzeitfähig", dass innerhalb einer > garantierten Zeit auf externe Ereignisse reagiert wird. Wie lang diese > Zeit ist, steht auf einem anderen Blatt. Gut erklaert. Hier mal ein praktisches Beispiel: Du benutzt eine Linux-Box mit einem angeschlossenen MIDI-Keyboard, um deinen Lieblingssong einzuueben: Mit Pulseaudio und Konsorten wird da nicht viel Freude aufkommen, da dieser resourcenfreundlich erst einmal alle Sound-Ereignisse einsammelt. Das macht natuerlich nichts, wenn du ein MP3-File abspielst, aber es ist frustrierend, wenn ein Tastendruck auf einem MIDI-Keyboard eine merkliche Verzoegerung hat. Wenn du stattdessen jackd als Soundserver installierst, ist die Verzoegerung verschwunden, da der Sound in Echtzeit ausgegeben wird. Der Preis ist, dass deine CPU Load (load average) heraufgehen wird.
Wolfgang schrieb: > Sina A. schrieb: >> Meine Frage ist, in wie weit diese OS nun wirklich echtzeitfähig sind? > > Um diese Frage zu beantworten, müsstest du erstmal erzählen, was für > dich "wirklich echtzeitfähig" bedeutet. Das hat sie getan.
Sina A. schrieb: > 1. Sind nicht alle Systeme letztendlich echtzeitfähig > (selbst Windows auf einem gewöhnlichen x86 system)? M.E. Nein. > Letztendlich müsste man nur alle möglichen > Events/Funktionen kennen, die von Windows ausgeführt > und die auf chipebene des x86 eingetaktet werden > könnten. Hierbei müsste man den worst case ermitteln > [...] Wie willst Du den "worst case" dafür berechnen, dass das System von einem Update blockiert wird, das nicht eingespielt werden kann? Oder wenn die Weiterarbeit von einer Nutzereingabe abhängt, die nicht erfolgt? (Es genügt ja, dass es IRGEND einen Programmpfad gibt, in dem ein solcher Zustand eintreten kann -- dann ist Deine Laufzeitgarantie im Eimer...) > 2. Ein RTOS kann doch gar nicht von sich selber > behaupten, dass es echtzeitfähig ist. Das nicht -- aber der Entwickler kann es behaupten :) > Maßgeblich ist doch auch, auf welchem Prozessor dieser > läuft. Denke ich nicht. > -> Ab wann ist somit ein RTOS echtzeitfähig? Wenn man > alle Berechnungsschritte des RTOS angeben kann, die für > eine Aufgabe benötigt werden? Das ist notwendig, aber nicht hinreichend. Man muss auch garantieren, dass keine "Press any key to continue"-Konstrukte verwendet werden -- auch im übertragenen Sinne: Man darf KEINE Programmpfade haben, die ggf. nicht abbrechende Schleifen bilden können. (Zählschleifen mit a priori fester Zahl von Durchläufen sind natürlich erlaubt.) > die genaue ausführungsdauer hängt dann vom verwendeten > Prozessor ab. Ja -- aber das ist wurscht, denn die Summe einer endlichen Anzahl endlicher Größen ist stets endlich. Soll heißen: Die genaue Größe der Antwortzeit ändert sich, aber die jeweilige Antwortzeit kann trotzdem stets GARANTIERT werden. > -> Kann ein RTOS seine Echtzeitfähigkeit verlieren, wenn > man einen Prozessor verwendet, der nicht echtzeitfähig ist? Was stellst Du Dir unter einem "nicht echtzeitfähigen Prozessor" vor? > -> Sind nicht alle Prozessoren letztendlich echtzeitfähig? Das kann ich nicht beantworten; ich kenne nicht alle Prozessoren dieser Welt (nichtmal einen erheblichen Teil davon). Die Antwort hängt aber davon ab, ob sich für alle bei der Programmausführung auftretenden Zustände garantierte Maximalzeiten angeben lassen oder nicht. Bei den paar Prozessoren, mit denen ich bisher zu tun hatte, war das der Fall. > -> ein x86 würde ich auf jeden fall als zu kompliziert > erachten, um hier Echtzeitfähigkeit anbringen zu können. Wieso denn das? Wenn sich für sämtliche Befehle bzw. Prozessorzustände der erforderlichen Prioritätsstufe die maximalen Ausführungs- zeiten von vornherein konkret angeben lassen, dann sind auch für alle (endlichen) Programmpfade, die keine Rückwärtssprünge enthalten, die maximalen Ausführungszeiten angebbar. "Eine Summe endlich vieler endlicher Größen ist stets endlich." Es geht nicht darum, dass das "viele" Befehle bzw. Zustände sind, sondern dass es ENDLICH viele sind.
Nicht echtzeitfaehiger Prozessor ? Man muss es richtig machen, man muss es besser machen. Die Anwendung zerfaellt optimalerweise in viele kleine Stuecke welche alle einzeln in einer Zeitscheibe locker abgespult werden koennen. Dann hat man die chance mit einem kooperierenden Multitasksystem durchzukommen. Falls dem nicht so ist, weil zb ein Task alle paar minuten eine laengere floatingpoint rechnung machen muss, welche (viel) laenger wie eine Zeitscheibe ist, muss man mit einem Preemptive System arbeiten, welches die Task auch unterbrechen kann. Das ist etwas weniger ueberschaubar, und bringt zusaetzliche Probleme. Man kann sich auch an dieser Grenze entlang hangeln, indem man diese Floatingpoint rechnung in einzelne Schritte zerlegt, die alle in einer Zeitscheibe Platz haben. Indem man die Rechenzeit nach einem Zwischenresultat wieder zurueck gibt. Eine Zustandsmaschine macht das. Die Frage ist nun, wie es um die Ueberschichtlichkeit steht. Denn darum geht es mit Echzeit systemen. Man hat zwar den Ablauf verloren, Trotzdem muss man dokumentieren und debuggen koennen, ohne den Ablauf zu stoeren. Deswegen sind 15fach ineinander geschachtetelte Zustandsmaschinen schlechter wie ein kooperatives RTOS, und wenn dieses zu kompliziert wird, macht's ein preemptives wieder einfacher.
Gerhard schrieb: > Ich hab hier viel mit ARINC-653 zu tun. Das ist eine Industrienorm aus > der Luftfahrt für so eine Art RTOS. in de:WP angeschaut. Hat wohl auch schon einen Nachfolger: https://de.wikipedia.org/wiki/STANAG_4626 "Wesentlich für STANAG 4626 ist die strikte Trennung einer Funktion in Hard- und Software, also in die Anwendung und die von ihr genutzten Ressourcen. [...]. Aus der Trennung bei der Entwicklung und möglicherweise auch bei der Zertifizierung verspricht sich die Industrie hohe Kostenersparnisse bei zukünftigen Systemen."
Beitrag #6969747 wurde von einem Moderator gelöscht.
Beitrag #6969775 wurde von einem Moderator gelöscht.
Moin, Egon D. schrieb: > Was stellst Du Dir unter einem "nicht echtzeitfähigen Prozessor" > vor? Ich stell' mir darunter Prozessoren vor, die z.b. Caches haben, oder mit DRAM arbeiten oder wo neben dem Prozessor noch irgendein Stueck Hardware auf Speicher/IO blockierend zugreifen kann (jede Art von DMA). Denn da geht die Kacke schon los, dass man eben nicht mehr genau sagen kann, wieviele Zyklen irgendein Stueck Software brauchen wird. Gruss WK
Dergute W. schrieb: > dass man eben nicht mehr genau sagen kann, > wieviele Zyklen irgendein Stueck Software brauchen wird. Puh, das ist aber mal eine harte 'realtime' Definition. Genau genommen ist dann auch ein STM8 schon nicht mehr echtzeitfähig, weil man nicht exakt sagen kann wie viele Zyklen einige Maschinenbefehle benötigen. Deswegen gibts auch keine V-USB Lib für den STM8. Ein ATtiny erfüllt hier also die Echtzeitanforderung wg. seiner fixen und vorab bestimmbaren Zyklenanzahl. Der STM8 mit seiner moderneren Struktur, schafft das nicht, weil exaktes Timing über ASM Zyklen + NOPs hier nicht funktioniert. Also ist das olle AVR Design mit fixer Zyklenanzahl Echtzeitfähig, eine moderne CPU mit all ihren Tricks und Kniffen nicht? Obwohl die moderne CPU in einem Bruchteil der AVR Zeit reagiert? Radio Eriwan: Im Prinzip schon. Echtzeit ist doch immer eine Definition und wenn die nur eng genug ist, hat irgendwann auch ein FPGA Probleme mit Echtzeit. Ist sie lax genug schafft auch ein 8051 mit den uralt Basic Interpreter Echtzeit.
Dergute W. schrieb: > dass man eben nicht mehr genau sagen kann, > wieviele Zyklen irgendein Stueck Software brauchen wird. Das ist ja auch nicht nötig. Du mußt nur für jedes Stück Deiner Software garantieren können, daß es längstens nach einer vorgegeben Zeit fertig sein wird.
mIstA schrieb: > Das ist ja auch nicht nötig. Du mußt nur für jedes Stück Deiner Software > garantieren können, daß es längstens nach einer vorgegeben Zeit fertig > sein wird. Ja. Je nach Zeitvorgabe kann das "garantieren" halt beliebig unangenehm/unmoeglich werden auf CPUs, die Features haben, die ich weiter oben beschrieben hatte... Gruss WK
Suchst du sowas in der Art? Beitrag "RTOS für MSP430" Hier weitere Infos dazu: https://www.freertos.org/RTOS.html
:
Bearbeitet durch User
Vielen Dank für die regen Antworten! Max M. schrieb: > Sina A. schrieb: >> echtzeitfähig > > Echtzeit bedeutet doch nur das eine Antwort innnerhalb einer definierten > Zeitspanne stattfindet. Also ist Deine Frage nicht zu beantworten. > Sind 10min okay, ist so ziemlich alles Echtzeitfähig. > Müssen es 5us sein, dürfte kein Realtime OS auf dem Markt genügen. hierbei ist ja die ganze zeit meine Frage, in wie weit eine Garantie gegeben werden kann. die Betriebssysteme schimpfen sich zwar RTOS, aber kann man doch gar nicht garantieren, dass die Zeiten eingehalten werden (egal ob 5us oder 10min). Bei einem mikrocontroller bis zur Cortex-M klasse kann ich genau sagen, wieviele takte notwendig sind und was im worst case alles dazwischenfunken kann. jedoch kann man das doch gar nicht bei einem pentium rechner mit VxWorks drauf?? Maxe schrieb: > Der Begriff der Echtzeit ist ein technischer und kein mathematischer , > auch kein philosophischer. D.h. nicht alles was in die formale > Definition passt ist auch Echtzeit. Es kommt auch auf den vorgesehenen > Zweck an und man darf auch den zugrunde liegenden Begriff nicht ganz > ausblenden, der ja die "Sofortigkeit" beschreibt. Das ist wie mit der > technischen Dichtheit. Kein Gefäß ist hundert Prozent dicht, es gibt > immer Diffusion, Leckage. Die technische Dichtheit ist dann letztlich > das "Dicht-Genug". Und trotzdem würde man ein Netz oder Sieb nicht als > "dicht" bezeichnen, auch wenn es für den Zweck eine vorteilhafte Stauung > mitbringt. Weil der Zweck des Siebs der Durchlass ist. Und so ist der > Zweck eines PC-Betriebssystems Programme möglichst schnell abzuarbeiten > und nicht einzelne Zeiten zu garantieren. Erst wenn Maßnahmen > implementiert werden, um Zeiten zu garantieren, kann man von einem > Echtzeitbetriebssystem sprechen. und genau diese maßnahmen stelle ich in frage, wenn so ein RTOS auf einem Cortex A prozessor läuft (oder i7 etc). die einzige erklärung, die ein wenig darauf eingeht, was unabhängig vom Betriebssystem an delays hinzukommen kann hab ich hier gefunden: https://community.arm.com/support-forums/f/embedded-forum/6299/cortex-a-vs-cortex-m-real-time-applications. Und dann ist da noch mehr, wenn es richtung multicore prozessor geht... wie kann man da bei einem RTOS bestimmte Zeiten garantieren, wenn schon durch den prozessor unvorhergesehene delays dazu kommen können? Wühlhase schrieb: > Einen Prozessor, der nicht echtzeitfähig wäre, gibt es so eigentlich > nicht. Das Betriebssystem steuert, wann was gemacht wird und besitzt > insofern auch eine gewisse Kontroller darüber, was wann abgearbeitet > wird. > [...] > So aus der Hüfte geschossen würde ich mal sagen, daß Prozessoren immer > echtzeitfähig sind. Solange man sie frei programmieren kann und die > Aufgabe in einer maximalen Zeitspanne immer berechenbar ist, müßte sich > Echtzeitfähigkeit herstellen lassen. > > Aber wie gesagt – es kommt vor allem auf die Software (sowohl BS als > auch das Programm selbeR) an, die darauf laufen. somit wäre doch auch ein Prozessor schon für den echtzeitbetrieb auszuschließen, oder nicht? (siehe begründung oben) 123 schrieb: > einen aktuellen x86 echtzeitfähig zu machen, ist durch aus möglich. > Linux liefert entsprechende Patche, und auch für windows gibt es > "lösungen". NI hat da was. (da läuft dann windows in einer Task des > Echtzeit OS von NI, ... oder NI und windows teilen sich die cors > entsprechend auf.) was mir halt sorge macht, dass da immer echtzeit draufsteht... aber dann eben sowas darunter verstanden wird wie: echtzeit ist ja eben kein mathematischer begriff... nichts ist komplett wasserdicht... ich möchte das ja nicht schlechtreden, aber kann ich dann nicht entscheiden, ob ich eine solche technologie verwenden kann, um eben systeme zu bauen, bei denen 20ms verspätung menschenleben fordern (extremes beispiel um meinen punkt klar zu machen). Markus H. schrieb: > 2. implementiere ein System, von dem du denkst, das es diese Vorgaben > erfüllt > 3. beweise, das diese Vorgaben tatsächlich eingehalten werden durch > a) Verwendungen von bereits erprobten Software-/Hardwarekkombinationen > mit harter Ecktzeit Funktion 3a) damit kann man doch gar nicht mehr fahren, weil jeder was anderes unter echtzeit versteht. der begriff wie hier mehrfach geschildert kein eindeutiger ist. und es steht trotzdem überall echtzeit drauf!?!? daher meine fragen um das weiter zu hinterfragen. c-hater schrieb: >> Das Betriebssystem hat natürlich auch seine Grenzen. Es kann einem >> Programm einen gewissen Anteil der Rechenzeit garantierten. Wenn das >> Programm selber aber nicht sicherstellen kann daß es innerhalb einer >> Frist mit seiner Verarbeitung fertig ist, kann das BS auch nichts mehr >> machen. > > Das ist eigentlich der Kern der ganzen Echtzeit-Sache in zwei schmalen > Sätzen zusammengefaßt. > > Das Witzige ist: auf bare metal ohne jegliches RTOS ist's im Prinzip > exakt dasselbe, bloß dass hier das RTOS durch die Hardware und deren > Konfiguration "ersetzt" wird. > > Soll heissen: durch ein RTOS wird eigentlich nichts einfacher (zumindest > nicht in Hinsicht auf die Sicherstellung der Echtzeitbedingung), aber > alles langsamer durch den zusätzlichen Overhead des RTOS selber. > > Für eine gegebene Echtzeitspezififikation und eine gegebene Hardware > wird es also durch ein RTOS schwieriger, die Spezifikation zu > erreichen. aber hier ignoriert ihr ja, dass schon der prozessor unvorhergesehene delays einbringen kann. Stichwort: cache miss, memory flaschenhals bei multicore prozessoren. Egon D. schrieb: >> die genaue ausführungsdauer hängt dann vom verwendeten >> Prozessor ab. > > Ja -- aber das ist wurscht, denn die Summe einer endlichen > Anzahl endlicher Größen ist stets endlich. Soll heißen: > Die genaue Größe der Antwortzeit ändert sich, aber die > jeweilige Antwortzeit kann trotzdem stets GARANTIERT > werden. > >> -> Kann ein RTOS seine Echtzeitfähigkeit verlieren, wenn >> man einen Prozessor verwendet, der nicht echtzeitfähig ist? > > Was stellst Du Dir unter einem "nicht echtzeitfähigen Prozessor" > vor? ein prozessor der so viele kniffe beinhaltet, dass es zu schwierig ist, eine aussage zu treffen, in wie weit es zu delays kommen kann. Stichwort: cache miss, memory flaschenhals bei multicore prozessoren. und bestimmt noch mehr und daher kann eben nicht garantiert werden wie lange das RTOS gerade braucht.
letztendlich läuft es wohl darauf hinaus, dass man einfach nicht so genau hinguckt... und wenn man nicht weiss was alles schief laufen kann (also wo noch zusätzliche delays auftauchen können) dann existieren diese einfach nicht. -> ist ein RTOS Max M. schrieb: > Dergute W. schrieb: >> dass man eben nicht mehr genau sagen kann, >> wieviele Zyklen irgendein Stueck Software brauchen wird. > > Puh, das ist aber mal eine harte 'realtime' Definition. > Genau genommen ist dann auch ein STM8 schon nicht mehr echtzeitfähig, > weil man nicht exakt sagen kann wie viele Zyklen einige Maschinenbefehle > benötigen. > Deswegen gibts auch keine V-USB Lib für den STM8. > Ein ATtiny erfüllt hier also die Echtzeitanforderung wg. seiner fixen > und vorab bestimmbaren Zyklenanzahl. Der STM8 mit seiner moderneren > Struktur, schafft das nicht, weil exaktes Timing über ASM Zyklen + NOPs > hier nicht funktioniert. wow, wieder was dazu gelernt... thx
Sina A. schrieb: > aber > kann man doch gar nicht garantieren, dass die Zeiten eingehalten werden Wie hier bereits geschrieben wurde muss es eine definierte Behandlung für Funktionen geben die nicht innerhalb einer definierten Zeit abgearbeitet sind, denn das ist per Defintion ein Fehler. Arbeiten die Funktionen wie erwartet, ist auch das Zeitverhalten definiert. Das geht natürlich bare Metal übersichtlicher. Hängt die SW, beißt der Watchdog zu. Rufe ich alle xx ms Timergesteuert meine IRQ auf, kann ich checken ob alle Funktionen ihre Arbeit getan habe und kann selber eine Fehlerbehandlung starten. Das beste Realtime OS kann natürlich nicht einen hängenden Task gesundbeten. Es kann aber den Task abschiessen, neu starten oder innerhalb der definierten Zeitspannen eine Fehlerbehandlung durchführen, die einen sicheren Zustand herstellt. Wer die Annehmlichkeiten eines OS will, bekommt eben nicht das Zeitverhalten einer bare metal MCU Umsetzung. Und Sicherheitsabschaltung muss eh die HW machen, weil SW defjnitiv unzuverlässiger ist als HW. Nur soll eben die HW Sicherheitsabschaltung nicht ständig triggern, nur weil das OS sich gerade die Nägel feilt. Ein RT OS hat aber wenigstens grundsätzlich einen Aufbau der ein definiertes Zeitverhalten zulässt. Im Gegensatz zu normalen OS wo man nicht garantieren kann das tatsächich binnen 300ms ein Uart Buffer gelesen wird. Mal gehts, mal läuft der über. Eine zeitliche Obergrenze ist nicht wirklich definiert. Kann auch mehrere Sek. dauern wenn irgendwas grad die CPU beschäftigt.
Letztlich stellt nur der Programmierer das Echtzeitverhalten her und das OS kann ihn dabei unterstützen oder ihm in die Parade fahren. Ich kann jedes RTOS aufs Kreuz legen, wenn ich ihm mehr Arbeit aufhalse, als die Hardware abarbeiten kann. Insofern zeichnet sich für mich ein Echtzeitsystem nur dadurch aus, daß es mich bei der Strukturierung der zeitlichen Zuordnung unterstützt. Das kann im Minimum ein 8051 mit einstellbarer Prio für verschiedene Interrupts sein, da steckt dann das OS im Interruptcontroller und die ganze Anwendung läuft in nested Interrupts. Das ist für mich das kleinste RTOS das ich kenne. Sorry, couldn't resist.
Sina A. schrieb: > Mir ist bewusst, dass es viele Echtzeit-Begriffe gibt, die alle nicht > wirklich definiert sind: firm-real-time, soft-real-time, > hard-real-time... jeder versteht unter diesen Begriffen immer etwas > leicht unterschiedliches Nicht bei denen, die damit arbeiten. Hard realtime: Eine verpasste Deadline richtet einen Schaden an, den ich nicht akzeptiere. Firm realtime: Eine verpaßte Deadline richtet einen Schaden an, den ich akzeptiere. Soft realtime: Eine verpaßte Deadline richtet keinen Schaden an, beschert mir aber einen entgangenen Gewinn (weniger Durchsatz). Jemand anderer Meinung?
Sina A. schrieb: > Wühlhase schrieb: >> Einen Prozessor, der nicht echtzeitfähig wäre, gibt es so eigentlich >> nicht. Das Betriebssystem steuert, wann was gemacht wird und besitzt >> insofern auch eine gewisse Kontroller darüber, was wann abgearbeitet >> wird. >> [...] >> So aus der Hüfte geschossen würde ich mal sagen, daß Prozessoren immer >> echtzeitfähig sind. Solange man sie frei programmieren kann und die >> Aufgabe in einer maximalen Zeitspanne immer berechenbar ist, müßte sich >> Echtzeitfähigkeit herstellen lassen. >> >> Aber wie gesagt – es kommt vor allem auf die Software (sowohl BS als >> auch das Programm selbeR) an, die darauf laufen. > > somit wäre doch auch ein Prozessor schon für den echtzeitbetrieb > auszuschließen, oder nicht? (siehe begründung oben) Ich gewinne so langsam den Eindruck daß du zum ersten Mal eine Aufgabe ohne Musterlösung bekommen hast und dein Fach einfach noch nicht verstanden hast. Wie kann man mit einer - durchaus brauchbaren - Definition ankommen und dann nicht in der Lage sein, diese auf seine Aufgabenstellung anzuwenden? Wenn du dein Programm in Assembler schreibst und auf ein Betriebssystem verzichtest, dann hast du doch alle Möglichkeiten und kannst jederzeit kontrollieren, wann was abgearbeitet wird. Warum soll also dein Prozessor nicht echtzeitfähig sein? SPS-System z.B. sind ja wohl definitiv echtzeitfähig, was meinst du was da wohl drinsteckt? Natürlich kann auch der beste, schnellste und echtzeitfähigste Prozessor dir nicht garantieren, daß dein Programm am Ende deine Echtzeitanforderungen auch immer liefert. Aber das liegt dann nicht am Prozessor. Wenn dein Programmentwurf scheiße ist, weil du z.B. einen Thread Deadlock gebaut hast, weil du vor der Ausgabe hart auf Daten aus einer unzuverlässigen Quelle wartest (und z.B. den Fall "Verlorener Stecker" nicht einkalkuliert hast, dein Programm wartet also bis zum jüngsten Tag auf Daten), weil du eine Endlosschleife programmiert hast, weil du...dann wird dein System halt nicht echtzeitfähig sein. Aber das hat dann weder etwas mit der Hardware noch mit deinem Echtzeitbetriebssystem zu tun. Sina A. schrieb: > was mir halt sorge macht, dass da immer echtzeit draufsteht... aber dann > eben sowas darunter verstanden wird wie: echtzeit ist ja eben kein > mathematischer begriff... nichts ist komplett wasserdicht... ich möchte > das ja nicht schlechtreden, aber kann ich dann nicht entscheiden, ob ich > eine solche technologie verwenden kann, um eben systeme zu bauen, bei > denen 20ms verspätung menschenleben fordern (extremes beispiel um meinen > punkt klar zu machen). Wenn du deinem Verkäufer nicht traust, dann mußt du dir einen anderen suchen. Und lerne, nach Zahlen, Tests und harten Fakten zu fragen. Wenn was garantiert ist - unter welchen Bedingungen gilt das? Natürlich ist Echtzeit kein mathematischer Begriff. Spannung, Strom, Kraft, usw. sind auch keine mathematischen Begriffe, trotzdem gibt es Definitionen dafür. Übrigens zum Thema Echtzeit mal ein Zeitproblem von der anderen Seite: Es gab bei uns mal ein Studienprojekt, dessen Aufgabe darin bestand irgendwelchen Graphikkrams zu berechnen und ich meine, auf einer VGA-Schnittstelle auszugeben. Die haben dafür einen STM32-Prozessor verwendet, jedoch ohne Erfolg, die Sache hat nicht funktioniert. Nicht weil der STM32 zu langsam war, sondern die Jungs haben vorher nicht gewußt daß das Ding eine Pipeline hat und daher manchmal schneller rechnete, als sie das erwartet hatten. Und dann kamen die Daten halt zu früh. Auch das ist eine Form von "nicht vorhersagbarer Ausführungszeit". In manchen Anwendungen kann man mit sowas gut leben, in anderen nicht. Aber auch dafür gibt es oft wieder Tricks... Hast du eigentlich jemals in deinem Leben ein Zeile Code geschrieben? Ein eigenes kleines Programm geschrieben? Auf einem AVR-Prozessor Assembler gelernt zu haben hat schon seine Vorteile.
Max M. schrieb: > Vollbart und ölige Langhaarmatte auf der Rübe aber rasierte Genitalien. Wenn du solche Sachen bei Tinder reinschreibst wundert mich dein angestauter Frust nicht.
Der Thread ist mal wieder ein exzellentes Beispiel für: Viele Köche verderben den Brei. Bisher hat noch keiner das Wort "deterministisch" benutzt. Das will der Prof nämlich hören :-) Wühlhase schrieb: > Warum soll also dein Prozessor nicht echtzeitfähig sein? SPS-System z.B. > sind ja wohl definitiv echtzeitfähig, was meinst du was da wohl > drinsteckt? Wer zyklengenaue, deterministische Abarbeitung braucht, hat für sowas einen DSP und lässt den entsprechenden Code im L1-SRAM ablaufen, wo kein Cache/Interrupt die Latenz versaut. Wer's auf einem von den vielen x86-Derivaten in bare-metal machen will, kann das auch tun, mit zyklengenau wird's da allerdings eher nix, fällt aber auch u.U. nicht ins Gewicht, bei 2 GHz. Und täglich grüsst das Murmeltier..
Also nur falls es jemand interessiert. In den Instrumenten, arbeitet ein LTOS das ist wirklich so das dort jedem Program Zeit Fis zugeteilt wird, Das muss so sein, den wenn du zum Beispiel 256 Polifonie brauchst dan darf nicht plötzlich eine "Stimme" oscillator etwas mehr Zeit brauchen, sonnst würde das Fürchterlich tönen. da muss wirklich "Live" jede Rutine genau in Ihrem vorgegebenen Zeitfenster sein. Da wird jeder Rutine die Zeit fesst zugeteilt, und das System berechnet die mögliche Rechenzeit, wenn diese erschöpft ist, wird keine Weitere Programm-Partition mehr zugeteilt. So wird Garantiert, das nicht plötzlich ein Ton eine andere Frequenz hat und sich Verstimmt. Bei Keyboards die beispielsweise nur 64 Polifon sind, kann dann passieren das währenddem Spielen plötzlich irgend etwas (das kann eine Trommel vom Schlagzeug, oder aber auch plötzlich ein anderes Instrument sein) Ist bei Billigen Orgeln oft der Fall dass man das hört. In Keyboards werden dazu oft DSP's verwendet, und eben ein LTOS L ife T ime O perating S ystem. Entweder sind dann halt mehrere Prozessoren verbaut, oder welche doie genug Performance haben.
:
Bearbeitet durch User
Klaus S. schrieb: > Ich kann jedes RTOS aufs Kreuz legen, wenn ich ihm mehr Arbeit aufhalse, > als die Hardware abarbeiten kann. Wie willst du es realisieren? Geht nur über Multitasking. Wenn das BS diese zu langen Prozesse blockiert, geht das schon. Die Rechnergeschwindigkeit spielt eine untergeordnete Rolle. Bestes Bsp. ist auch unter W10, wenn eine nicht lesbare CD/DVD das System lahmlegt. Das darf in einem Echtzeitsystem nicht passieren.
michael_ schrieb: > Klaus S. schrieb: >> Ich kann jedes RTOS aufs Kreuz legen, wenn ich ihm mehr Arbeit aufhalse, >> als die Hardware abarbeiten kann. > > Wie willst du es realisieren? > Geht nur über Multitasking. Wenn das RTOS etwas ungewollt blockiert, ist das Echtzeitverhalten im Eimer. Das nenne ich "aufs Kreuz legen". Geht mit repetitivem Interrupt und ausreichend langer ISR auch ohne Multitasking. Kann jeder Echtzeitprogrammierer im Halbschlaf.
Die finale Antwort: Ein Entwickler fragt nicht, ob irgendwas als echtzeitfähig vermarktet wird. Ein Entwickler überprüft, ob er mit dieser Hard- und Software maximale Latenz und Jitter einhalten kann. Übrigens, ein echtes RTOS hält die maximalen Antwortzeiten auch ein, wenn man während einer Mondlandung den Rechner ein paar mal neu bootet. https://www.youtube.com/watch?v=B1J2RMorJXM
Noch ein Kommentar schrieb: > Die finale Antwort: Ein Entwickler fragt nicht, ob irgendwas > als echtzeitfähig vermarktet wird. Ein Entwickler überprüft, > ob er mit dieser Hard- und Software maximale Latenz und Jitter > einhalten kann. Geht in der Praxis nicht. Das Alleinstellungsmerkmal eines Echtzeitsystems ist die GARANTIE für die Antwortzeit; die kann man aber in der Praxis nicht nachträglich überprüfen, weil das eine Testüberdeckung von 100% erfordern würde. Das geht in der Regel nicht. Eine Testüberdeckung von 98% ist aber keine Garantie, sondern ein "Meistens langt es..." Echtzeitfähigkeit muss in der Struktur angelegt sein.
Wühlhase schrieb: > Wie kann man mit einer - durchaus brauchbaren - > Definition ankommen und dann nicht in der Lage sein, > diese auf seine Aufgabenstellung anzuwenden? Warum wirfst Du das ausgerechnet dem Fragesteller/der Fragestellerin vor? Die meisten Antwortenden können das doch auch nicht. Den meisten Antworten entnehme ich ein komplettes Ignorieren der Unterscheidung zwischen "Gibt es eine Antwortzeit, die ich garantieren kann?" und " Wie lang ist die Antwortzeit, die ich garantieren kann?" > Warum soll also dein Prozessor nicht echtzeitfähig sein? > SPS-System z.B. sind ja wohl definitiv echtzeitfähig, was > meinst du was da wohl drinsteckt? SPS zählt nicht. SPS ist aus Sicht der "richtigen" Informatiker nur eine Hilfskrücke für debile Elektriker. Dass eine SPS natürlich echtzeitfähig ist, zählt auch nicht, denn das ist eben keine "richtige" Informatik. Und dass SPS-Programmierer die Probleme, die die "richtigen" Informatiker mit Echtzeit haben, nicht verstehen können, zeigt nur, WIE debil die SPS-Leute sind.
SPS ist eigentlich ein "Spagetti-Programm-Ablauf" Das heißt es wird immer der Reihenfolge abgearbeitet. Aber um dass genau zu Erklären müsste ich hier ein Roman schreiben und ist so weit weg von der Frage des TO dass ich mir das erspar.
Patrick L. schrieb: > SPS ist eigentlich ein "Spagetti-Programm-Ablauf" > > Das heißt es wird immer der Reihenfolge abgearbeitet. Und es gibt vor allem 1 Eingangsabbild, das sich während des gesamten Zyklus der Hauptschleife nicht ändert. Und es gibt 1 Ausgangsabbild, das nur am Ende des Zyklus geschrieben wird. Dadurch ersparen sich SPS-Programmierer 99% der Fehler, die dem "richtigen" Informatiker durch asynchron eintrudelnde Events das Leben schwer machen. Egon D. schrieb: > SPS ist aus Sicht der "richtigen" Informatiker nur eine Hilfskrücke für > debile Elektriker. Die Praxis sieht aber allzu oft so aus: der Schlosser und sein debiler Elektriker bekommen mit KOP und FUP die Maschine zum Laufen und fahren nach Hause. Und der "richtige" Informatiker sitzt immer noch an der Maschine und fragt sich, woher die Prioritäsinversion samt folgendem Deadlock bei seinen sich asynchron gegenseitig triggernden und verriegelnden 87 Threads auf dem 8-Kern Prozessor kommt...
:
Bearbeitet durch Moderator
Sina A. schrieb: > und genau diese maßnahmen stelle ich in frage, wenn so ein RTOS auf > einem Cortex A prozessor läuft (oder i7 etc). [...] > Und dann ist da noch mehr, wenn es richtung multicore prozessor geht... > wie kann man da bei einem RTOS bestimmte Zeiten garantieren, wenn schon > durch den prozessor unvorhergesehene delays dazu kommen können? Es wird ja nicht die exakte Zeit garantiert, sondern die maximale Zeit. Die diversen Delays vom Prozessor sind dann nicht "unvorhergesehen". Zumindest der gute Entwickler wird sie berücksichtigen. Ein Cache-Flush braucht eine bestimmte Zeit, ein Sprungbefehl löst evtl. ein langsames Nachladen von Code aus, aber auch das ist in einer bestimmten Zeit beendet. Die Zeitscheiben werden über Interrupts ausgelöst, der Aufruf braucht eine bestimmte Zeit, bzw. bewegt sich in einem gewissen Rahmen. "Garantierte Zeiten" heißt aber auch nicht, dass sie im einzelnen dokumentiert sein müssen. > was mir halt sorge macht, dass da immer echtzeit draufsteht... aber dann > eben sowas darunter verstanden wird wie: echtzeit ist ja eben kein > mathematischer begriff... nichts ist komplett wasserdicht... Du hast das falsch verstanden. Eine echte Gleichzeitigkeit zwischen Ein- und Ausgang (Steuerung) kann es schon physikalisch nicht geben. Selbst bei einer analogen Steuerung/Regelung muss sich das elektrische Feld erst durch die Schaltung arbeiten, bis es beim Ausgang ankommt. Beim Prozessor kann es erst recht keine echte Gleichzeitigkeit geben, da ja die einzelnen Befehle hintereinander abgearbeitet werden müssen. Die Echtzeit bedeutet dann einfach "gleichzeitig genug". Und dieses "gleichzeitig genug" ist eben auch selbst bei schnellen Prozessoren kaputt, wenn es einzelne Ereignisse gibt, die die Abarbeitung der zeitkritischen Aufgaben für zu lange Zeit unterbrechen, sei es durch die Hardware oder Software.
Die Grenzen zwischen der klassischen SPS und dem frei programmierbaren System sind auch schon lange recht verschwommen. Ich habe noch an den ollen ABB, OMRON und Siemens SPS Kisten herumgemacht. So richtig mit gigantomanischem 'Programmiergerät' auf Rollwagen mit Röhrenmonitor. Mit FUP, KOP, AWL kann der geschulte Betriebselektriker kleine Änderung machen oder herausfinden warum die Kiste sich weigert zu laufen. Das hörte auch damals schon ratz fatz auf trivial zu sein, wenn die Abläufe komplexer wurden und ich behaupte das so manch 'richtiger Programmierer' ziemlich blöd aus der Wäsche schauen würde, wenn er sich mal das SPS Programm einer größeren Maschine reinzieht auch wenn sie 20J alt ist. Heute sind die größeren SPS ohnehin PCs die man in vielen Sprachen programmieren kann, mit IOs die in einer industriellen Umgebung nicht sofort die Grätsche machen und LIBs die komplexe Funktionen auf standartisierter HW abbilden. Wenn eine Stillstandsstunde 10K€ kostet ist man sehr, sehr froh, wenn man bei der Fehlersuche die klassischen FUP, KOP, AWL Geschichten vor Augen hat. Klar, kann ich alles mit einem Arduino und I2C Expander mit Aliexpress Relaiskarte für 1% des SPS Preises machen. Aber wer mal gesehen hat wie eine Kugelmühle mit 5m Länge und 3m Durchmesser zur Hälfte gefüllt mit 2cm Stahlkugeln im Überlastbetrieb anläuft, das Schütz in der Größe einer kleinen Mikrowelle mit KAWUMMS reinhaut und das Bild des 2m entfernt stehenden Röhrenmonitors durch die Magnetfelder ausflippt, der setzt dann doch lieber auf eine SPS die das alles klaglos 50mal am tag für die nöchsten 20J erträgt.
Wir sollten langsam zum Punkt kommen, wie man ein Realtime system kaputt machen kann, naemlich mit falscher Software und duemmlichen Algorithmen. Wenn ich alse eine Antwortzeit definiere, und als zu leistende Arbeit eine Rekursion von unbestimmter Tiefe, war's das. Wenn der Algorithmus Muell ist und mit einer Exception abstuerzt, zB 1/0. Dann kann man schon ein Exceptionhandling aufsetzen, das Resultat aber nicht hilft... Mit dynamischen Objekten arbeite, und den Garbage Collector das Memory aufsammeln lasse... Man sollte sich bei der Dimensionierung vornehmen, dass der Prozessor niedrig ausgelastet ist. zB < 20%.
:
Bearbeitet durch User
> Das Alleinstellungsmerkmal eines Echtzeitsystems ist die GARANTIE für die
Antwortzeit
Deine Aussage ist natürlich richtig. Reicht aber nicht aus.
Der Marketingbegriff "RTOS" ist nur eine Voraussetzung, damit du dir das
System näher anschaust.
Aber die Frage "wirklich echtzeitfähig" bringt uns nicht weiter. Du hast
unterschiedliche Anforderungslisten. Bei einem 3D Drucker im
Bastelkeller hast du andere Anforderungen, als bei der Notabschaltung
eines Atomkraftwerkes.
Die Frage "Ist ein RTOS, das sich nur für 3D Drucker eignet, wirklich
echtzeitfähig?" erscheint mir unsinnig.
Weshalb denn ? Ein Echtzeitsystem fuer einen 3D Drucker laeuft allenfalls schon auf einem Mega32. Ein notfall abschalt fuer ein AKW allenfalls auch. Und falls nicht, nicht.
Max M. schrieb: > AI wird sicher cleverer als Menschen werden. > Aber nicht unbedingt cleverer als kluge Menschen. Immerhin hat Joseph Weizenbaums ELIZA schon 1966 cleverere Dinge gesagt als Du.
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.