www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATmega8 und FT232BM: Datenkorruption bei hohen Baudraten


Autor: Philipp Wagner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp Wagner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp Wagner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp Wagner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mark Hämmerling (haemi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.