Synaser RS232 und FTDI COM14

Rund um die LCL und andere Komponenten

Synaser RS232 und FTDI COM14

Beitragvon siro » 9. Feb 2017, 15:46 Synaser RS232 und FTDI COM14

Ich arbeite mich grade in die serielle Schnittstelle unter Windows mittels Synaser ein.

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 :shock:
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 :cry: 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 :mrgreen: ) 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 :shock:

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
Grüße von Siro
"C" verCehnfacht die Entwicklungszeit...
siro
 
Beiträge: 162
Registriert: 23. Aug 2016, 13:25
Wohnort: Berlin
OS, Lazarus, FPC: Windows 7 Windows 8.1 Windows 10 | 
CPU-Target: 64Bit
Nach oben

Beitragvon kupferstecher » 9. Feb 2017, 16:49 Re: Synaser RS232 und FTDI COM14

An COM1 hattest du den FTDI nicht dran, oder?

Was der Grund fuer das von dir beschriebene Verhalten, ist, weiss ich auch nicht, koennte mir aber folgende Erklaerung vorstellen: Da der FTDI ueber USB uebertraegt, werden keine einzelnen Byte gesendet, sondern immer Blockweise. Die Groesse der Bloecke wird auch damit zusammenhaengen, wie schnell neue Daten reinkommen. Wenn diese blockweise auftreffen, wird man aber nie genau die Maximalzahl des Puffers erreichen, sondern der Ueberlauf verusacht vermutlich ein Loeschen der alten Daten, evtl. ebenfalls blockweise.

Wie gesagt, ist nur eine Vermutung. Mir ist aber nicht so klar, warum die Internas fuer dich so wichtig sind.
Fuers Empfangen bietet sich ein eigener Thread an, wie in den Beispielen, anfallende Daten koennen so sofort (ohne GUI-Verzoegerung) verarbeitet werden und die GUI wird trotzdem nicht blockiert.
kupferstecher
 
Beiträge: 22
Registriert: 17. Nov 2016, 11:52

Beitragvon Mathias » 9. Feb 2017, 18:25 Re: Synaser RS232 und FTDI COM14

Die Aktualisierungsrate (Anzeige der empfangenen Daten) des Zahlers hat sich anscheinend auch auf 0,5 Sekunden verlangsamt.

Dies könnte daran liegen, da es zum Teil bei den Geräteeigenschaften bei den USB-UART, eine sehr grösse Verzögerung eingestellt ist.
Die müsste man dann auf 1ms runterstellen. Die Eigenschaft findet man unter USB-Erweitert oder ähnlich.

So nebenbei habe ich auch schon mit Endlos-Eingabe gebastelt, aber nie hat es etwas schlaues gegben.

Um was für ein RS232-Gerät handelt es sich ?
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 2666
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon siro » 9. Feb 2017, 18:55 Re: Synaser RS232 und FTDI COM14

Habt erstmal Dank für eure Rückmeldungen.
Das mit dem Blockweisen füllen des Puffers beim FTDI wäre eine Möglichkeit und erscheint mir sogar recht logisch.

