FT232R und handshakes

[lowtexx]

Hallo!

Ich möchte einen FT232R zur Kommunikation mit einem uC überreden. Das ganze soll mit 115kbaud ablaufen. Dazu sind unbedingt die Hardware-Handshakes überr RTS#/CTS# notwendig. Hat das schon mal jemand zum laufen bekommen? Ich lese hier und in anderen Foren immer, dass die Signale nicht verwendet werden, weil es schon funktionieren wird ....

Ich habe das Problem, dass das RTS# Signal vom FT232R immer auf high (logisch 0) liegt, und damit dem angeschlossenen Controller signalisiert, dass der FT232 gerade nichts empfangen kann.
Hab ich da was mit der Bedeutung der Signale falsch verstanden?

MfG
lowtexx

[Hubert.G]

Warum glaubst du das die Hardwarehandshakes notwendig sind, bei permanenten Verbindungen meiner Ansicht nach nicht. Diese Leitungen sind doch dafür da damit der Sender nicht ins leere sendet oder wenn der Empfänger nicht mit der Sendegeschwindigkeit mithalten kann.

[lowtexx]

Du hast Recht. Aber genau das ist das Problem. Der empfänger kann ni cht immer mithalten. Daher muss ich Handshakes verwenden, um den Datenstrom vom usb zu bremsen bis der uC die Daten wieder verarbeiten kann.
Das funktioniert an sich auch. uC setzt CTS# auf high (logisch 0), wenn er nicht gestört werden will. Aber er darf nun nichts senden (z.B. ACK), da RTS# immer high ist.
Irgendwie muss das mit dem FT232 doch funktionieren, wenn es die Pins daran schon gibt.

[ogni42]

Was sagt denn das Datenblatt vom FT232R. Muss man den vielleicht konfigurieren, damit er RTS/CTS kann?

[lowtexx]

Das Datenblatt sagt nur dass per default CTS# und RTS# als low-aktiv programmiert sind.
Hab' dies auch mit Mprog mal geändert, aber dann ändert nichts. außerdem versteht der Controller das dann auch nicht mehr, da er low-aktiv arbeitet.

[ogni42]

Also wenn RTS auf 0V liegt (also logisch True) ist der FT232 bereit Daten zu empfangen
CTS = 0V (logisch True) signalisiert doch, dass die Gegenstelle (der AVR) Daten empfangen kann.

Bist Du sicher, dass Du die Logik auch so programmiert hast?


Ansonsten sind die Signale auch hier beschrieben:
http://de.wikipedia.org/wiki/RS232

[lowtexx]

Also wenn RTS auf 0V liegt (also logisch True) ist der FT232 bereit Daten zu empfangen
Ja. So hab ich das auch verstanden. Aber: RTS# ist immer auf 3.3V (log. FALSE) und empfängt die Daten trotzdem!
Die Flusskontrolle ist im Treiber aktiviert und ich verwende hterm zum als Terminal-Programm. Das ganze sollte doch aber eigentlich unabhängig vom Terminal-Programm sein, weil die ja eigentlich nur der FT232 weiß, dass sein Puffer voll ist.

[ogni42]

Funktioniert den CTS am FT232?

[lowtexx]

der uC erzeugt ein korrektes CTS Signal. Ob der FT232 dann auch anhält zu senden konnte ich noch nicht feststellen. Da gibt es noch ein Problem mit der uC-Firmware. Wenn viele Daten gesendet werden steigt der ganz aus. Daher auch die Notwendigkeit der Flusskontrolle.

[Amiwerewolf]

ich hab es schon gesehen das bei USB-RS232 wandlern die CTS, RTS, ... deaktiviert sind, oder auch treibermäßig nicht unterstüzt werden.
auch habe ich es erlebt das der Baustein das signal selbst generiert, wenn sein puffer voll ist

[lowtexx]

das bei USB-RS232 wandlern die CTS, RTS, ... deaktiviert sind, oder auch treibermäßig nicht unterstüzt werden.

Zu irgendwas müssen die Pins ja gut sein, sonst könnte FTDI die ja gleich weglassen. In ihrer Application Note werden die auch verwendet. Dort wird eine RS232-Schnittstelle dargestellt. Diese arbeitet dann mit einem MAX232. CTS und RTS sind jeweils durchgeschleift.


auch habe ich es erlebt das der Baustein das signal selbst generiert, wenn sein puffer voll ist
Genau so brauche ich das. Und so ist es wohl auch vorgesehen. Aber es funktioniert noch nicht. ](*,)

[Amiwerewolf]

soweit ich weiß ist der FTDI232 über ein 93Cxx EEPROM Configurierbar.
so lassen sich die funktionen der handshake pins, fifo, name of divice, etc. konfigurieren. Dieser befindet sich oft wegen seiner kompakten bauform auf usb/seriell wandlern, wo ich oft die erfahrung gemacht hab das nur Rxd und Txd funktionieren.