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?
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.
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.
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 .
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
Nur Jeff
talsit
sternenblau
sternenblau
talsit