Wofür und wann ein RTOS verwenden?

[Lutz (Gast)]

Hallo,

gerade habe ich einige Threads gelesen, wo unterschiedlichste Ansichten 
zum Thema RTOS auf uC vertreten wurden. Leider habe ich irgendwie außer 
den Grunddefinitionen eines RTOS nicht wirklich was zum Thema finden 
können. Ich "spiele" noch in der kleinsten Anfängerliga und würde gerne 
wissen, ob das was wissenswertes für mich ist bzw. bald wird oder nicht.

1.) Wann bzw. wozu braucht man eines (Anwendungsbeispiele)?
2.) Was sind die Unterschiede z.B. zu Interruptroutinen?
3.) Wie unterscheidet sich praktisch die Programmierung?

Danke im Voraus
Lutz

[embedded-os (Gast)]

schau mal, ob dir die Links in nachfolgender Seite weiter helfen.
Leider sind gute Erklärungen in Deutsch selten geworden ..

http://www.embedded-os.de/index.html?links.htm

[3358 (Gast)]

Mit dem Aufwand von unten kommend hat man irgendwann eine Statusmaschine 
im Main und einen Satz Interruptroutinen. Damit kann man eigentlich 
alles machen. Mit zunehmender kompexitaet der Statusmaschine wird diese 
schwerer wartbar. Dann wird es Zeit fuer ein RTOS. Der Preis ist der 
Determinismus, den man mit einer Statusmaschine noch hat und mit einem 
RTOS nicht mehr hat. Der Gewinn ist die Uebersichtlichkeit, die 
Wartbarkeit.

[Moritz E. (devmo)]

Ich würde sagen RTOS fängt da an, wo es um Nebenläufigkeit geht, 
außerhalb der interrupt ebene? also ner einfachen prozess-liste die im 
main durchgegangen wird

[PS (Gast)]

> Der Preis ist der
> Determinismus, den man mit einer Statusmaschine noch hat und mit einem
> RTOS nicht mehr hat.

Echtzeitbetriebssysteme sind aber dafür gemacht, dass man
damit Anwendungen mit exakt vorhersagbarem Zeitverhalten
implementieren kann.

[3359 (Gast)]

Ja, das Antwortverhalten ist definiert, nicht notwendigerweise 
sichergestellt. Aber man weiss nicht ob nach Prozess A der Prozess B 
dran kommt. Das RTOS macht selber was, aufgrund von Regeln, sprich 
Prioritaeten. Je nachdem ob man Preemptives Multitasking oder 
Kooperatives Multitasking hat.

[Stefan E. (sternst)]

> Ja, das Antwortverhalten ist definiert, nicht notwendigerweise
> sichergestellt.

Kann es sein, dass du da irgendetwas verwechselst? Es ist doch gerade 
die entscheidende Eigenschaft eines RTOS, dass das Zeitverhalten in den 
gegebenen Grenzen sichergestellt ist. Wenn es nicht sichergestellt ist, 
dann ist es auch kein RTOS.

[Tim R. (octoate)]

Stefan Ernst wrote:
>> Ja, das Antwortverhalten ist definiert, nicht notwendigerweise
>> sichergestellt.
> Kann es sein, dass du da irgendetwas verwechselst? Es ist doch gerade
> die entscheidende Eigenschaft eines RTOS, dass das Zeitverhalten in den
> gegebenen Grenzen sichergestellt ist. Wenn es nicht sichergestellt ist,
> dann ist es auch kein RTOS.
Das kommt drauf an welche Art von RTOS du hast. Bei einem Hard-RTOS ist 
das Antwortverhalten zeitkritisch und muss sichergestellt sein (bspw. 
Airbag - wenn der zu spaet aufgeht bringts nichts mehr). Bei einem 
Soft-RTOS kann eine Deadline auch mal ueberschritten werden, was aber 
keine grossen Konsequenzen nach sich zieht (bspw. Encodieren eines 
Videos, wird man nicht rechtzeitig mit dem Encodieren fertig, wird das 
Bild einfach verworfen).