Hallo, ich habe hier ein Problem mit einem ATmega8 MCU (8 MHz Quarzoszillator, Fuses richtig gesetzt) und der seriellen Datenübertragung über USB mit dem FT232BM. Die Schaltung funktioniert wunderbar bei geringen Baudraten (bis ca. 9600 Baud), aber sobald es höher geht kommen die Daten korrupt an (z.B. aus 'X' wird 'r' usw.). Ich benötige eine Baudrate > 250kBit/s, aber ich komme noch nichteinmal in diese Gegend. Dass es am Quarz liegt kann ich mir auch fast nicht vorstellen, da laut Datenblatt der Fehler bei 250kbit/s 0,0 % beträgt. Was ich mir noch vorstellen könnte ist, dass es am Handshaking liegt. Das Problem dabei ist, dass ich auch noch nirgendwo eine wirklich ordentliche Erklärung gefunden habe, wie das eigentlich funktionieren soll. Ich bin (ausgehend von einem einzigen Satz in einer App-Note von FTDI) mal davon ausgegangen, dass der FT232BM solange sendet, wie CTS# high ist, und RTS# auf low setzt, wenn er nicht mehr senden kann (interner Buffer voll, d.h. der Computer empfängt die Daten zu langsam). Dass der Computer schon zu langsam beim Datenempfang bei 14400 Baud ist, leuchtet mir zwar nicht ganz ein, aber möglich wär's ja (weil ab da bekomme ich korrupte Daten). Ich habe das Handshaking also auf einige verschiedene Methoden versucht (was ich so im Internet gefunden habe), aber funktioniert hat's nie wirklich. Das Problem ist, dass der FT232BM RTS# nach den ersten paar Bytes vom MCU auf low setzt, was wohl heißen soll, sein Buffer ist voll und ich soll warten bis ich was neues sende. Das tue ich dann auch und warte so lange bis RTS# wieder auf high ist, was aber nie passiert. Es kommt somit also garkeine ordentliche Verbindung zustande. Das interessante dabei ist jetzt, dass RTS# auf high (sprich: MCU, du kannst senden) ist, solange ich die Daten nicht vom Computer empfangen lasse (d.h. solange ich cu nicht starte, unter Windows ist's mit Hyperterminal das gleiche Spiel). Was ich bei dem ganzen Handshaking dann noch nicht verstehe, für was brauche ich dann die CTS# Leitung? Ich will ja nicht, dass der FT232BM aufhört zu senden, also kann ich die ja auf high lassen, oder? Im Internet hab ich da ein paar Beschreibungen gefunden, die das Wort "Handshaking" etwas logischer erscheinen lassen (wenn der eine auf 1 geht, muss der andere auf 0, was der andere dann auch wieder mit 0 bestätigt usw.). Allerdings funktioniert's damit genauso wenig. Zu dem Ganzen kommt jetzt noch, dass es ja drei Handshaking-Methoden zu geben scheint. RTS/CTS, DTR/DSR und XON/XOFF. Lassen wir die letzte Methode mal weg, bleiben immer noch zwei Methoden des Hardware-Handshakes übrig. In der App-Note "Data Throughput, Latency & Handshaking" werden beide Methoden exakt gleich beschrieben? Wozu sind aber dann beide am Chip vorhanden wenn sie eh das gleiche bewirken? Oder ist der eine fürs Senden und der andere fürs Empfangen? Ich hab's versucht mit beiden, doch das Ergebnis war leider das gleiche. Habt ihr das schonmal hinbekommen? Habt ihr es schonmal geschafft, mit dem FT232BM Daten in einer ordentlichen Baudrate fehlerfrei zu übertragen? Ich bin mir sicher, ich habe nur irgendwo einen kleinen Denkfehler, aber ich sitz jetzt schon zwei Tage dran und finde den Fehler einfach nicht. Danke schonmal, Philipp
Die ganzen Handshaking Leitungen haben eine # Zeichen dahinter, d.h. sie sind invertiert: Liegt CTS# auf Low sendet der FT232 Daten an den uC. Liegt CTS# azuf High macht der FT232 nichts. Umgekehrt darf man nur senden, wenn RTS# auf Low liegt.
Benedikt, danke, das hatte ich komplett übersehen. Jetzt funktioniert das wenigstens soweit, obwohl die Daten immer noch korrupt ankommen. Als Grund dafür würde ich mal Timing-Probleme mit dem 8 MHz-Quarz sehen, ich besorge mir jetzt mal ein genaueres Quarz und dann schaumer mal - hoffentlich geht's dann, ansonsten fällt mir garnichts mehr ein. Noch eine kurze Frage, die noch offen geblieben ist: Reicht es beim Handshaking dann also, RTS/CTS ODER DTR/DSR zu verwenden? Für was gibt es dann eigentlich beide? Philipp
Im Normafall reicht RTS CTS. DTR und DSR Signalisieren nur Daten verfuegbar, sind also vernachlaessigbar. Am Quarz sollte es eigentlich nicht liegen. Ich habe schon 3MBaud mit 24MHz am AVR verwendet.
Das Problem scheint nur zu sein, dass ich es nicht fertig gebracht habe, den Treiber auf genaue 250kBaud oder 500kBaud einzustellen (was eigentlich 0% Fehler sein sollte), sondern nur auf 230,4kBaud usw., und bei diesen Geschwindigkeiten der Fehler recht hoch ist. Oder geht das doch irgendwie die Geschwindigkeiten im Treiber frei zu setzen? Philipp
Ich verwende verschiedenste Terminals (Bray Terminal, HTerm) und auch eigene Routinen in C. Da hatte ich sowohl mit 115,2, 230,4, 250, 500, 1000kBaud usw. nie Prolbeme: Der VCP Treiber akzeptierte alles.
Ich hatte nicht gedacht, dass es jemals noch funktioniert - aber es funktioniert tatsächlich. Der Tip mit Bray Terminal war echt gut, das Programm ist mal um Längen besser als Hyperterm. Jetzt suche ich nur noch was vergleichbares für Linux, bisher verwende ich cu, aber das mag mich irgendwie nicht mehr so wirklich :-) Kennt da jemand was? Philipp
Ich antworte mir einfach mal selber. Ich habe jetzt CuteCom (http://cutecom.sf.net) gefunden, das fast alles unterstützt was ich brauche. Einzig die Übertragungsraten, die ich gebraucht hätte, haben gefehlt, aber ein paar kleine Änderungen im Quellcode hat auch das Problem behoben (ich habe jetzt 500kBaud). Dabei ist mir aufgefallen, dass die Baudraten alle als Konstanten (definiert in /usr/include/bits/termios.h) in Linux gehandhabt werden, ist es denn nicht möglich, jede beliebige Baudrate zu setzen? Philipp
Salve, unter Linux lassen sich die FT232 imho am elegantesten über die libftdi ansprechen. Die etwas murksige Einstellung von "non-standard baudrates" über so einen Trick mit 38400 bps (Details hab ich schonwieder vergessen) entfällt dann. Mit der lib kannst Du auch andere Parameter einstellen, wie Latenzzeiten etc. Zum Tunen ganz nützlich (in meiner Anwendung kam es auf minimale Reaktionszeit an). Als Terminal verwende ich minicom, aber auch nur weil ich noch nie ein anderes probiert oder gebraucht habe. Mark
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.