Ersatz für DOS-Int 15h Funkt. 83h (Timer)

[af0815]

Und das was mir heute am meisten abgeht, sind ja eigentlich die Krücken die wir damals als Ersatz für ereignisgesteuerte Programmierung verwendeten: Der direkte Zugriff auf Hardwareinterrupts (Auch weil ich sehr oft nicht weiß, daß es ja Ersatz dafür gibt).

Der Hauptersatz ist der Timer mit seinem Event.

[RSE]

Als ich angefangen habe, war DOS schon nicht mehr sooo aktuell, ich bin dann recht schnell auf Win gewechselt. Unter DOS hab ich nie Interrupts benutzt, sondern immer nur repeat until keypressed. Seit ich nun mit Win programmiere nutze ich den Timer trotzdem nur sehr selten. Er ist eigentlich nur dann vonnöten, wenn man pollen muss oder tatsächlich eine Uhrzeit (Tageszeit) abwarten muss. Das kommt doch aber sehr selten vor, weil es eigentlich für alles entsprechende Events gibt?

[AlterMann]

Nur um das ganze mit einem Feedback abzurunden:

Es ließ sich prächtig mit Appliation.OnIdle und TBlockSerial.WaitingDataEx lösen.
Die Kommunikation funktioniert um nichts schlechter als seinerzeit interruptgesteuert ...

[mschnell]

Es ließ sich prächtig mit Appliation.OnIdle und TBlockSerial.WaitingDataEx lösen.

Aber vermutlich braucht dein Programm jetzt 100% CPU-Leistung (schau 'mal in den Task-Manager), das es permanent den Port-Status aktiv pollt und nicht wie früher auf einen Interrupt wartet. Das ist in einem Multritasking System unzulässig, da es alle parallel laufenden Prozesse verlangsamt.

-Michael

[AlterMann]

Aber vermutlich braucht dein Programm jetzt 100% CPU-Leistung (schau 'mal in den Task-Manager)
-Michael

Ich kann das erst Montags überprüfen, das Programm hab ich in der Firma.
Ich denke aber nicht, daß das so problematisch ist. Die Procedure OnIdle wird ja nicht öfter aufgerufen als sonst auch, und es wird eigentlich nur bei jedem Aufruf geschaut ob ein Zeichen im Buffer der seriellen Schnittstelle wartet. Nur wenn das der Fall ist passiert ein bißchen mehr.

Aber ich schau mir das natürlich am Montag an.

[mse]

OnIdle wird nur einmal aufgerufen, wenn die event queue leer ist. Auf Linux, wo im Gegensatz zu Windows keine dauernden events gesendet werden, könnte dies zum Stillstand deines Programm führen, bis beispielsweise die Maus bewegt wird.

[mschnell]

Die Procedure OnIdle wird ja nicht öfter aufgerufen als sonst auch

Wann denn genau ? da sollte es eine Doku geben, sonst weiß man nicht was man da tut ....

-Michael

[theo]

OnIdle wird nur einmal aufgerufen, wenn die event queue leer ist. Auf Linux, wo im Gegensatz zu Windows keine dauernden events gesendet werden, könnte dies zum Stillstand deines Programm führen, bis beispielsweise die Maus bewegt wird.

Da hat mse leider recht. OnIdle ist auf Linux nicht für polling geeignet. Leider wird dieses Event auch in gewissen SimpleIPC Demos verwendet, welche dann auf Linux nicht richtig zu funzen scheinen. Abhilfe: TTimer.

[mschnell]

Abhilfe: TTimer.

Oder, wenn's mehr "realtime" sein soll: TThread.

-Michael

[AlterMann]

Wie oft OnIdle wirklich aufgerufen wird, kann ich nicht sagen, aber darauf habe ich ja keinen Einfluß genommen.
Auch wenn das dem Muliplattformgedanken hinter Lazarus so gar nicht entsprechen mag, es ist mir eigentlich nicht wichtig ob es auf Linux funktionieren würde, mit Linux hab ich nichts am Hut und ich glaube das wird sich auch nicht so bald ändern.

Das ganze -trotz momentaner Funktionstüchtigkeit- mit TThread zu verwirklichen hab ich ohnedies vor, da ich mich mit TThread vertraut machen möchte und diese Routinen in einer Unit eingebettet sind die ich für verschiedene Projekte brauchen werde.

Bei diesem (ersten) Programm ist mir die CPU-Auslastung nicht wichtig, da es immer nur kurz auf einem Notebook verwendet wird um ein Gerät vor Ort zu programmieren, da muß kein anderes Programm Rechenzeit bekommen, aber das ist natürlich ein Ausnahmefall.

[AlterMann]

Es ist natürlich so wie Michael vermutet, die Anwendung braucht 100% Systemleistung.

Nur:
Wieso ändert sich das wenn ich TThread verwende?
Das Polling findet dann eben in der Procedure execute statt und läuft unabhängig vom Hauptthread, aber wer hindert den Nebenthread daran, nun seinerseits 100% Rechenzeit zu verschlingen? Ich verstehe immer noch nicht wie das den Hardwareinterrupt ersetzen soll ...

[theo]

Es geht ja um OnIdle. Das kommt unter Windows offenbar zu oft.
Deshalb hättest du mit einem TTimer mehr Kontrolle. In einem separaten Thread könnte man im Main-Loop einfach sleepen z.B. sleep(100); //ms.

[mschnell]

In einem separaten Thread könnte man im Main-Loop einfach sleepen z.B. sleep(100); //ms.

Kann man. Ist dann aber immer noch polling (nicht so realtime, verbrät unnötige Rechenzeit). Besser ist es einfach (z.B. von einem CPM-Port) zu lesen, dann bleibt der Thread im Treiber stehen, und braucht überhaupt keine Rechenzeit. Wenn dann ein Zeichen ankommt wird der Thread sofort aktiviert. SAchnelle Reaktionen sollten direkt im Thread passieren (GUI geht da aber nicht) Mit TThread.Synchronzie kann man dann im Mainthread weitermachen, wenn es sinnvoll ist-

-Michael

[AlterMann]

Kann man. Ist dann aber immer noch polling ()nicht so realtime, verbrät unnötige Rechenzeit.
Genau das ist der Punkt, das hätte ich auch gemeint.

Besser ist es einfach (z.B. von einem CPM-Port) zu lesen,

Was ist das?

dann bleibt der Thread im Treiber stehen,

heißt das ich müßte selbst einen Gerätetreiber schreiben?

und braucht überhaupt keine Rechenzeit. Wenn dann ein Zeichen ankommt wird der Thread sofort aktiviert.

Das wäre ja haargenau wie meine Interrupt Service Routines, aber genau das geht ja anscheinend nicht



-Michaek

Bitte um weitere Aufklärung ...

[mschnell]

Sorry, Typo. Ich meinte als Beispiel einen COM-Port (Serielle Schnittstelle). Ein TCP/IP-Socket hat dieselbe Eigenschaft (nennt sich "blocking" /Byte Stream).

Den Treiber muss man nur dann selber schreiben, wenn man spezielle Hardware verwendet. Für serielle Schnittstellen und TCP/IP und diverse andere gibt es im System entsprechende Treiber.

Es ist ja dann auch ein Interrupt-Service. Allerdings im Treiber. Im Userland-Code ist das bei Linux und Windows nicht möglich.(OK, es gibt da Workarounds wie IOP (oder so ähnlich) für Linux und Kithara für Windows). da würde ich aber die Finger von lassen.

-Michael