C# SerialPort.Write nur alle 40ms

[Hanskarl (Gast)]

Hallo,

ich möchte mit C# Daten an die Serielle-Schnitstelle senden und von 
dieser empfangen. Prinzipell funktioniert senden und empfangen auch 
problemlos.
Ich habe eine Funktion SendFrame(...) diese sendet die in den Argumentan 
angegeben daten mit der Write-Funktion als Byte-Array und liest die 
Antwort der Hardware mit der Read-Funktion als Byte-Array zurück. Die 
Hardware sendet die Antwort binnen 2ms ab.
Ich möchte nun mit einer for-Schleife 16 Frames senden und die Antwort 
lesen.

Wenn ich mit dem Oszi auf die Datenleitungen schau, dann sehe ich das 
alle 40ms ein Frame gesendet wird und die antwort prompt innerhalb der 
2ms folgt.
Die Frage die sich mir jetzt stellt ist, woher kommt die 40ms Delay? Ich 
habe in meinem Programm nirgends eine Sleep oder sonstige Delay-Funktion 
eingebaut.

Kann es evtl. an der USB/COM-Brücke (FT232) liegen?

[Nicht"Gast" (Gast)]

Moin,

die FTDIs benutzen den bulk data transfer mode vom USB. der ist leider 
als nicht Zeitkritisch eingestuft und wird als letztes durchgeführt, 
wenn noch andere Operationen am Bus anstehen.

da bist du mit 40ms gut dran ;)


grüße

[Peter II (Gast)]

ich nutze einen RS485 mit FTDI, dort bekomme ich in weniger als 10ms 
meine Antwort. Es scheint also kein generelles Problem mit FTDI zu sein.

sicher das du nicht noch Probleme im code hast?

[Nicht"Gast" (Gast)]

nachtrag.

von FTDI gibts ein Tool zum auslesen vom eeprom. schau da mal nach, was 
für eine Buffergröße USB seitig benutzt wird (wenn das geht) und schreib 
den voll. vielleicht wirds dann schneller.

ich hab leider grad keinen Adapter zur Hand um zu schauen wo's steht und 
ob man den überhaupt einstellen kann.

Wenn das morgen noch keiner geschrieben hat, schau ich mal


Grüße

[Stefan (Gast)]

Für den VCP kann man in den Treibereinstellungen unter 
Anschlusseinstellungen/ Erweitert einiges einstellen.
Insbesondere Latenz und Puffergrößen
Stefan

[Philipp (Gast)]

Ohne deinen Code in C# ist es extrem schwer zu sagen wo der Fehler 
liegt.
Es könnte durchaus sein, dass dir der windows scheduler dazwischen funkt

[Peter II (Gast)]

Philipp schrieb:
> Es könnte durchaus sein, dass dir der windows scheduler dazwischen funkt

aber nicht bei 40ms. Ich nutze auch Windows und keine speziellen 
Treiber. Aber ich nutze es auch C und nicht c# - das erklärt aber nicht 
den unterschied.

[Marc O. (Gast)]

Hi ich weis nicht genau, ob es meine Antwort jetzt stimmt, aber könnte 
es sein, dass dein Betriebssystem dem Prozess/Thread während dem senden 
immer mal wieder die Rechenzeit entzieht? Oder verhinderst du das 
unterbrechen?

[Peter II (Gast)]

Marc O'Patrick schrieb:
> Hi ich weis nicht genau, ob es meine Antwort jetzt stimmt, aber könnte
> es sein, dass dein Betriebssystem dem Prozess/Thread während dem senden
> immer mal wieder die Rechenzeit entzieht? Oder verhinderst du das
> unterbrechen?

Klar kann das sein, aber da macht nur weinige ms aus, (außer das System 
läuft auf 100% cpu last)

[Hanskarl (Gast)]

Danke für die Antworten...

ich habe nun mittels der Stopwatch-Klasse mal die einzelen Codezeilen 
angesehen und festgestellt, dass ich noch von der Verwendung der 
Mainboard-Seriellen-Schnittstelle (kein USB-Teil) folgende Anweisung 
hatte:

mySerial.RtsEnable = true; // RS485 Driver to Listen-Mode

Diese macht eine Laufzeit von 20ms. Warum auch immer. Zweimal diese 
Anwesung erklärt die 40ms.

Ich muss jetzt mal probieren, ob dieses Delay auch auf der 
Mainbord-Schnittstelle auftriff.

[ich (Gast)]

Hanskarl schrieb:
> Diese macht eine Laufzeit von 20ms. Warum auch immer.

Das macht der direkte Zugriff auf das Com Pinchen!