Ich habe bisher leider kein einziges Beispiel gefunden, wo mal in minimalster Weise gezeigt wird,
wie der RS232 Empfang laufen soll, deshalb meine Versuch mit dem Timer.
Wo sind denn Beispiele zu finden ?
In dem geladenem Ziparchiv sind zwar viele Beispiele, aber nix mit RS232 Empfang.
Google schiebt mich von a nach b aber leider ohne den gewünschten Erfolg. :(

Die Hilfefiles verstehe ich überhaupt nicht. Ein Ordner voller html Dolumente ??? :P

Was mir also bleibt ist experimentieren und den Source Code zu analysieren und natürlich EUCH fragen :oops:
Man wird ja nicht dümmer dabei...

Mein Sender ist ein LPC1768 Controller bzw. ein medizinisches Gerät mit diesem Prozessor,
dort sende ich Messdaten aus um mir die Regelung anzuschauen und das Verhalten zu beurteilen.
Ich hab das bisher mit Delphi 6 gemacht und das läuft recht gut. Da habe ich die Komponente TSerial aus der ToolBox. Die lässt sich sehr einfach
handhaben, da gibt es zum Beispiel ein Ereignis OnRxChar, hier läuft der Empfang wohl in einem separaten Thread.

Was macht das Spass seine eigenen Interrupts zu programmieren....wenn doch diese "merkwürdigen" Betriebssysteme nicht wären :D
Grüße von Siro
"C" verCehnfacht die Entwicklungszeit...
siro
 
Beiträge: 162
Registriert: 23. Aug 2016, 13:25
Wohnort: Berlin
OS, Lazarus, FPC: Windows 7 Windows 8.1 Windows 10 | 
CPU-Target: 64Bit
Nach oben

Beitragvon Mathias » 9. Feb 2017, 20:01 Re: Synaser RS232 und FTDI COM14

Mein Sender ist ein LPC1768 Controller bzw. ein medizinisches Gerät mit diesem Prozessor,

Programmierst du diesen auch selbst, oder ist dort alles vorgegeben ?

Mein angeschlossenens Gerät sendet kontinuierlich rund 10000 Bytes pro Sekunde mit 115200 Baud.

Sind das Text oder Binär-Dateien ?


Vielleicht, hilf dir das Programm im Anhang weiter. Dies ist ein einfaches Terminal-Programm.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 2666
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Timm Thaler » 9. Feb 2017, 20:41 Re: Synaser RS232 und FTDI COM14

Ursprünglich war der Empfangs- und Sendebuffer der Hardwarebuffer des RS232-Chips. Das waren meist 16k oder 64k bei den "guten" Chips. Nun will ich nicht ausschließen, dass Windows auch einen größeren virtuellen Buffer zuläßt, in den es die Daten rüberkopiert, aber ich würde einfach mal sagen: Der Buffer Deines USB-Uart-Wandlers ist einfach bei 4000irgendwas Bytes begrenzt.

Wozu brauchst Du so einen großen Buffer? Selbst wenn Du nur alle 100msec die Daten abholst, sind das bei 115kBaud nur 1150 Bytes.
Timm Thaler
 
Beiträge: 186
Registriert: 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.6 FPC3.0.0, Raspbian Jessie Laz1.6 FPC3.0.0 | 
CPU-Target: Raspberry Pi 3
Nach oben

Beitragvon siro » 9. Feb 2017, 21:21 Re: Synaser RS232 und FTDI COM14

@Mathias,
Ja, ich programmiere den Microcontroller komplett selbst, (leider in "C")
angefangen von den Registern PLL Clock Uarts SPI .... bis zum Endgerät.
Ich benutze nichteinmal irgendwelche Header Dateien oder stdio oder ähnliches.
Weil es ein medizinisches Gerät ist, möchte ich jedes BIT nachvollziehen können
und keine fremde Software (sogenannte Soup/ Software of unknown provenance) benutzen.

Zu deinem Zip:
Das ist Spitze:, ja, das hilft mir wirklich weiter. Ich werd morgen gleich dran arbeiten..
Hab vielen Dank


@Tim:
Ich sende Binärdaten von meinem Gerät, bzw. immer eine feste Struktur jede Millisekunde.
Da sind vier 16 Bit Werte und ein Synczeichen, damit nix ausser Tritt gerät...
Entweder direkt ADU Werte oder auch berechnete Werte.

static struct
{
S16 a; /* 16 bit value */
S16 b; /* 16 bit value */
S16 c; /* 16 bit value */
S16 d; /* 16 bit value */
S16 sync; /* fixed value to synchronize every data block */
} send_data;

Sofern meine Windowsanwenung schnell genug ist, brauche ich natürlich keinen großen Puffer.
Ich möchte ja auch möglichst die Daten in Echtzeit in meinem Kurvenfenster sehen.
4 Kanäle zu je 1000 Messungen pro Sekunde.
Viel mehr geht schon nicht mit 115200 Baud.

Das sind aber nur Daten zum Testen während der Software Entwicklung, das wird vor der Auslieferung
abgeschaltet, da keine externen Schnittstellen vorhanden sind.
Grüße von Siro
"C" verCehnfacht die Entwicklungszeit...
siro
 
Beiträge: 162
Registriert: 23. Aug 2016, 13:25
Wohnort: Berlin
OS, Lazarus, FPC: Windows 7 Windows 8.1 Windows 10 | 
CPU-Target: 64Bit
Nach oben

Beitragvon kupferstecher » 9. Feb 2017, 21:58 Re: Synaser RS232 und FTDI COM14

siro hat geschrieben:Ich habe bisher leider kein einziges Beispiel gefunden, wo mal in minimalster Weise gezeigt wird,
wie der RS232 Empfang laufen soll, deshalb meine Versuch mit dem Timer.
Wo sind denn Beispiele zu finden ?

Du hast recht, das hatte ich falsch in Erinnerung.
Ich kann dir jetzt auch kein funktionierendes Minimalbeispiel liefern, aber die Schnittstelle und der Timer läuft ja bei dir schon, der folgende Ausschnitt sollte also reichen. Die Schleife ist dazu da, dass alle Daten gelesen werden, welche verfügbar sind und erst wenn ein Timeout kam, verlässt man den Timer-Aufruf.

Code: Alles auswählen
Procedure TSerielle.TimerCall(Sender:TObject);
begin
  while true do begin
    ByteValue:= ser.RecvByte(10);     //Kurzes Timeout, um nicht zu blockieren. Daten entweder schon da, oder eben nicht
    If ser.LastError = 0 Then Begin  //Empfang erfolgreich (Daten waren vorhanden) 
      //Daten verarbeiten...
    End Else If ser.LastError = 9997 Then Begin //TimeOut, es sind keine Daten angekommen
      BREAK;
    End Else Begin //Schnittstellenfehler, aber kein Timeout, z.B. Schnittstelle getrennt
      //Fehlerbehandlung
      //Disconnect
      BREAK;
    End;//If
  end;//while
 
end;


Mit Thread funktioniert es prinzipiell genau gleich, nur dass die Empfngsschleife eben im TThread.Execute abläuft. Der Timer wird ja im Gegensatz zum Thread vom GUI-Framework gerufen, kann also durch das GUI verzögert werden und auch selber die GUI blockieren. Dafür ist im Thread die Datenweiterverarbeitung schwieriger und oft geht es bei den empfangenen Daten ja auch nur um die Darstellung in der GUI, dann wäre der Timer ausreichend.

siro hat geschrieben:Die Hilfefiles verstehe ich überhaupt nicht. Ein Ordner voller html Dolumente ???

Bei index.htm ist die Startseite der Hilfe, aber am Besten nach TBlockSerial suchen (Dateiinhalte oder Internetsuche).
Oder direkt hier:
http://synapse.ararat.cz/doc/help/synas ... erial.html
Die Hilfeseite ist schon wichtig, du findest dort die verschiedenen Empfangs- und Sendearten (Byte, String, Buffer...)
kupferstecher
 
Beiträge: 22
Registriert: 17. Nov 2016, 11:52

Beitragvon siro » 9. Feb 2017, 22:20 Re: Synaser RS232 und FTDI COM14

Ich wuste doch, hier gibts input :D

Danke Dir auch Kupferstecher, ja das ist wohl die richtige Hilfedatei mit den Funktionen.

Ich werd auch lieber mit einem Timer arbeiten, auch wenn diese sehr ungenau sind, aber um Daten mal abzuholen mehr als ausreichend.
Ein Thread ist ja doch schon eine recht komplexe Angelegenheit, mit eigeneder Stackverwaltung...
Wobei man sich darum wohl nicht unbedingt kümmern muss in Lazarus. Vorteil vom Thread wäre, das ein anderer Kern,
sofern vorhanden, die Arbeit übernehmen könnte.
Wer das wie verteilt weis ich zwar nicht, aber so zeitintensiv sind die paar Daten ja nun auch nicht.

Im Timer wird anscheinend auch gern noch
Application.ProcessMessages; aufgerufen, hier wird quasi CPU Zeit wieder für die GUI spendiert,
wenn ich das richtig verstanden habe. Gibt hoffentlich keine Rekursion (reentranter code) :wink:
Grüße von Siro
"C" verCehnfacht die Entwicklungszeit...
siro
 
Beiträge: 162
Registriert: 23. Aug 2016, 13:25
Wohnort: Berlin
OS, Lazarus, FPC: Windows 7 Windows 8.1 Windows 10 | 
CPU-Target: 64Bit
Nach oben

Beitragvon Mathias » 9. Feb 2017, 22:36 Re: Synaser RS232 und FTDI COM14

Ursprünglich war der Empfangs- und Sendebuffer der Hardwarebuffer des RS232-Chips. Das waren meist 16k oder 64k bei den "guten" Chips.

Bist du sicher, das dies 16K oder 64K sind ?
Ich dachte, dies sei nur 16 uder 64Byte.
http://www.zeiner.at/informatik/c/serialport.html

Sofern meine Windowsanwenung schnell genug ist, brauche ich natürlich keinen großen Puffer.

Irgendwann stottert jeder PC.

Ich möchte ja auch möglichst die Daten in Echtzeit in meinem Kurvenfenster sehen.
4 Kanäle zu je 1000 Messungen pro Sekunde.


An so etwas ähnlichen bin ich auch gerade dran.
Nur bei mir arbeitet dafür ein Arduino due.
Auch habe ich nur 2 Kanäle.
Dabei puffere ich die Daten im AVR, bis sie vom PC abgeholt werden.
Momentan sind dies 2 Puffer, bei dem einen werden die Messdaten geschrieben, beim anderen dann zum PC übermittelt.
Mit diesem System, kann ich etwa max. 1 Sekunde überbrücken, wen der PC stottert.
Mein Ziel ist aber anstelle der 2 Pufffer, mit einem Ring-puffer zu arbeiten. Momentan ist dieser aber noch im Beta-Stadium.

Was ich nicht mache, ist AVR-seitig, einfach endlos Daten schicken. Der AVR sendet nur, wen er den Befehl dazu bekommt.
Dann sendet er die Buffergrösse und anschliessend die Daten. ähnlich wie bei einem TStream mir dynamischer Array.

Viel mehr geht schon nicht mit 115200 Baud.
Kommt dein AVR nicht auch höher, ein einfacher Arduino Nano kann schon bis 2'000'000 Baud.
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 2666
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Timm Thaler » 9. Feb 2017, 23:09 Re: Synaser RS232 und FTDI COM14

Ähm ja, die Uart-Encoder und Decoder hatten 8 oder 16 Byte, auf den besseren ISA-Karten gab es dann nochmal FIFO dazu. Das Problem waren die Interrupts, auf die das System sehr zeitnah reagieren musste, was mit Windows und Multitasking zunehmend schwieriger wurde, bis dann PCI kam.

Geh einfach mal davon aus, die Daten zeitnah abzuholen.

Im AVR habe ich auch einen Ringbuffer für das Datenhandling. Im PC schreibe ich die eingehenden Daten einfach in einen String (oder ein Bytearray, wenn Nullbytes dabeisein können), und wenn das Endezeichen kommt, werte ich den String aus. Wird der String zu lang ohne Steuerzeichen, oder kommen eine Zeitlang keine Zeichen, wird der String verworfen.
Timm Thaler
 
Beiträge: 186
Registriert: 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.6 FPC3.0.0, Raspbian Jessie Laz1.6 FPC3.0.0 | 
CPU-Target: Raspberry Pi 3
Nach oben

Beitragvon siro » 9. Feb 2017, 23:28 Re: Synaser RS232 und FTDI COM14

Puffer im Chip:
Das war früher mal der 8250, den hab ich sogar noch in Assembler auf dem PC-XT programmiert.
Dann kam der Nachfolger 16450 der hatte 16 Byte FiFo.

Das Timing zum Senden hab ich lieber auf dem externen Controller,
weil das stimmt hundertprozentig Quarzgenau. Wobei das aber nicht wirklich relevant wäre,
da meine Datenaufnahme vom ADU nur exakt sein muss.

Baudrate:
Ich habe mich bisher nicht daran gewagt mehr als 115200 Baud zu benutzen,
da meine ehemalige Komponente (oder auch das Motherboard) das nicht konnte.
Der Engpass war also eher mein Windows System.
Mit dem externen FTDI kam ich aber auch weitaus höher,
das funktioniert dann aber nicht auf einem "normalen" Comport,
sofern der überhaupt noch existert am Rechner...

Ich hab auf dem PC einen relativ grossen Puffer, da der ja mal gern anderweitig beschäftigt ist
und die Daten auflaufen können. Oft flippte das System aber trotzdem aus, weil Windows unaufgefordert ein
"Update" macht oder das Antivir Programm mal dazwischenfunkt.
Das geht soweit, dass selbst mein SWD (Seriell Wire Debugging) vom externen Microcontroller deswegen aussteigt.

Übrigens ist mein LPC1768 kein AVR sondern ein NXP Controller, das ist aber auch ein Cortex M3 Kern
wie dein Arduino. Angeknüpfte Peripherie ist halt etwas anders, wobei auch beide einen 12-Bit ADU haben.

Dann wollen wir mal versuchen, dass wir unsere Daten vom Controller gut rüberbringen zum PC.
Krijen wa schon hin..... :mrgreen:
Grüße von Siro
"C" verCehnfacht die Entwicklungszeit...
siro
 
Beiträge: 162
Registriert: 23. Aug 2016, 13:25
Wohnort: Berlin
OS, Lazarus, FPC: Windows 7 Windows 8.1 Windows 10 | 
CPU-Target: 64Bit
Nach oben

Beitragvon siro » 10. Feb 2017, 08:40 Re: Synaser RS232 und FTDI COM14

Guten Morgen,

ich bin grad etwas enttäuscht, ich habe mir mal das Senden angesehen, bzw. bissle Zeit dabei gemessen.
Die Sendefunktion blockiert die gesamte Anwendung. Kommt erst zurück, wenn alles ausgesendet wurde.

Ich hab das mal verglichen mit meiner TSerial Komponente von Delphi 6.
Hier kommt die Funktion SOFORT zurück. Das Senden geschieht im Hintergrund.

Jetzt müste ich ja für das Senden auch noch einen Thread bauen, irgendwie werd ich nicht so richtig glücklich mit der Synaser Unit.
Das ging alles schonmal besser und einfacher....

Die Timer laufen nicht richtig, die Schnittstellen laufen nicht richtig, Interrupts gehen nicht, wie soll man da noch vernünftige Software schreiben.
Was bin ich froh auf Embedded Systemen ohne Betriebssystem zu programmieren.

...... Pause....

Nur meckern hilft aber auch nicht :wink:
ich werd der Synaser Unit mal fürs Windows System den fehlenden Sendepuffer spendieren, mal gucken ob ich das hinbekomme....
Grüße von Siro
"C" verCehnfacht die Entwicklungszeit...
siro
 
Beiträge: 162
Registriert: 23. Aug 2016, 13:25
Wohnort: Berlin
OS, Lazarus, FPC: Windows 7 Windows 8.1 Windows 10 | 
CPU-Target: 64Bit
Nach oben

Beitragvon mse » 10. Feb 2017, 09:13 Re: Synaser RS232 und FTDI COM14

"Syn" steht ja auch für "Synchron" in Synapse. Wobei normalerweise beim Senden die Daten in einem Rutsch in einen Betriebssystem-Puffer geschrieben werden können und der aufrufende Thread nicht warten muss. Vielleicht kann man dieses Verhalten bei SynaSer beeinflussen?
Beim Lesen muss man entweder pollen oder einen separaten Thread verwenden. Die MSEgui Komponenten für Serielle Kommunikation machen Letzteres übrigens automatisch und haben OnInputAvailable Ereignisse welche mit dem Mainthread synchronisiert werden.
mse
 
Beiträge: 1561
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.4.2,git master FPC 3.0,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon siro » 10. Feb 2017, 10:10 Re: Synaser RS232 und FTDI COM14

Da hast Du völlig recht, SYNCHRON und ich möchte Asynchron arbeiten... :wink:
Mal schauen was da noch geht. So schnell geb ich ja nicht auf....

-----
Komplette Unit in Windows neu geschrieben: :oops:
Baudratentest auf COM1
128KBaud ist maximal, danach will mein System nicht mehr.

Auf dem FTDI Port kann ich setzten was ich will, Windows meint, es ist immer Okay.
Die Funktion SetCommstate(hFile,DCB) liefert immer TRUE

Puffergrößen einstellen scheint auch generell immer zu gehen.
Auf COM1 sowie meinem FTDI auf COM14
Die Windows Funktion SetupComm(hFile,SizeIn,SizeOut) liefert zumindest immer TRUE
auch bei Puffergrößen von 10.000.000

Habe einen Sendepuffer von 1 Million eingestellt und diesen dann ausgegeben.
Mit dem Oszilloskop mir das auch angesehen. Der Aufruf kommt sofort zurück und im Hintergrund wird fleissig gesendet.

Nach 1 Minute 27 Sekunden sind 1 Million Daten gesendet worden mit 115200 Baud
Dabei andere Anwenungen bedient, gesurft und in eigener Anwenung diverses getan.
Das macht doch schon einen recht guten Eindruck :)

Hab versucht die Änderungen in die Synaser Unit zu implementieren, bisher leider ohne Erfolg.
Das würde aber eh nur auf einem Windows System funktionieren.

Für den Empfang nehme ich dann einen Timer, hier will ich noch testen wie sich der FTDI Treiber verhält,
für einen Freitag reichts aber heute... :mrgreen:

Ich werde jetzt eine eigene Mini-Unit für meine Anwenungen fertig machen.
Mehr als Baudrate setzen und Daten Senden und Empfangen brauche ich eh nicht.
Grüße von Siro
"C" verCehnfacht die Entwicklungszeit...
siro
 
Beiträge: 162
Registriert: 23. Aug 2016, 13:25
Wohnort: Berlin
OS, Lazarus, FPC: Windows 7 Windows 8.1 Windows 10 | 
CPU-Target: 64Bit
Nach oben

» Weitere Beiträge siehe nächste Seite »
Nächste

Zurück zu Komponenten und Packages



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

porpoises-institution
accuracy-worried