Scheint soweit super einfach zu sein. 3 Zeilen und schon kann man senden.
Code: Alles auswählen
var ser: TBlockSerial;
procedure TForm1.FormCreate(Sender: TObject);
begin
ser:=TBlockSerial.Create;
ser.Connect('COM1');
ser.config(115200, 8, 'N', SB1, False, False);
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
ser.SendByte($AA); { so sendet man ein Byte }
end;
Nun experimentiere ich grade am Empfang.
Uart Interrupts gibt es ja nicht mehr. Also muss man irgendwie im Polling Modus
versuchen zu ermitteln wieviele Daten sich im Empfangspuffer befinden.
Darauf zu warten, dass n Daten im Puffer sind, ist nun garnicht mein Ding.
"Es gibt immer was zu tun"....
Um zu prüfen, wieviele Daten sich schon im Empfangspuffer befinden,
bedient sich, notwendigerweise, die Synaser Unit bei einem Windows System der Funktion
ClearCommError. Nein, das ist kein Schreibfehler es ist tatsächlich diese Funktion dafür zuständig
Dort wird in cbInQue die Anzahl Bytes im Empfangspuffer zurückgeliefert,
die noch nicht abgeholt wurden.
in Synaser nennt es sich dann: TBlockSerial.WaitingData
Man kann also jederzeit mit WaitingData abfragen wie der Stand der Dinge ist.
Leider nur für empfangene Daten.
Der EmpfangsPuffer steht standardmässig (Windows) auf 4096 Bytes,
diesen kann man bei Bedarf, bei Synaser mit der Eigenschaft "SizeRecvBuffer" einstellen.
okay und getestet.
Den Sendepuffer kann man jedoch nicht einstellen, hier liegt in der Unit Synaser.pas eine "tote" Variable FSendBuffer
und in der Windows Funktion SetupComm wird generell 0 übergeben.
aber das ist vorerst auch nicht mein Problem.
Ich hab mir jetzt einen Timer genommen, der all 10ms mal guckt, ob schon was da ist.
Klappt auch super.
Code: Alles auswählen
procedure TForm1.Timer1Timer(Sender: TObject);
begin
if Assigned(ser) then caption:=IntToStr(ser.WaitingData); { Ausgabe Anzahl Daten im Empfangspuffer }
end;
Mein angeschlossenens Gerät sendet kontinuierlich rund 10000 Bytes pro Sekunde mit 115200 Baud.
In Windeseile (nicht Windowseile, da hats keiner eilig ) ist der Puffer voll und die letzte Ausgabe steht dann bei 4096.
Alles Bestens.
Den Puffer vergrößert:
ser.SizeRecvBuffer:=20000;
geht auch recht schnell und der angezeigte Wert steht bei 20000
Neuer Versuch mit 500000 (is ne halbe Million)
geht auch.
Bisher habe ich nur auf COM1 gearbeitet, nun das gleiche Spiel mit COM14
Ich habe einen USB zu RS232 Converter dran und dieser hat sich eingetragen als COM14
Initilialisierern, senden, klappt auf Anhieb.
Hier war ich mir nicht so sicher, da Windows ab Com10 SEHR merkwürdie Namen einführt.
Das macht die Synaser Unit aber richtig...
Jetzt kommt der Empfang:
Puffer auf 4096 gestellt.
Daten kommen, aber der letzte angezeigte Wert der Füllung steht beo 4062
Erneuter Versuch, nun steht der Wert auf 4094
Nochmal neu starten, steht auf 4093
Nun auf 4035, 4037, 4092,4093.....
Buffer auf 10000 gestellt.
Daten empfangen 9989,
Neuer Start 9981, 9984, 9989...
Sehr eigenartig....
Der Puffer muss eigentlich immer vollaufen, da ich keine Bytes abhole.
Die Aktualisierungsrate (Anzeige der empfangenen Daten) des Zahlers hat sich anscheinend auch auf 0,5 Sekunden verlangsamt.
Das heisst, dass der Treiber von FTDI nicht oft genug aktualisiert und evtl. sogar den Puffer falsch bedient ????
Hat damit schon jemand Erfahrungen gesammelt, oder kann dieses Verhalten erklären, bestätigen ?
Sorry, viel Text, will nur zeigen, dass ich mich ernsthaft schon mit dem Thema beschäftigt habe
und auch mal in den Source Code von Synaser reingeschaut habe.
Siro