FTDI Probleme! bzw. Komisch!

[jokern (Gast)]

Hallo!
Folgendes habe einen Atmega 16 mit einem 4 MGz Quarz, von diesem Atmega 
benutze ich nur die 8 analog digital Wandler-Eingänge. Am Atmega ist ein 
MAX232 angeschlossen und mit einem 9pol D-Sub Verbunden sprich eine 
RS232 Schnittstelle um mit einem LabVIEW Programm meine angelegten 
Spannungen Digital am Computer darzustellen. Alles funktioniert 
wunderbar.
Jetzt kommen wir zum Problem:
Nun habe ich auch einen FTDI-Chip an den Atmega angeschlossen weil ich 
mir gedacht hab USB ist doch wunderbar und die RS232 Schnittstelle ist 
am aussterben (Notebook). Nun ist das Problem das alles anscheinend noch 
läuft nur die Darstellung aufeinmal in LabVIEW zähflüssiger läuft, die 
Daten kommen anscheinend verzögert an, oder etc.
Hat jemand eine Lösung?
MfG
Johannes

[Ralf (Gast)]

Soweit ich weiss, ist beim FTDI Treiber ein 16ms Timeout für das Abholen 
der Daten eingestellt. Ich könnte mir vorstellen, dass es daran liegt. 
Du könntest probieren, dieses Timeout auf 1ms zu reduzieren. Das geht in 
den erweiterten Treiber-Einstellungen im Gerätemanager.

Ralf

[Andreas W. (Firma: andreas-weschenfelder.de.vu) (rupplyn)]

Check mal folgende Stichwörter ab:

- Paketgröße verändern
- Latency-Timer verändern
- Siwu-Pin-Unterstützung

[jokern (Gast)]

Hallo Ralf!
Also das mit verändern der Wartezeit hat leider nichts gebracht!
Aber trotzdem danke für die Schnelle Antwort!
Gruß Johannes

[Christian R. (supachris)]

Wie schickst du denn die Daten? Immer ein Byte? Bei USB gibts nur 
paket-orientierten Transfer, d.h. für immer ein Byte wird ein ganzes 
Paket verschwendet, das nächste erst wieder nach einer Millisekunde. Du 
musst, wenn du die Geschwindigkeit haben willst, immer gleich viele 
Bytes auf ein Mal senden, dann kann der FTDI die in ein Paket, und wenn 
möglich gleich noch mehrere Pakete in einen MicroFrame packen.

[jokern (Gast)]

Könnte es auch evtl. daran liegen dass ich keinen Hardware Handshake 
habe?
Hab nur TxD und RxD mit dem Atmega verbunden.

Johannes

[jokern (Gast)]

Und noch evtl. ne blöde Frage aber irgendwie programmieren muss ich den 
FTDI-Chip nicht?

[Christian R. (supachris)]

Programmieren musst du erst mal nix.

Fehlendes HW-handshake merkst du, wenn Daten verloren gehen.

Es liegt definitiv an der USB-Paket-Geschichte. Wenn deine Daten bloß 
langsam reinkleckern, wirds sehr langsam, die Latenzzeit ist viel viel 
höher als bei einer normalen RS232. Also puffere die Daten und übertrage 
dann meinetwegen 512 Byte in einem Rutsch. Ich hab auch mehrere der FTDI 
im Einsatz, meist mit 460.800 oder 921.600 Baud, und mit entsprechend 
großen Paketen geht das sau-schnell.

[Marco G. (stan)]

dazu gibt es auch eine AppNote von FTDI:
http://www.ftdichip.com/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf

[jokern (Gast)]

Das ist ja für mich alles Neuland. Und ich war schon froh das des 
einigermaßen alles funktioniert hat. Und jetzt macht mir das USB so 
Probleme. Aber verstehe ich das richtig ich müsste nur mein Programm auf 
dem Atmega anpassen und dann natürlich noch mein LabVIEW Programm 
mitteilen dass jetzt die Pakete anders ankommen.

[Michael G. (linuxgeek)]

Ich frag mich nur wie ich ueber die USART "Pakete" absenden kann wenn 
der Sendepuffer ein Byte gross ist. Am Stueck geht das also sowieso 
nicht. Soll damit "schnell hintereinander" gemeint sein?

[Benedikt K. (benedikt)]

Über die USART immer nur Byteweise. Alles was innerhalb 1ms rausgeht 
wird automatisch zu einem Paket.
Auf der PC Seite muss man aber Pakete machen: Wenn man die 
Sendefuntktion für jedes Byte einzeln aufruft, wird jedes Byte einzeln 
gesendet. Daher muss man hier immer Pakete übergeben.

[Michael G. (linuxgeek)]

Gut zu wissen...