Es gibt ja mehrere Stellen, wo es hängen kann.
Viele ComPort-Komponenten arbeiten in einem Thread, also Senden und Empfangen nicht dort wo du es wegsendest.
Hier kommt es natürlich drauf an, wie da die Synchronisierung arbeitet.
Hier sollte es zwar nicht passieren, aber z.B. bei einigen
TCP/
IP-Komponenten wird auch nochmal bissl gewartet, ob nochmal was kommt, um besser ein Großes anstatt vieler kleiner Pakete versenden zu können.
Und dann gibt es vermutlich auch nochmal im Treiber/Hardware ein paar Puffer und Verzögerungen,
allerdings würde ich so eine "große" Pause doch eher/erstmal in deiner Komponente suchen.
Test:
CreateFile/TFileStream/... auf 'COM2' (oder welcher es ist), da dann ein Write ausführen und schauen ob es immernoch so lange dauert.
Hier im Windows die Defaults für BAUD und Co. beachten/anpassen, sonst müsstest du nach dem Create noch mit
SetCommState das im Programm setzen.
Die alten APIs um
AssignFile nicht benutzen, denn dort ist ein Schreib-Lesepuffer integriert. (vor allem für TEXT)
Bei zeitkritischen Anwendungen und wo du selber schon in einem Thread arbeitest, da wäre vermutlich eine synchrone SerialPort-Komponente besser,
aber, wie gesagt, arbeiten fast alle Komponenten asynchron, damit wenn man sie im Haupthread benutzt, nicht das Programm hängen bleibt.
Zitat:
dürfte also nicht durch anderen Task behindert werden
In deinem Programm, aber andere Programme interessiert es nicht.
Bei Einer synchronen Komponente und alles im selben Thread, da könnte man ein
Sleep(0)
vorher einfügen.
Danach wird in einem neuen Slott begonnen und für die nächsten paar dutzend Millisekunden wird der Task nicht unterbrochen.