Gibt es etwas Besonderes, das ich über RS232 und FT232R wissen muss?

Ich versuche, eine XSens-IMU mit meinem Computer zu verbinden, und ich stoße auf interessante Schwierigkeiten. Die IMU hat einen RS232-Anschluss, der nur die Pins VCC, GND, TX, RX verwendet, sonst nichts. Das mitgelieferte SDK hat einen benutzerdefinierten RS232-USB-Adapter, der den FT232R und MAX3160 verwendet, aber abgesehen davon scheint es nichts Besonderes zu tun.

Der Hersteller behauptet, dass die IMU Standard-RS232 verwendet (und ich habe keinen Grund, daran zu zweifeln), also versuche ich, um Platz zu sparen (ihr Konverter ist ziemlich sperrig), einen Sparkfun FTDI Basic Breakout 5V zu verwenden .

Wenn ich alle COM-Einstellungen gleich einstelle (Baudrate, Parität, Stopp usw.) und mich mit dem Gerät verbinde, bekomme ich zwar Daten zurück, aber es scheint nur Kauderwelsch zu sein. Ich gebe Befehle aus, die TX-LED am FTDI blinkt, die RX-LED auch, und ich bekomme Daten, aber es ist nicht das, was ich erwarte.

Kann mir jemand irgendwelche "Fallstricke" einfallen lassen, die ich vielleicht übersehe? Gibt es eine FooBar, die zum Betätigen mit dem DingDing verbunden werden muss?

Wie sind die Porteinstellungen und woran hast du es bisher angeschlossen? War das ein PC, an den du ihn angeschlossen hast? Ist dies das 921600-bps-Gerät in Ihrer anderen Frage?
Ich habe das Gerät und den VCOM-Port auf 115200, 8 Bit, keine Parität, 2 Stoppbits, kein xonxoff, keine rtscts, kein dsrdtr eingestellt. Ja, es ist das Gerät in meiner anderen Frage. Im Moment werde ich einen PC verwenden, möchte aber später das ganze System in eine Box packen.
VCC ist kein Standard-RS232.
2 Stoppbits sind ungewöhnlich, der Standardwert ist normalerweise ein Stoppbit.
Ich akzeptiere 5-30 V als VCC, und es werden 2 Stoppbits verwendet. Ich habe jedoch sowohl 1 als auch 2 Stoppbits ausprobiert.

Antworten (5)

Standard-RS-232 (wie Ihre IMU) und TTL-Pegel-RS-232 (wie der FTDI-Chip) sind unterschiedlich.

Standard-RS-232 schaltet zwischen +V und -V um (wobei V ursprünglich 12 war, aber jetzt funktionieren die meisten Geräte mit viel niedrigeren Spannungen). TTL-Pegel RS-232 schaltet zwischen 0 und 5 V um. Sie benötigen einen RS-232-Transceiver, um die Spannungen umzuwandeln, z. B. diesen MAX3160-Chip (obwohl das ungewöhnlich ist - so etwas wie der max2332 ist häufiger).

Die USB-zu-TTL-Pegel-RS-232-Konverter wie der, mit dem Sie verbunden sind, werden verwendet, um eine Verbindung zu einem Mikrocontroller herzustellen, nicht zu einem typischen RS-232-Gerät.

Ich denke, das klingt nach dem, was ich falsch mache. Ich bräuchte so einen Transceiver. Ich glaube, sie haben sich für den MAX3160 entschieden, weil er bis zu 1 MBit/s leistet. Weiß jemand, wo ich ein einzelnes Board bekommen kann, das an einem Ende USB und am anderen Ende "echtes" RS232 / EIA-232 ausführen kann? Und in der Lage sein, Geschwindigkeiten von bis zu 921600 zu erreichen?

Sind Sie sicher, dass die Spannungspegel kompatibel sind?

Standard-RS232 hat ±12-V-Pegel, die normalerweise von einigen MAX-Chips in TTL-Pegel umgewandelt werden.

In Ihrem Fall hat das Sparkfun FTDI-Breakout-Board TTL-Pegel (0/5 V), während der MAX3160 RS232 und RS485 (!) ausführen kann, sodass eine Diskrepanz vorliegt.

Ich werde es noch einmal versuchen, aber nach dem Lesen der Spezifikationen akzeptiert der xsens 5-30 V!
Ja, aber was wird ausgegeben ?
Beachten Sie auch, dass die Polarität zwischen RS232 und TTL invertiert ist.

Wenn Sie sich die technischen Daten einiger Geräte auf dieser Website ansehen, wird die digitale Schnittstelle mit „max während Sie versuchen, mit ein paar anderen Baudraten zu sprechen, insbesondere wenn Sie eine gute Vorstellung davon haben, wie die Daten aussehen sollen. Ich würde mein Terminal auf 115200 einstellen und sehen, ob die Daten bei dieser Rate sinnvoll sind, und dann die Baudratenskala herunterarbeiten. Wenn Sie 9600 erreichen und es immer noch wie Kauderwelsch aussieht, gehen Sie zurück zu 115200 und arbeiten Sie sich hoch.

Eine Rate von 921600 ist fast unbekannt. Es ist ein Standard-Multiple, aber ich habe ehrlich gesagt noch nie etwas gesehen, das RS232 schneller als 115200 pusht. Wenn es notwendig wird, schnellere Raten als 115200 zu verwenden, wechseln Designer normalerweise zu einer anderen, zuverlässigeren Schnittstelle.

