UART lange Antwortzeit

USB arbeitet Blockweise. Ich sehe leider nicht wie du die Daten 
überträgst. Wenn du 1 Zeichen sendet und dann auch 1 Zeichen wartest 
dann wird das niemals schnell werden.

Du musst dafür sorgen, das viele Daten in einem Rutsch übertragen 
werden.

Danke dir für deine Antwort, ich sende die ASCI zeichen "A0" und erwarte 
10 Byte zurück. CR bedeutet das Ende der Übertragung.

Es war mir bewusst, dass ich so den USB nicht gerade optimal ausnütze, 
hätte jedoch erwartet, dass ich 20Hz rauskriege um ein flüssiges Bild 
darstellen zu können. 4 Hz dünkt mich doch ein wenig sehr tief?

Christian schrieb:
> Die Datenübertragung funktioniert einwandfrei, jedoch
> kriege ich nur ca 4Hz raus

Mach doch mal das Gleiche nicht mit Labview, sondern mit einem 
Terminalprogramm. Man kann eine Datei senden und die Verzögerung nach 
jeder Zeile einstellen.

Georg

Habe ich ausprobiert und bin gleich langsam.

Christian

Du kannst im Gerätemanager in den Einstellungen des COM-Ports das 
Timeout einstellen, das kannst du bis auf 1ms runterstellen.
Reiter "Anschlusseinstellungen" -> Erweitert -> BM Einstellungen -> 
Wartezeit auf 1ms einstellen.
Die Timeouts kannst du auch gleich mal auf 0ms setzen falls die anderes 
eingestellt sein sollten.

Ich habe es im Terminalprogramm "HTERM" ausprobiert und kriege 
vergleichbare Taktzeiten. Auf die Anregung von Chris habe ich die 
Einstellungen des Com Ports verändert (siehe Anhang), leider sind die 
Ergebnisse gleich.

Christian

Christian schrieb:
> Ich habe es im Terminalprogramm "HTERM" ausprobiert und kriege
> vergleichbare Taktzeiten. Auf die Anregung von Chris habe ich die
> Einstellungen des Com Ports verändert (siehe Anhang), leider sind die
> Ergebnisse gleich.
>
> Christian

Sieht bis auf die Puffergrößen bei mir gleich aus, dort habe ich jeweils 
4096 Bytes drin.

Da habe ich auch beides probiert. Ich habe gehofft dass das Problem zu 
grosse Pakete sind (wo ich doch sehr kleine verwende).

Wie gesagt, habe ich beides PROBIERT, nicht nur GEHOFFT :D
und wie gesagt, ich habe es nicht nur im LabView ausprobiert sondern 
auch in einem Terminalprogramm. Also wird der Fehler höchst 
wahrscheinlich nicht in LabView liegen.
Hast du sonst noch eine Idee?

Sehe ich gleich, dass es der FTDI Chip nicht sein wird. Ich tippe auf 
Windows bzw Treiber. Nur hilft mir dies nicht viel weiter.
Ein weiterer Punkt; ich kriege 4 Übertragungen raus, egal ob ich jetzt 1 
Byte oder 20 Byte schicke --> nicht FTDI.

Christian schrieb:
> Sehe ich gleich, dass es der FTDI Chip nicht sein wird. Ich tippe auf
> Windows bzw Treiber. Nur hilft mir dies nicht viel weiter.

Fang doch um himmelswillen systematisch an!

Also zu allererst ein logischer Kurzschluß direkt auf der seriellen 
Seite des FTDI, also TxD an RxD. Dann probierst du aus, wie schnell 
deine ganze Strecke von der Applikation über's OS zum FTDI und wieder 
zurück ist.

Normalerweise geht das ruckzuck, die Latenzzeit zwischen einzelnen 
Datenblöcken auf den USB liegt so bei 1 ms. Du solltest also beim 
Terminalprogramm beim Tippen keinerlei Verzögerungen spüren.

Die nächste Sache ist dann das Programm, was auf deinem µC läuft. Wenn 
sich das zu dämlich anstellt, dann wird das Ganze eben langsam. Und 
genau das vermute ich.

W.S.

Ich habe schon eine Menge mit unterschiedlichen USB-UART Adaptern 
gemahct, nur nicht mit dem FT232 Chip. In allen Fällen lagen die 
Latenzzeiten ohne besondere Konfiguration im Bereich um 1ms.

250ms ist nicht in Ordnung.

Teste den Adapter mit Hterm in einer Schleife, also ohne weitere 
Hardware und ohne Matlab.

Der Logische Kurzschluss von TX-RX habe ich durchgeführt. Antwort kommt 
ohne spürbare Verzögerung. Getestet habe ich in Hterm. Nur auch hier 
vergehen bis 250ms bis er eine erneute Meldung sendet, wenn ich den 
Befehl aus Hterm in einer schleife ohne Verzögerung schicke.

Ein Lösungsansatz wäre hilfreich. Ich habe diese Konfiguration auch 
schon an einem anderen PC mit hTerm ausprobiert, leider mit gleichem 
Ergebnis.

Das ist eine gute Frage.
Ich habe das USB-Kabel getauscht und es sieht immer noch gleich aus.

Ich habe es herausgefunden :D

Das Problem ist der CLR Befehl den ich im Labview eingebaut habe. Dieser 
braucht ca 250ms. Wenn ich diesen weg lasse kriege ich ca 600Hz raus 
(Bild Timing im Anhang). Warum ich auf die gleichen Ergebnisse mit HTerm 
komme weiss ich nicht.

Vielen Dank an alle die geholfen haben eine Lösung zu finden.


Gruss Christian

Dann müsste HTerm ja jetzt nach der Korrektur auch schneler sein. Ist 
das der Fall?

> Der Logische Kurzschluss von TX-RX habe ich durchgeführt.

Haben wir alle verstanden. Richtig heisst es: Loop-Back, nicht 
Kurzschluss.

Das wäre eine Möglichkeit. Ich bin auch ziemlich überrascht. Ich habe 
eine Programmlaufzeit (ohne Kommunikation) von ca 150us, da fallen 250ms 
doch ziemlich ins Gewicht ;D.
Ich nehme an, dass es einen schnelleren Weg geben wird den Buffer zu 
lehren.