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

[AlterMann]

Hallo

Unter DOS hab ich gerne den Int 15h - Unterfunktion 83h verwendet. Dem konnte man eine Zeit vorgeben und die Adresse einer beliebigen byte-Variable im Speicher. Dann rief man ihn auf und bekam sofort wieder die Kontrolle zurück. Nach Ablauf der Zeit wurde die Variable gesetzt und man konnte sie abfragen.

Das sah ungefähr so aus:

Code: Alles auswählen

procedure tserial.starttimer;
 
  var ober,unter : word;
      offs,segment : word;
 
 begin
  flag := 0;
  offs := ofs(flag);
  segment := seg(flag);
  case s of
   2 : begin
        ober := $001E;
        unter := $8480;
       end;
  end;{case}
  asm
   mov ah,$83
   mov al,0
   mov es,segment
   mov bx,offs
   mov cx,ober
   mov dx,unter
   int $15
  end;
 end;

Verwendet hab ich ihn beispielsweise so:

Code: Alles auswählen

function tserial.transfer;
 
  var st : string;
      a : byte;
      c : char;
 begin
  st := s + prfs(s);
  transfer := false;
  send_string(com,dc2,dly);
  dwrite('<DC2>');
  starttimer(2);
  repeat until (zeichenempf = dc4) or (flag <> 0);
  if flag <> 0 then exit;
  st := stx + st + etx;
  dwrite('[DC4]'+st);
  send_string(com,st,dly);
  starttimer(2);
  repeat until (buffercheck(com)) or (flag <> 0);
  if buffercheck(com) then check_buffer(com,c);
  if c = ack then
   begin
   dwrite('[Ack]');
   transfer := true
   end
   else
   begin
   dwrite('[NAK]');
   transfer := false;
   end;
 end;

Natürlich gibt es das unter XP u. Konsorten nimmer.
Gibt es da vergleichbares? (Sei es in der Riesen-RTL von Lazarus oder bei den Win-API-Funktionen)
Wie würdet ihr das lösen?

Der direkte Zugriff auf Ports, Speicher und InterruptserviceRoutinen feeeeeeehlt mir sooooo

Danke für die Aufmerksamkeit
Christian

[theo]

Wie würdet ihr das lösen?

Was denn eigentlich?
Könntest ohne DOS erklären, was du brauchst oder zu brauchen glaubst?

[AlterMann]

... oder zu brauchen glaubst?

Hihi! Das trifft es wohl am besten.

Eigentlich geht's um dieses Stück:

Code: Alles auswählen

send_string(com,dc2,dly);
  starttimer(2);
  repeat until (zeichenempf = dc4) or (flag <> 0);

Ich sende ein bestimmtes Zeichen über die serielle Schnittstelle und warte auf ein anderes als Antwort.
Kommt dieses nicht innert einer bestimmten Zeit (Gegenstelle nicht anwesend, etc. ..) so beende ich das Warten ...

[AlterMann]

Alles zurück! Wie's scheint macht die Methode RecvBufferEx von Synaser ohnedies alles was ich möchte von Hause aus.

[Hitman]

... und dann gibts da auch noch Threads und Timer

[AlterMann]

... und dann gibts da auch noch Threads und Timer

Bin soeben dabei mich mit TThread zu beschäftigen. Ist wohl die einzige (Beste?) Möglichkeit auf (unvorhersehbar auftretende) Zeichen die an der seriellen Schnittstelle ankommen, zu reagieren.
Bei TurboVision gab es eine procedure namens idle. Die wurde immer aufgerufen wenn die Application nichts anderes zu tun hatte. Sowas gibt es wohl auch nicht mehr?

[theo]

Application.OnIdle gibt's schon, das hilft dir aber nicht, wenn du auf blockierende Funktionen wartest (blocking sockets etc.), dann ist die Anwendung nämlich nicht Idle sondern eben blockiert.
Das kann man mit Threads lösen, um Funktionen auf die man warten muss vom GUI abzutrennen und diese ggf. auch abschiessen zu können.

[AlterMann]

Das ist mir schon klar.
Das war auch nur z.B. darauf bezogen, daß ich in der OnIdle-Routine ja nachsehen könnte ob was an der Schnittstelle angekommen ist.
Ich werde das aber wohl doch mit TThread lösen, allein schon des Kennenlernens dieser Funktion wegen.

BTW: Ist das Neuzeichnen der Elemente einer Form blockiert, während eine OnClick-Methode eines Buttons ausgeführt wird?
Selbst wenn ich zwischendurch z.B. Label6.Show ausführe ändern sich Farbe u. Caption erst wenn die OnClick-Routine abgearbeitet ist.

Code: Alles auswählen

procedure TForm1.BitBtn1Click(Sender: TObject);
 
 var PortNr : string;
 
begin
  if AccPort.Connected then AccPort.Close(Label5) else
   begin
    PortNr := ComboBox1.Text;
    AccPort.Open(PortNr,9600,7,'N',SB1,Label5);
    Label5.Show;
    AccPort.TestAccConn(Label6);
   end;
end;

In AccPort.Open wird Textfarbe und Caption von Label5 geändert.
AccPort.TestAccConn braucht dann einige Sekunden wenn keine Gegenstelle antwortet.
Erst dann ändert sich das Label ...

[theo]

Ja, du kannst Application.Processmessages aufrufen, wenn du das sofort updaten willst.

[Hitman]

Show ist da übrigens glaube nicht das, was du willst. Du willst wohl eher .Repaint. Allerdings brauchst du trotzdem das ProcessMessages (Neuzeichnen ist nämlich nur eine "Anfrage", kein direkter Befehl).

[AlterMann]

Das war's. Danke!

[RSE]

Zusammenfassend ist zu sagen: In Dos-Zeiten hattest du die Kontrolle über die volle Prozessorzeit, in Win hast du sie nur noch während der Abarbeitung von Events (z.B. wenn der User eine Aktion ausführt, wenn Timer ablaufen, wenn sich die Peripherie meldet). Ein Idle-Befehl ist daher einfach nicht mehr nötig. Stattdessen beendest du einfach deine Prozedur und reagierst auf das, auf das du wartest (Timerevent, Systemevent etc.) mit dem entsprechenden Event-Handler. Gibt es mal tatsächlich keinen entsprechenden Event (kommt selten vor), dann wartest du in einer Schleife, die Application.ProcessMessages; beinhaltet. Das ist aber nur noch als Notlösung anzusehen.

[af0815]

Das Hauptproblem ist der 'gedankliche' Übergang vom Spaghetticode zum event-gesteuerten Code.

Man agiert nicht mehr sondern reagiert.

Das hat mir am Anfang auch einiges an 'Umdenke' gekostet, mittlerweile gehts - lol

[RSE]

schön gesagt, muss ich mir merken

[AlterMann]

Was ihr schreibt ist zwar richtig, aber das Problem habe ich (zum größten Teil) schon hinter mich gebracht.
Als ich zuletzt in BP7 Programme geschrieben hab, war das durchaus vollständig OOP (und ehrlich gesagt das ist mir leichter gefallen, als ein paar Jahre davor der Umstieg von BASIC auf Pascal )
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).
Aber mit jeder Zeile Code gefällt mir das Programmieren mit Lazarus besser, und es kommt mir auch vor, daß es etwas schneller geht, weil man sich auf's Wesentliche konzentrieren kann.