Übrigens gehe ich immer noch davon aus, dass Sie das Gerät an einen PC-COM-Anschluss angeschlossen haben und über eine Dokumentation verfügen, die das Datenformat vorschlägt. Wenn Sie eine Baudrate auswählen können, verwenden Sie 115200. Dies ist viel zuverlässiger, vorausgesetzt, es ist mit Ihren allgemeinen Datenratenanforderungen kompatibel .

Ja, ich habe die meisten mir zur Verfügung stehenden Baudraten ausprobiert. Ich habe alle Stopbit-, Bytesize- und Buadrate-Kombinationen ausprobiert. Ich sende über das serielle Kabel etwa 44 kB/s durch. Versuchsweise habe ich jedoch versucht, die Datenrate vom Gerät auf 8,4kB/s und die Baudrate auf 115200 zu reduzieren. Mit deren USB-Serial funktioniert alles, mit dem FTDI bekomme ich das gleiche Kauderwelsch wie zuvor. Ich kann das Gerät auf eine Vielzahl von Baudraten, Abtastraten usw. konfigurieren, aber ich hatte kein Glück mit dem FTDI :( Aber danke!
Ich bin einmal auf eine Situation gestoßen, in der ein USB/FTDI-basierter Port, der 115.2k-fähig sein sollte, mit einem bestimmten Gerät nicht mit dieser Geschwindigkeit abgespielt werden konnte. In diesem Fall funktionierte das Gerät einwandfrei, wenn es an einen „echten“ COM-Port angeschlossen war, der in den Computer eingebaut war, und der FTDI-basierte Port funktionierte mit anderen Geräten bei 115,2; aber FTDI und dieses eine Gerät waren nur eine pathologische Kombination von Schnittstellenchips.
Just Jeff, ich habe eine ähnliche Situation mit einem Peripheriegerät, das wir in unsere Produkte einbetten. Es funktioniert gut mit der seriellen Schnittstelle eines Computers, aber nicht mit einem PIC. Es stellt sich heraus, dass die Baudrate etwas abweicht. Anscheinend sind "echte" serielle Ports nachsichtiger als Mikrocontroller. Glücklicherweise kann der PIC mit nicht standardmäßigen Baudraten betrieben werden.
@Jeanne Pindar: Ja, das ist mir auch schon passiert. Sie erhalten ein Gerät, das ein wenig langsam ist, ein anderes, das ein wenig schnell ist, und die meisten Dinge spielen mit den meisten anderen Dingen zusammen. Aber hin und wieder stellen Sie fest, dass, obwohl A mit B und B mit C spricht, Sie A und C einfach nicht zum Reden bringen können, und das O-Scope kommt heraus.

Ein Ärgernis, das ich mit FTDI-Chips hatte, das wahrscheinlich nicht die Ursache Ihrer Probleme ist, aber möglicherweise sein könnte, ist, dass, wenn das Remote-Gerät sendet, was das FTDI als "lange Pause" wahrnimmt, das FTDI Informationen verwirft, die es hat vom entfernten Gerät empfangen, aber noch nicht an den PC weitergeleitet. Dies kann auf zwei Arten zu Problemen führen:

  • Einige eingebettete Geräte sind im Leerlauf mit niedrigem seriellen Ausgang; Wenn sie etwas zu sagen haben, schalten sie ihren seriellen Ausgang ein, senden einige Daten und gehen dann zurück in den Leerlauf, sobald sie es gesagt haben. Wenn das eingebettete Gerät etwas speist, das schlafen gehen kann, wenn sein serieller Eingang für einen längeren Zeitraum niedrig ist, und aufwachen kann, wenn es hoch geht, kann diese Funktion ein effektives Mittel zur Wecksignalisierung darstellen, ohne dass ein zusätzlicher Pin erforderlich ist. Leider kann das Abschalten des seriellen Anschlusses des Remote-Geräts dazu führen, dass der FTDI den letzten Teil der vom Gerät gesendeten Daten verwirft (ich habe es mit einem Oszilloskop überprüft - die Daten wurden gesendet, bevor die Leitung tot war, aber der FTDI fiel aus es sowieso).

  • Wenn ein typischer UART verwendet wird, der auf eine schnellere Baudrate eingestellt ist als das Gerät, an das er angeschlossen ist, erhält man im Allgemeinen Datenmüll, der eine identifizierbare Teilmenge möglicher Bytewerte enthält. Wenn man beispielsweise auf 38.400 konfiguriert ist und das Remote-Gerät auf 9600 eingestellt ist, erhält man richtig gerahmte Bytewerte und 80, F8 und falsch gerahmte Bytewerte 00 und 78. Das Empfangen vieler dieser bestimmten Bytewerte kann machen es ist einfach, das Problem zu identifizieren. Unglücklicherweise neigt der FTDI jedes Mal, wenn er eine falsch gerahmte 00 sieht, dazu, die ihm vorangehenden Daten zu verwerfen. Folglich kann man am Ende nichts sehen, anstatt leicht identifizierbare Mülldaten zu sehen.

Unter anderem aus diesem Grund habe ich eine Art Hassliebe zu den FTDI-Chips. Ich benutze sie, und sie sind in vielerlei Hinsicht recht praktisch, aber sie sind kein so einfacher Drop-in-Ersatz für einen UART, wie man es sich wünschen könnte.

Wenn Sie deren Software verwenden, achten Sie darauf, die VID/PID Ihres FTDI so zu ändern, dass sie mit deren übereinstimmt. Andernfalls erkennt ihre Software Ihren benutzerdefinierten seriellen Konverter nicht