REAL TIME: Timer-INT öfter als 18.2 * pro Sekunde aufrufen

Wäre das nicht der klassische Einsatz eines µC? Dem überträgst du per
COM lediglich die Aktion, z. B. Drehrichtung rechts, Schrittanzahl
1000. Das ganze Timing erledigt der Controller, genauso wie die Start-
und Bremsrampen. Ich glaube nicht, daß Windows 98 echtzeitfähig ist.
Michael

Nur am Rande: Die ernstgemeinten Windows-Versionen arbeiten
standardmäßig mit Timerauflösungen von 15 bzw. 10 msec. Mit einem
einfachen API-Aufruf kann die Timerauflösung auf 1 msec Genauigkeit
erhöht werden ...

Aber dann muss man - igittigitt - Hardware über Devicetreiber anfassen
und das gehört sich ja nicht.

Hi,

nur um das Timing-Problem nochmal zu konkretisieren:

der Motor läuft zur Zeit unter DOS mit Uralt-Hardware und QBASIC(!!)
mit bis zu 4 Umdrehungen pro Sekunde (240 U/min) schrittfehlerfrei, dh.
es werden 4 * 400 = 1600 exakt getimte Schaltvorgänge pro Sekunde am
Parallelport erforderlich - die Timing-Auflösung muß daher deutlich
unter 1 ms liegen.

µC ist momentan (noch) keine Lösung, da dadurch weitere Kosten
entstehen - eigentlich sind in einem PC auch schon genug µC drin... wie
z.B. der Timerbaustein - die Frage ist halt, wie man das System
"umgeht" und sozusagen ein kleines ASM-Programm von ein paar Bytes zu
fest definierten Zeitintervallen (="hard real time") unabhängig von
Windows-Prozeßen aufrufen kann... die Abarbeitung ist dann so schnell
daß es niemanden (auch keine anderen DAQ-Programme) stört. Evlt. den
Windows-Timer-API hooken? Ich möchte halt so low-level wie möglich
gehen ohne viel Overhead...

Habe schon gelesen daß manche es über eine 16bit DLL versuchen um so
aus der Protected-Mode-Falle (in der keine direkten Portzugriffe
möglich sind) herauszukommen...

Tipps?

Hi

eben das will ja Windows und jedes andere ordentlich (nicht RT)
Multiprozessing-OS verhindern.
Du sollst nicht auf die Hardware zugreifen sondern immer über
API-Funktionen des OS gehen. Und da kann dir der Scheduler halt
dazwischenhauen wie er grade will und dir auch mal für 100ms den
Prozessor entziehen.

DOS ist kein Multiprozessing-OS. Da gehört dir der Prozessor ganz
alleine bis du ihn wieder abgiebst.

Wenn das für dich nicht aktzektabel ist mußt du auf etwas setzen was
echte Echtzeit kann. Also z.B. die von Michael vorgeschlagene Lösung
mit seperatem µC der nur noch Kommandos empfängt.

Matthias

Hm, ok.

Wie ist das mit "Sleep"? Anscheinend kann man die Granularität der
Zeitscheibe bis auf 1 ms herabsetzen... das ist zwar nicht das was ich
eigentlich wollte (ich wollte das System veranlassen, nach einer fixen
Zeit mein Programm aufzurufen) aber vielleicht tut das auch, wenn man
in der Zwischenzeit die Zeit pollt.

Ich brauche die < 1ms Auflösung nur für den Fall, daß der Motor schnell
vor- bzw. zurückfahren muß (so wie fast forward / rewind beim Tapedeck),
dies ist die Ausnahmesituation, während der notfalls der Rechner auch
100% der Rechenzeit mit meinem Task verbringen darf. Die meiste Zeit
sind die Anforderungen einiges geringer.

Dann gibts da noch die directX-timer, zum Teil werden die zur Kontrolle
der Framerate eingesetzt... mal schauen.

Grüße,
Dierk

Nein, wenn irgendwelches Hardwaregefummel mit Timerauflösungen < 1 msec
erforderlich ist, dann sollte das in einem Devicetreiber geschehen.
Alternativ könnte eine der verschiedenen verfügbaren
"Realtime"-Erweiterungen verwendet werden - Windows ist schließlich
kein Echtzeitbetriebssystem.

@ Dirk U,
schau dir mal bei www.ros.de die Karte Stepper 8 an. Wenn du mit den
Leistungen hinkommst, melde dich bei mir. Von den Karten haben wir noch
einige hundert (aus einer Konkursmasse). Die Programmierung erfolgt dann
über die serielle Schnittstelle vom PC. Und dann bist du die
Timingprobleme los.
Michael