FTDI Konfiguration

[kaplan (Gast)]

Ich bekomm meine Datenübertragung noch nicht ganz fehlerfrei hin. 
Passend zu den 20MHz Systemtakt des ATMEga644 sind:
Baudraten: 2500000, 1250000, 625000, 500000, 312500, 250000
ich hab sie alle getestet. Bei 312500 bekomme ich keine Fehler.
Bei den höheren sind übertragungsfehler da. aber nur ab und zu. nicht 
immer.
D.h. eine gute sekunde klappts wunderbar. danach kommen für 0.5 sekunden 
verstärkt fehler.

Ich benutze die UART.C library von Peter FLeury auf ATMega seite.
DEn FTDI lese ich mittels D2XX.

ich frage mich welche Konfiguration wohl am besten ist.
gerade die timings wie latency sind mir etwas schleierhaft.

Die daten des ATMEga haben 5 Byte start und endheader. Zwischendrin 
liegen die daten.

Etwa so:
StartHeader (4Byte), Datenmenge(1Byte), Paket1, Paket2, ... PaketN, 
Endheader

Meine Routine in C++ empfängt EINZELNE Bytes. Sie sucht zyklisch die 
Daten durch bis der Startheader gefunden wurde. dann lese ich die 
DATENMENGE ein. nun weiß ich wieviele Pakete folgen. nach dem letzten 
Paket muss der endheader folgen. stimmen die dort empfangenen Daten 
nicht mit dem Endheader überein, gehe ich von einer fehlerhaften 
übertragung aus.

Die übertragung funktioniert zu 90% fehlerfrei. Ab und zu aber leider 
nicht. Es scheint dass einzelne Bytes verloren gehen bei höheren 
Baudraten.

Ich hab in den Anmerkungen viel über Latency usw gelesen.
Welche PArameter sind denn für meine Übertragung geeignet?

Der Mikrocontroller sendet immer eine unterschiedliche Anzahl an 
Paketen. Nur die beiden Header sind immer identisch!
Danke für die Hilfe
Patrick

[Arc N. (arc)]

Falls die Uart-Routinen nicht angepasst wurden, werten diese die 
Statussignale des FT nicht aus! D.h. der AVR sendet u.U. Daten an den FT 
dessen FIFO voll ist und der allerdings erst senden kann, wenn er vom PC 
abgefragt wird...

[Patrick K. (kaplan)]

Ich habe die Baudrate auf 250 000 reduziert. Dennoch kommen Fehler. Mit 
steigender Baudrate müsste dann doch die Fehlerrate überproportional 
zunehmen.
Sie nehmen zwar zu aber eher in dem Maße wie auch die Datenrate 
ansteigt.

Wie kann ich sehen ob FIFO Overflow hat (hatte)?

Die Statussignale kann ich vom uC nicht auslesen. Ich hab nur RX und TX 
mit dem FTDI verbunden.


Desweiteren hab ich in der Dokumentation des FTDI gefunden, dass eine 
FLow Control immer an sein sollte. Die sind doch unabhängig vom uC oder? 
Also reine USB Sache? Die ganze Sache ist so verwirrend. Ich weiß 
momentan nur dass ich Pakete verliere.

[Arc N. (arc)]

> Wie kann ich sehen ob FIFO Overflow hat (hatte)?
> Die Statussignale kann ich vom uC nicht auslesen. Ich hab nur RX und TX
> mit dem FTDI verbunden.

Dann kann der AVR nichts feststellen!
Falls die Hardware nicht mehr geändert werden kann, würde ich noch mal 
das Software XON/XOFF des FTDIs probieren.

[Patrick K. (kaplan)]

XON OFF hab ich aktiviert. Doch es bleiben immer noch Fehler...

ftStatus = FT_SetFlowControl (ftHandle1, FT_FLOW_XON_XOFF, UCHAR('N'), UCHAR('U'));

passt das so?

Da ich 20 MHz uC Takt habe, ist die Wahl der Baudrate so ne Sache. 
Gingen denn theoretisch auch 1250000Baud am FTDI? Ich hab das mal 
getestet aber ich hab ebenso die Fehler wie bei 250000. Aber es kam mir 
nicht so vor als ob der FTDI damit probleme hat.

Soll ich anstatt D2xx doch eher Virtual Comport nuntzen?
Oder hat jemand fuer D2XX ein gutes beispiel?
ich brauche halt 100% zuverlaessige uebrtragung mit hoher 
geschwindigkeit (mindestens 250 000 Baud). Je mehr desto besser.


danke
Patrick

[Arc N. (arc)]

> Gingen denn theoretisch auch 1250000Baud am FTDI? Ich hab das mal
> getestet aber ich hab ebenso die Fehler wie bei 250000. Aber es kam mir
> nicht so vor als ob der FTDI damit probleme hat.

Jein, 3M / 1250000 = 2.4, der FTDI kennt als Subdivisor nur (n * 0.125) 
also wäre der Geamtteiler 2.375, obwohl der Fehler relativ klein ist, 
würde ich das bei diesen Datenraten nicht machen.

XON/XOFF setzt auch Unterstützung in der PC und AVR-Software voraus.
Wie die Daten aufzubereiten sind bzw. ersetzt werden steht z.B. in der 
Appnote: 
http://www.ftdichip.com/Documents/AppNotes/AN232B-09_Modem_Emulation_Mode.pdf

[Arc N. (arc)]

Nachtrag: Das einfachste wäre trotz des "Aufwands" die Flusskontrolle in 
Hardware.

[Patrick K. (kaplan)]

> Jein, 3M / 1250000 = 2.4, der FTDI kennt als Subdivisor nur (n * 0.125)
> also wäre der Geamtteiler 2.375, obwohl der Fehler relativ klein ist,
> würde ich das bei diesen Datenraten nicht machen.
>

das ist ein  richtiges problem:
denn mein AVR laeuft mit 20 MHz. Da find ich gar nicht so schnelle 
Baudraten:
Unterstuetzt im normal mode:
125000
625000
416666
312500
250000
usw

IM Double mode
2500000
1250000
833333
625000
500000

D.h. die hoechste Baudrate mit 0% Fehler auf allen Seiten ist
500000Baud im Double Mode??????
und 250000Baud im Normal Mode???
Ich glaube der FTDI unterstuetzt Double Mode... (U2XN=1)

> XON/XOFF setzt auch Unterstützung in der PC und AVR-Software voraus.

AVR Software versteh ich nicht. Im Datenblatt zum ATMEga644 find eich 
nix unter USART ueber XON XOFF Modus. Und die daten die ich versende 
sind einfach Bytes von 0x00 bis 0xFF. Mit uart Library vom Peter Fleury, 
1Stopbit, No parity, 8 Datenbits.