Hallo ihr,

ich habe ein Problem und hoffe das ihr mir helfen könnt...

Ich lese mit einem TCP-Clienten von einem Server Daten aus und lasse die mir auf meinem Desktop-PC anzeigen, diese werden dann über die Serielle Schnittstelle über TxD über eine kleine Platine (nur zum Aufteilen der Daten) an Laptops geschickt.
Auf den Laptops habe ich Programme drauf, die diese Daten (bis jetzt nur 5 Bytes und ein Syncronisierungsbyte, später ca. 15 - 20 Bytes) einlesen und auswerten sollen.
Es sind drei Laptops an der Zahl, zwei mit 133Mhz (Toshiba Sattelite), 64MB-Ram und einer mit 266Mhz, 32MB-Ram (IBM-Thinkpad).
Auf allen dreien hab ich Win98 installiert.
Das Sendeprogramm auf meinem PC sendet ca. alle 200ms die Daten raus, die Laptops lesen alle 200ms die Daten ein (werden ja zwischengespeichert).
Nun ist es so, das auf meinem IBM-Thinkpad mit 650Mhz mein Prog die Daten passend ausließt und mir anzeigt (über die Port.dll), auf den anderen Laptops jedoch laufen die Daten so verzögert ein, das ich so damit nicht arbeiten kann...
Wo liegt jetzt das Problem?
Ich lese die Daten mittels des normalen Delphi-Timers aus, das dieser nicht genau läuft ist mir klar, könnte dieser so verzögert laufen, das das Prog deswegen so hängt?
Oder ist das auslesen mit ca. 200ms bei solch "langsamen" Laptops nicht möglich, oder vieleicht nur bei direktem auslesen?
Wie ihr seht, ich könnt mir mehrere Sachen vorstellen.
Senden und Empfangen wird im Prog übrigens mit 115200Baud.

Eine kleine Frage hänge ich auch mal noch dran, auch wenns manchmal nicht so erwünscht ist :
Gibt es eine Möglichkeit mittels Port.dll oder einer anderen DLL den Dateneingang über RxD zu überwachen (sowas wie OnRead...) oder kann ich die nur mittels abgestimmter Zeiten abfragen?

Danke im Vorraus.

Nimm eine der vielen (auch kostenlose) verfügbaren Komponenten für die serielle Kommunikation. Es ist ein Wunder das mit einem Timer überhaupt was funktioniert.

Hallo Bernhard,

Mit dem Timer hab ich ja gesagt, hab ich auch schon oft genug gesehen/gelesen und ja auch selbst gemerkt. (auf meinem PC gings immer sehr gut, auf langsameren Rechnern eben auch schlechter...)
Nur so dem Problem aus dem Weg zu gehen ist auch nicht toll, woran es wirklich liegt weiß ich ja dadurch auch nicht, und was mit einer anderen Komponente besser ist, genauso wenig.
Vieleicht hast du schon Erfahrung mit der ein oder anderen?
Meinst du also, das sollte trotzdem problemlos auf den Laptops möglich sein?

Die rsapi.dll hab ich übrigens auch schon getestet, da war es das gleiche...

Gruß
Patrick

Edit: Und wie könnte ich eine Schleife (endlos) aufbauen, die mir dann alle 200ms das Event bzw. die Procedure auslöst, so das mein Prog sauber und stabil läuft (im Zusammenhang mit dem auslesen der COM)

ich weiß nicht, ob dir das was hilft, aber mit dem seriellen port ist aus zeitlicher sicht immer der puffer ein problem. es kann gut sein das fertige komponenten dies besser lösen als eine grundlegende dll.

außerdem geht es dir ja um das übertragen der daten, oder?

~HKK

Hallo HKK,

okay ich werds mal ausprobieren, bleibt weiterhin die Frage, kannst du/ihr mir eine Komponente empfehlen oder soll ich einfach mal querbeet testen?

Gruß
Patrick

ich persönlich kann dir jetzt leider keine konkrete empfehlung geben, da ich selber in delphi noch nichts für den seri port programmiert habe, aber auf www.torry.net solltest du schon fündig werden und auch ein bisschen ausprobieren.

vllt wissen die anderen noch was.

ach ja, durchsuch auch hier das forum mal nach serieller schnittstelle, com port, etc. vllt gibts da schon was geeignetes ^^

~HKK

Windows ist kein Echtzeitbetriebssystem! Sende ein Start-Zeichen und ein Stopp-Zeichen. Der Empfänger puffert die Daten und setzt sie wieder richtig zusammen.

Luckie hat folgendes geschrieben:

Windows ist kein Echtzeitbetriebssystem! Sende ein Start-Zeichen und ein Stopp-Zeichen. Der Empfänger puffert die Daten und setzt sie wieder richtig zusammen.

das habe ich mit den problemen beim puffern gemeint =D
btw, was sollte denn eine "echtzeitbetriebssystem" sein? da der prozessor(-kern) nur immer einen befehl nach anderen abarbeiten kann, MUSS es ja warteschlangen, und damit auch Puffer, geben

das problem hierbei ist nur, dass die ports nicht vom prozessor direkt angesprochen werden, sondern das wieder über weitere controller läuft, und die serielle schnittstelle dazu noch ein rel. langsames protokoll hat.

~HKK

Hallo Luckie,

das meinte ich mit den Timern auch, ist mir also bewusst, das Windows nix mit Echtzeit am Hut hat.
Es wird halt das abgearbeitet, was wichtiger ist, und ich glaube da stehen solche Sachen wie Timer ganz hinten, kann also schöne Abweichungen geben.
Wie gesagt, das habe ich selbst oft genug erlebt, aber zum testen und probieren nutz ich die dann schon mal.
Ich habe über torry.net mal eine komponete gedownloadet, das Testprogramm, welches dort mit bei ist, bringt die Daten auf den "langsamen" Laptops so wieder wie sie ankommen sollen.
Ich muss das nur noch in mein Programm übernehmen und berichte dann obs geklappt hat.
Ich danke schonmal für die Hilfe und die Erklärungen

Manchmal reichen kleine Denkanstöße um zu merken woran es liegen könnte, auf externe DLLs zugreifen dauert halt doch länger als intern alles abzuarbeiten...

Gruß
Patrick