schon jemand gemacht?
Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Echtzeitprogrammierung unter Windows
Hab folgendes Problem:
Ich soll ein Programm schreiben, dass zu genau definierten Zeiten, ein Signal ueber den Druckerport ausgeben soll. Das ganze muss millisekundengenau funktionieren und darf nicht durch Scheduler oder Swapping zu spaet kommen. Nun find ich leider kein Framework, wo man derartige Dinge machen kann zumindest nicht fuer ein Standardwindows (kann auch einschraenkung auf NT oder XP sein, sollte aber ‘zukunftsfaehig’ sein).
Hat schon jemand sowas gemacht und kann mir einen Tipp geben, nach was ich suchen sollte?
Ich habe mal ein ähliches Projekt gehabt. Ich habe damals allerdings festgestellt, dass Abtastungen unter 50ms nicht machbar sind (weder unter Win (98/2000/NT4) noch unter Linux). Ich habe mich dann für eine Hardwareseitige Lösung entschieden, die die Signalsteuerung übernimmt und nur bei fast vollem Puffer mit Windows “reden” muss.
Wenn deine Software aber dieses Signal nicht ständig abgibt, gibt es für manche Timer-Bausteine DDKs (Driver DevKit), mit denen man den Zeitgeber Baustein zu bestimmten Zeiten einen Interupt auslösen lassen kann. Dafür mußt Du aber einen Windowstreiber für dein Motherboard (!) anpassen und hängst noch von der Genauigkeit deines Zeitgebers ab.
Das kann doch net sein, ein Treiber muss ja auch manchmal recht genaue Antwortzeiten einhalten. Windows hat auch recht viel Echtzeitprioritaeten uns so Zeugs, da muss es schon an Weg geben denk ich, nur find ich kei Beschreibung wie man das anwendet. Eine externe Hardwareloesung mit nem Controller, der dann halt per usb oder so angesprochen wuerde und immer im vorraus programmiert, waer vermutlich die beste Loesung. Das wuerde aber den Rahmen spraengen, dann bleibt das alte Dosprogram, damit gehts naemlich prima, nur muss halt extra ein Uraltrechner rumstehen.
Echt? Wann?
Ist das nicht gerade der Unterschied zwischen “echtzeit”- und “normalen” Betriebssystemen?
Was du noch versuchen könntest (falls du es nicht schon getan hast), ist die Thread-priorität hochschrauben, ich glaube da gibt es auch eine pseudo-real-time-stufe.
Oder du probierst mal real-time-linux aus. Das hab ich zwar auch noch nicht ausprobiert, aber dem Namen nach sollte das ja sowas können (Antipythagoras, hast du das mit “normalem” oder RTL ausprobiert?).
Vielleicht kann man das mit dem seriellen Port machen: Du stellst alle Start- und Stop-Bits aus, dann müsstest du ja nur mit den gesendeten Daten die Signalform am Ausgangspin direkt beeinflussen können (also: 100 Nullen senden, dann einmal 255, usw.). Wenn du dann noch die Baud-Rate auf einen geeigneten Wert einstellst, und den Sende-Puffer mit entsprechenden Daten füllst, erledigt der I/O-Baustein im Seriellen Port den Rest (und zwar in Hardware, ähnlich wie der von Antipythagoras vorgeschlagenen externe Timer-Baustein).
Vielleicht kann man sowas auch direkt am Parallelen Port machen.
Also eine Genauigkeit von 1ms ist doch kein Problem.
Nimm einen Parallelport-treiber (sowas wie das: http://www.beyondlogic.org/porttalk/porttalk.htm), und probiers aus. Bei Bedarf die Threadpriorität bei Zugriffen auf Realtime stellen.
Und zum Timen bzw Berechnen der Länge von Delay-Loops die QueryPerformanceCounter Funktion benutzen, dann sollte das gehen.
habe damals auf normalem Linux probiert. Mit RTLx habe ich noch keine Erfahrung. Das mit dem Seriellen Port ist eine nette Idee, scheitert aber an der RS232 Spezifikation, die Schwankungen um 8% zulässt (schießt dir deine Genauigkeit zum Mars), was die Mainboardhersteller schamlos ausnutzen (klage aus eigener Erfahrung). Außerdem müsste man garantieren können, dass der Puffer nie leerläuft.
Ich denke der Kniff von Cody (“Realtime”-Priority) eignet sich, falls du keine anderen Programme, wie z.B. Grafikkartentreiber, Solitär o.ä. laufen hast.