Erstmal ist es doch egal, wenn ein Thread wartet. Das einzig 'Häßliche' ist die CPÜ-Anzeige des Taskmanagers.
Du hast hier das Problem, das ein ereignisgesteuertes System (hier: Windows) auf streng sequentiell abzuarbeitende Jobs (RS232 Abfragen) stößt. Wenn man es gänzlich ohne Wartezeit macht (aber was spricht hier dagegen?), dann müsste man eine ereignisgesteuerte RS-232 Komponente nehmen, und einen DEA (Deterministischen Endlichen Automaten) basteln, aber das ist zu kompliziert für deinen Fall.
Ich weiss nicht, wie Du mit dem Ladegerät kommunizierst, aber ich habe so ein Tool, mit geht das sehr einfach, so etwa:
Delphi-Quellcode:
...
MyRs232.OpenCom ('
Com1',8600,NoParity,8,1);
MyRs232.WriteString (#027+'
AB');
// Ersten Befehl senden
sAnswer := MyRs232.ReadString;
// Antwort auf den 1.Befehl
If sAnswer<>'
READY'
Then
Raise Exception.Create('
Gerät nicht bereit';
MyRs232.WriteString (#027+'
XY');
sAnswer := MyRs232.ReadString;
If sAnswer<>'
OK'
Then
Raise Exception.Create('
Gerät hat nicht mit OK geantwortet';
...
So wie man es aus alten DOS-Tagen kennt.
Jedes WriteString und ReadString wartet eben, bis die Funktion ausgeführt wurde. Das kann man auch ereignisgesteuert machen, aber eher lagere ich das in einen Thread aus und rufe die Sequenz nur eben alle 1000ms auf. Wieso willst Du auch nonstop wissen, wie es dem Ladegerät geht?
Was Du machst, nennt man 'Polling', also aktives Abfragen eines Zustandes. Da ist es doch logisch, das die Anwendung CPU-eit verbrät.