Hallo, bevor ich jetzt richtig in die Theorie von Echtzeitprogrammierung einsteige und Queues und Semaphores lerne, wollte ich erstmal ganz allgemein den Sinn der Echtzeitprogramiierung nachvollziehen.. Ich programmiere eigentlich schon seit einiger Zeit Mikrokontroller und die reagieren auf verschiedene Ereignisse mehr oder weniger zeitnah, also was soll denn der eigentlicher Sinn der Echtzeitprogrammierung und verschiedener Betriebssysteme wie FreeRtos usw sein? da wurde ich im Internet leider nicht viel weitergeholfen. freue mich auf Eure Hilfe! Alex
Echtzeit ist ein komischer Begriff.... Eigentlich sagt es nur, dass eine garantierte Reaktionszeit eingehalten wird. Das können Sekundenbruchteile sein, aber auch Stunden.
Alex S. schrieb: > Ich programmiere eigentlich schon seit einiger Zeit Mikrokontroller > .... > eigentlicher Sinn der Echtzeitprogrammierung und > verschiedener Betriebssysteme wie FreeRtos usw sein? Du kennst den Unterschied zwischen EINEM Programm das auf einem µC läuft und einem BETRIEBSSYSTEM? Bei einem Echtzeitbetriebssystem kannst du die Reaktionszeit vorhersagen, bei den anderen nicht. (mal so ganz grob gesagt)
ok das heißt, der eigentliche Unterschied liegt halt nur darin (abgesehen davon, dass man in einem Betriebssystem programmiert), dass die Reaktionszeit vorhersehbar ist..? verstehe ich das richtig, oder gibt es noch was ausschlaggebendes, was ich da nachvollziehen soll? momentan ist für mich da noch alles dunkel
@ Alex S. (sirius7) >ok das heißt, der eigentliche Unterschied liegt halt nur darin >(abgesehen davon, dass man in einem Betriebssystem programmiert), Nö, man kann auch ohne Betriebssystem Echtzeit erreichen, bisweilen sogar einfacher ;-) >dass >die Reaktionszeit vorhersehbar ist..? Ja. >verstehe ich das richtig, oder >gibt es noch was ausschlaggebendes, was ich da nachvollziehen soll? Nein. Echtzeit ist nur ein Schlagwort für's Bullshitbingo.
Alex S. schrieb: > dass > die Reaktionszeit vorhersehbar ist..? Ja! Wikipedia: Echtzeit Sagt das gleiche, nur mit viel mehr Worten...... Lohnt sich zu lesen!
Teo D. schrieb: > Bei einem Echtzeitbetriebssystem kannst du die Reaktionszeit > vorhersagen, bei den anderen nicht. (mal so ganz grob gesagt) Natuerlich kann man auf einem µC vorhersagen, wie lange es braucht, auf etwas zu reagieren. Wenn du keine Interrupts benutzt und nur pollst ist das kein Problem.
1 | int main(void) |
2 | {
|
3 | while(1) { |
4 | if(hat der UART Datenempfangen) { |
5 | // mach was mit den Daten
|
6 | }
|
7 | |
8 | |
9 | if(hat der I²C Datenempfangen) { |
10 | // mach was mit den Daten
|
11 | }
|
12 | |
13 | }
|
14 | return 0; |
15 | }
|
Hier kann man sehr wohl vorher sagen, wie lange es braucht (sowohl im günstigsten als auch im schlechtesten falle), um auf empfangene Daten zu reagieren, und wie lange es dauert, bis diese fertig verarbeitet sind (in abhängigkeit von dem µC). Ganz ohne Betriebssystem. Einfach Compilieren, den Asm-Code anschauen und Takte zählen. Oder gleich in ASM programmieren. Ein OS nimmt einem aber ein paar sachen ab, um die man sich sonst zu fuss kümmern müsste, z.B. Kontextwechsel wenn mehr als nur eine Aufgabe ausgeführt wird, scheduling, etc. pp. Ulrich F. schrieb: > Echtzeit ist ein komischer Begriff.... > > Eigentlich sagt es nur, dass eine garantierte Reaktionszeit eingehalten > wird. Das können Sekundenbruchteile sein, aber auch Stunden. Nicht ganz, denn man muss unterscheiden zwischen harter und weicher Echtzeit. harte Echtzeit: Deadlines sind unter allen umständen einzuhalten. Eine verletzung der Deadlines führt sofort zu fehlern im System. weiche Echtzeit: Es gibt keine garantie das Deadlines eingehalten werden. Eine Verletzung von Deadlines hat keine schwerwiegenen Fehler zur folge und können ignoriert werden. Es gibt eine Garantie, dass Reagiert wird, aber nicht wann. Aber ja: Echtzeit ist nicht als konkreter Zeitwert definiert (z.B. 5ms). Das Zeitfenster hängt von der Aufgabe ab. Eine Raketenabwehranlage oder ein Industrieroboter hat andere Zeitanforderungen als die Druckerpresse bei der Bildzeitung.
ich frage mal so, was kann ein Beispiel sein, wo eine Programmierung mit freeRtos vorteilhafter ist, als einfach auf eine signal=true mit Mc zu reagieren?
Alex S. schrieb: > was kann ein Beispiel sein, wo eine Programmierung mit > freeRtos vorteilhafter ist Wenn du bzw. das System mehr als eine Aufgabe hat - z.B. eine Regelung, das Führen von Log-Dateien und die Bearbeitung von Benutzer-Eingaben. Nimm eine Heizungsregelung state of the art: ohne die Temperaturregelung zu beeinträchtigen muss das System im Internet der Dinge ständig Google drüber informieren, welche Temperatur deine Räume haben. Das willst du sicher nicht alles zu Fuss programmieren. Es gibt zahllose Werkzeugmaschinen, die einerseits Bearbeitungen durchführen, andrerseits den Benutzer über Bildschirm informieren und Daten mit einem Leitrechner austauschen. Für die Punkte 2 und 3 ist Windows Ok, aber nicht für das fräsen einer Freiformoberfläche, da braucht man ein System, dass garantiert keine Löcher ins Werkstück fräst bloss weil gerade von der Festplatte oder DVD gelesen wird - und das ist ganz sicher nicht Windows, sondern eben ein Echtzeitsystem. Georg
Kaj schrieb: > Eine Raketenabwehranlage oder ein Industrieroboter hat andere > Zeitanforderungen als die Druckerpresse bei der Bildzeitung. Nein, der Druckmaschine ist es egal, was sie druckt. Den Druckern vielleicht nicht, aber das ist hier nicht relevant. Im Zeitungsdruck sind heute Geschwindigkeiten von bis 75000 Exemplare/h ueblich, also etwas mehr als 20 Ex./s. wendelsberg
Hallo Georg, jetzt leuchtet es ein, vielen Dank für die gute Erklärung!
Kaj schrieb: > weiche Echtzeit: > Es gibt keine garantie das Deadlines eingehalten werden. Eine Verletzung > von Deadlines hat keine schwerwiegenen Fehler zur folge und können > ignoriert werden. Es gibt eine Garantie, dass Reagiert wird, aber nicht > wann. Und was ist daran bitte Echtzeit? Das ist bestenfalls eine Beschreibung der Anforderungen eines zu steuernden Prozesses.
Alex S. schrieb: > Ich programmiere eigentlich schon seit einiger Zeit Mikrokontroller und > die reagieren auf verschiedene Ereignisse mehr oder weniger zeitnah, > also was soll denn der eigentlicher Sinn der Echtzeitprogrammierung und > verschiedener Betriebssysteme wie FreeRtos usw sein? Echtzeit heißt, daß die Reaktion nicht "mehr oder weniger zeitnah" ist, sondern garantiert innerhalb einer gewissen Zeit erfolgt. Kaj schrieb: > Teo D. schrieb: >> Bei einem Echtzeitbetriebssystem kannst du die Reaktionszeit >> vorhersagen, bei den anderen nicht. (mal so ganz grob gesagt) > Hier kann man sehr wohl vorher sagen, wie lange es braucht (sowohl im > günstigsten als auch im schlechtesten falle), um auf empfangene Daten zu > reagieren, und wie lange es dauert, bis diese fertig verarbeitet sind > (in abhängigkeit von dem µC). Ganz ohne Betriebssystem. Ja, aber oben ging es explizit um den Fall mit Betriebssystem. Und wenn das nicht echtzeitfähig ist, ist auch das darin laufenden Programm nicht echtzeitfähig, unabhängig davon, auf welcher Hardware das läuft. > Einfach Compilieren, den Asm-Code anschauen und Takte zählen. Oder gleich > in ASM programmieren. Takte zählen geht auch nur auf den einfachsten Prozessoren wie z.B. AVR. Bei den meisten Prozessoren hängt die genaue Ausführungszeit von sehr vielen Faktoren ab, wie z.B. Cache, TLB, Branch Prediction, Wait States u.s.w.
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.