Realtime Operating Systems

Hallo zusammen,

das Informatik-Forum geht in den Archivmodus, genaue Informationen kann man der entsprechenden Ankündigung entnehmen. Als Dankeschön für die Treue bekommt man von uns einen Gutscheincode (informatikforum30) womit man bei netzliving.de 30% auf das erste Jahr sparen kann. (Genaue Infos sind ebenfalls in der Ankündigung)

Vielen Dank für die Treue und das Verständnis!

    Hallo Leute..
    Weisz nicht, ob ich hier richtig bin, aber wollte nur mal nachfragen, ob jemand Erfahrung mit Echtzeit-Betriebssystemen hat. Wenn ja, welche koennt ihr empfehlen? (wenn moeglich, OpenSource)

    Dank im Voraus..
    ciao..

    Probier mal Real Time LINUX, auch RTL. Dort kann man die Prioritaet der Prozesse definieren uns so das Verhalten ganau vorhersagen was beim normalen Linux nicht moeglich ist.
    Ausserdem glaube ich gibt es einen patch fuer linux um prozesse real time laufen zu lassen.
    Was moechtest du denn genau machen?

    RTLinux ist eine feine Sache, sofern man sich ein bisschen damit herumspielt und das ganze vernünftig zum Laufen bekommt.

    QNX ist auch ein RTOS und ist mittlerweile für den Privatgebrauch gratis verfügbar. Hab es allerdings nur kurz mal getestet. Lustig ist auch die eigene grafische Oberfläche und der ganze Heckmeck.

    wie ist eigentlich so ein rtos im alltagsgebrauch? kann man da normale anwendungen laufen lassen, und welche unterschiede machen sich da bemerkbar? die gängige vorstellung, dass einfach alles gleich passiert, wird ja nur schwer zutreffen, oder? :)

    lg michi

    Zitat von C++Redeemer

    würd mich auch interessieren was das genau sein soll. klingt irrgendwie nach nuklearAngriffsSimulationsSystem oder sowas... (oder halt des mit die erdbeben oder dem wetter)

    =)

    naja normalerweise verwendet man so etwas in ubahnen, steuerungssystemen etc, wo man definitiv wissen muss, wie lange eine aktion dauert (zumindest ist das mein wissensstand). aber dass jemand so was auf seinem pc installiert hör ich zum 1. mal.

    lg michi

    Zitat von C++Redeemer

    ah die antwort kam aber schnell =)


    na reicht es bei sowas nicht, in einem normalen OS einen prozess auf maximum priorität laufen zu lassen?!

    Fast is not real-time!, wies so schön heißt.

    Es geht bei Echtzeitanwendungen immer darum, dass der worst case sich in Grenzen hält. Ethernet ist z.B. nicht geeignet für Echtzeitkommunikation, weil es zwar _meistens_ schnell ist, der worst case aber ziemlich böse ist. Bei einem RTOS müssen dementsprechend Antwortzeiten garantiert werden, was "normale" OSs nicht machen. Dazu kommen aber auch noch Synchronisations- und Schedulingprobleme. Wen es noch genauer interessiert, dem sei die VO Echtzeitsysteme am vmars empfohlen.

    Danke erstmal fuer die Replies, werde mir mal die Beiden OS's anschauen.

    Zitat von Jeff_Mills

    Was moechtest du denn genau machen?

    Im Moment versuche ich mich nur mal ins Gebiet einzulesen/einzuarbeiten. Als laengeres Projekt hab ich ein eigenes RTOS fuer den Realtime-Planning Bereich fuer UAVs (Unmanned Air Vehicles) im Sinn.. Mal schau'n ob ich auf dem Richtigen weg bin..

    Danke nochmals..
    ciao..

    Zitat


    Es geht bei Echtzeitanwendungen immer darum, dass der worst case sich in Grenzen hält.

    Das würd ich so nicht sagen.
    Ok, das ist nicht unwichtig bzw nice to have, aber noch wichtiger ist die *Berechenbarkeit* des worst case.
    Also *beweisbare* garantierte Antwortzeiten.
    Zumindest bei Hard-Realtime-Systems.
    Ein HRS mit <=12 micro-secs Antwortzeit in 99.99999999%
    ist unbrauchbar, eines mit *garantierten* 120 micro-secs sehrwohl, soferne das für die Applikation noch akzetabel ist.

    Schon alleine das werben von RTLinux mit
    * Hard real-time networking over Ethernet or FireWire (1394) ...
    ist nicht sehr vertraunserweckend.
    Ethernet und HRT ? wtf ?

    Egal, will ned weiter klugschei**, hab' das Zeug eh schon lange vergessen und verdrängt :>

    Bei einer ernsthaften Beschäftigung mit dem Thema würd' ich auch die Kopetz-VO empfehlen.

    Mfg, LB

    Zitat von Lord Binary

    Das würd ich so nicht sagen.
    Ok, das ist nicht unwichtig bzw nice to have, aber noch wichtiger ist die *Berechenbarkeit* des worst case.
    Also *beweisbare* garantierte Antwortzeiten.
    Zumindest bei Hard-Realtime-Systems.
    Ein HRS mit <=12 micro-secs Antwortzeit in 99.99999999%
    ist unbrauchbar, eines mit *garantierten* 120 micro-secs sehrwohl, soferne das für die Applikation noch akzetabel ist.


    Nun ja, der Sinn eines worst case ist ja, in 100% der Fälle zuzutreffen ;) Statt "in Grenzen halten" wäre aber wohl "garantiert beschränkt sein" der bessere Ausdruck gewesen.

    Also für Ethernet gibts einen abgewandelten Standard, der auch RT-kompatibel ist. Hab schon wieder vergessen wie der heißt. Irgendsowas war da aber. Sowas wie Etherbus, kann das sein? Also eher Bus-System, aber halt Ethernet-mäßig.

    Was RTLinux betrifft, wird da quasi ein kleiner RT-Kernel vor den Linux-Kernel eingeschoben. Dann kann ich einige Anwendungen dem RT-Kernel anvertrauen, die laufen dann in RT, und der Rest läuft normal in "Plain-Linux"