Problem mit dem FTDI USB Chip FT232BM

[Unregistriert]

Hallo,

ich habe den FT232BM nach gegebener Applikationsschaltung aufgebaut und an meinen Mikrocontroller angeschlossen (RxD, TxD). Sende ich nun Zeichen via ein Terminalprogramm vom PC über den FTDI Chip an meinen Controller, so kommen diese korrekt an (Baudr. 9600). Wenn ich nun vom Controller
zum PC ein Zeichen schicke kommt dieses auch korrekt an, jedoch folgt jedesmal ein weiteres Zeichen (0xFF). Dieses kann aber nicht vom Controller
kommen. Hat jemand eine Erklärung für dieses zusätzliche Zeichen?

Gruss
Charly

[MacSeck]

was für´n PC??? bzw. Betriebssystem???

Ich könnte mir vorstellen, dass das ffh eine Erweiterung auf entweder
- Wortlänge ist, was allerdings bei "hol ein BYTE vom Controller" oder vom Schnittstellenpuffer nicht sein sollte..
- das was mit UNICODE zu tun hat (16 Bit Zeichensatzerweiterung)
- das was mit Unzulänglichkeiten und Prog-Schlamp auf 64-Bittern ist
- oder ein Problem Deiner Schnittstellenanbindung an die verwendete Hochsprache. Dazu gäbe es auch zwei Möglichkeiten:
a) nach dem Zeichen folgt 00h (als Zeilenende, Stringende (pchar und solcherlei), eben C-konform), aber es ist ja ffh... als Extra Schmankerl
b) Zeichen, true! - also korrekt empfangen (true = -1 = ffh, false = 0)

sowas vielleicht???

[Steffen]

Da stimmt unter Umständen irgendwo das Timing nicht. Der FTDI-Chip erkennt anscheinend nach dem Stoppbit noch ein Startbit. Da aber nichts weiter kommt wird 0xFF draus.

Läuft der MC mit einem Quarz?

Steffen

[Unregistriert]

Hallo,

der Mikrocontroller läuft mit einem 12 MHz Quarz. Ürigens, wenn ich vom Mikrocontroller aus einen ganzen String (z.B. Hallo) sende, kommt im Terminalprogramm nur Schrott an (mal ein Zeichen, mal zwei). Hab den Treiber von FTDI, der eine COM Schnittstelle bereitstellt.

Gruss
Charly

[Unregistriert]

Allerdings habe ich die Handshake Leitungen RTS/CTS (des Chips) nicht angeschlossen.
Aber an dem kann es doch normal nicht liegen, oder?

Charly

[Carsten]

Hallo,

schau doch mal nach, was der USB-Chip für ne Baudratentoleranz hat und dann rechne mal genau nach ob der kann was der Controller ausgibt.
Es könnte ja sein, dass dein Controller mehr Toleranz vertägt als der USB-Chip. Oder es unterschiedliche Abweichungen zwischen TX und RX Routine.

Gruß
Carsten

[edgar]

http://www.ftdichip.com/knowledgebase/AppNotes/005/knowledgebase.htm

steuersignale haben einfluss...

edgar

[peter dannegger]

klingt wirklich hart nach Baudratenfehler.

Nimm doch für den 8051 besser ein Standardquarz z.B. 11,0592MHz und nicht sowas krummes wie 12MHz.

Das Handshake solltest Du auch verwenden in der Richtung 8051->USB, da ja durch die langen Latenzzeiten der USB-Chip überlaufen könnte.


Peter

[Steffen]

Wenn dein Controller (besser gesagt deine Software) keinen Hardwarehandshake unterstützt brauchst Du die Handshakeleitungen nicht zu beschalten.
Auf der FTDI-Seite werden diese nicht durch den FT232 sondern von der PC-Software (Hyperterminal etc.) gesetzt. Einen Pufferüberlauf kannst Du damit also nicht verhindern. Deine Software sollte allerdings sicherstellen, dass nicht mehr als 128 Byte (interner TX-Puffer des FT232BM) ohne Rückmeldung der PC-Software (egal ob setzen der Handshakeleitungen oder Softwarehandshake) an den FT232 gesendet werden.
In der anderen Richtung (PC->FT232) sind es übrigens 384 Byte.

Steffen

[Steffen]

Quark, man sollte doch vor dem Schreiben mal ins Datenblatt schauen.

Der FT232BM übernimmt selbst den Handshake. Also ist es bei hohen Geschwindigkeiten sinnvoll die Handshakeleitungen auch auszuwerten.

Steffen