OT: Freies PC-RTOS?

"MaWin" schrieb:

Ok, ich meine Zustandsänderung. Ereignis ist vielleicht nicht der richtige Ausdruck.

Es läuft darauf hinaus, dass ein Pegel von Low auf High (oder andersrum) kippt. Also dachte ich mir, einfach den ParPort regelmäßig einlesen.

Das ich unter Win2k keine Reaktionszeit garantieren kann ist klar.

Mir ging es eher darum Ausagen wie "in 99,8% der Fälle 50ms oder besser", (ggf. mit Worst-Case) aufstellen zu können.

Viele Grüße, Bernd

"Bernd Maier" schrieb im Newsbeitrag news: snipped-for-privacy@uni-berlin.de...

Oje, also ein Anwenderprogramm.

Na, der Worst case lautet: 'Nie', soviel ist schon mal klar.

Der normale Wert haengt schlicht und einfach davon ab, welche Programm parallel laufen und was zu tun haben, denn ein Programm alleine obliegt ja dir und du kannst es so schreiben, das die Schleife maximal schnell wird, also bloss ein paar Instruktionen dauert.

Aber was die anderen Programme machen werden..... ....besonders huebsch sind die, die zeitgesteuert sind (Indexdienst, Defragmentation, Windows-Update) oder von aussen beeinflusst werden (was macht die Firewall wenn ein DoS-Angriff kommt).

Bernd Maier schrieb:

Meine Erfahrungen dazu sind ernüchternd. Ich habe mal ein System basteln müssen, bei dem 2xMS-Windows2000 und 2xLinux exakt dasselbe Ergebnis in einem 100ms-Zeitraster produzieren sollten. Das war schon sehr schwierig, und die MS-Windows-Kisten waren immer hintendran.

Du kannst ja unter WindowsNT und Nachfolgern (oder auch Linux) bestimmte Threads(/Prozesse) mit "Echtzeitpriorität" laufen lassen. Das klappt auch, nur ist dann das Betriebssystem lahmgelegt, solange dieser Thread nicht freiwillig die Kontrolle abgibt. Und wenn er das dann irgendwann einmal tut, sind aber erst mal *alle* anderen Prozesse dran, weil sie so lange warten mussten.

Der Worst-Case ergibt sich also dadurch, welche anderen Prozesse noch auf deinem System laufen, und was diese tun. Insbesondere solltest du die Zahl der Systemdienste soweit wie möglich reduzieren. Das geht so weit, auch die grafische Oberfläche von MS-Windows nicht mehr zu starten (möglich). Damit fällt zumindest schon mal die Bevorzugung der interaktiven Tasks weg, die es unter MS-Windows ja immer noch gibt.

Solltest du das Zielsystem nicht genau bestimmen können, sind keine Aussagen möglich.

Bernd Maier schrub im Jahre 07.11.2004 17:36:

Sehr empfehlenswet ist

-- B.Eckstein, snipped-for-privacy@ivu.de Cheap, Fast, Good - pick any two of them Die FAQ zu de.comp.hardware.netzwerke:

"Auch wenn ich die Funktionsweise dieser Konsole nicht kenne, glaube ich nicht, dass sie rauchen sollte"

Bernd Maier schrieb:

Ich habe vor einigen Jahren mal mit RTLinux

Ein anderes Projekt, das das gleiche verwirklicht ist

Das "durchschnittlich" erfolgt recht flott. Wenn du aber Real-Time-Fähigkeiten wünscht (also eine obere Schranke für das worst-case-Verhalten), darfst Du wohl Reaktionszeiten im Zehntelsekundenbereich erwarten (falls z.B. Office geladen wird und die Maschine, während heftig Plattenzugriffe stattfinden, ins Swappen kommt...).

Gruß, Jürgen

HAllo Bernd!

Das ist alles quark. Toggel einen Pin am Parallelport und miß mit einem Digitaloskar die Flankenwechsel. So habe ich das gerade letzte Woche gemacht, um festzustellen, das RTX für nicht mehr als 5kHz taugt.

Gruß Thorsten

Am Mon, 08 Nov 2004 08:41:54 +0100, meinte Thorsten Ostermann :

Sorry, verstehe ich nicht. Was heißt dies im Klartext?

Beste Grüße

Dr. Michael König

Hallo Michael!

Das es keinen Sinn macht, die Reaktionszeit einer Windows-Anwendung mit einem Echtzeitbetriebssystem zu Messen. Wenn er in dem Moment, wo seine Software reagiert, einen Ausgang am Parallelport umschaltet (was er ja sowieso vor hat), kann er die Reaktionszeit auch gleich mit einem Oszilloskop messen. Und zwar ohne die Reaktionszeit eines RTOS dazwischen, das man erstmal installieren und verstehen muß.

Gruß Thorsten