Hallo, weiß einer von Euch, wo FTDI im Datenblatt auf die Eigenheiten des _CTS eingeht? Auf der FTDI Website http://www.ftdichip.com/Support/FAQs.htm#HwGen3 steht etwas von "If CTS# is logic 1 it is indicating the external device cannot accept motre data. the FTxxx will stop transmitting within 0~3 characters, depending on what is in the buffer." Ich bin nun auf der Suche, wo das im Datenblatt genauer erklärt ist. Bzw. für welche Chips das denn nun alles gilt. Außerdem frage ich mich (siehe auch Beitrag "CTS# delay") was Flußkontrolle in Hardware bringt. Die PIC24/32 Mikrocontroller besitzen einen 4 Byte FIFO an der RX Leitung. Der dazugehöringe _RTS Eingang (_CTS FT232RL) geht auf Hi, wenn der FIFO randvoll ist. Wie paßt das zusammen?
Be Bo schrieb: > If CTS# is logic 1 it is indicating the external device > cannot accept motre data. >Der dazugehöringe _RTS Eingang (_CTS FT232RL) geht >auf Hi, wenn der FIFO randvoll ist. Wie paßt das zusammen? Auf Hardware-Ebene heißt eine High-gezogene /RTS-Leitung, daß nichts mehr gesendet werden darf. Der FT232R stoppt dann auch den USB-Transfer, was aber systembedingt nicht sofort passiert und deswegen muß er noch 0...3 Bytes ausgeben. Du mußt Dein /RTS also manuell generieren bevor der FIFO rammelvoll ist. Worst case mußt Du noch 3 Bytes hineinbekommen, ohne daß Du Daten verlierst.
Das ist mir schon klar, nur würde ich erwarten, daß so ein Verhalten im Datenblatt spezifiziert ist und nicht in einer Randbemerkung auf der Website. Die PIC Controller reagieren auf eine 1 an _CTS übrigens mit einem sofortigen Stop der Übertragung nach dem das aktuell übertragene Byte fertig ist. Frage mich, wieso anderer Hersteller das nicht machen.
Weil USB sich nicht einfach stoppen läßt. Im Transfer befindliche Bytes werden eben noch ´rausgeschickt.
Das hat ja nichts mit USB zu tun. Der FT232 hat ja auch einen internen Buffer, in dem er die Daten vom USB zwischenspeichert, bevor sie über den UART ausgegeben werden.
Nein, geht auch garnicht, da USB Daten in Blöcken überträgt, die nach dem Empfangen byteweise über den UART ausgegeben werden. Also ist eine Pufferung unumgänglich.
Solche Operationsmodi sollte man vermeiden. Ein voller Buffer bedeutet, die CPU ist schon am Anschlag und kann kaum mehr verarbeiten. Ein Hardware Handshake braucht auch wieder Code und Ausfuehrungszeit. Das ist nicht gut. Dagegen gibt es zwei Moeglichkeiten : Eine schnellere CPU oder eine tiefere Baudrate. Das Protokoll hat auch noch was zu sagen. Ein Master Slave Protokol wird ein Device nicht ueberfluten. Wenn man aber ein Modem, oder einen Router bauen will sieht's anders aus.
Bitte 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.