Hallo Forumgemeinde Ich suche jemanden, der Erfahrung mit dem FT232R von FTDI hat. Mein Problem: Ich kommuniziere über den FT232R mit einem anderen Chip an den ich Kommandos schicke (einfache Hex Werte), die dieser dann ausführen soll. Das funktioniert soweit eigentlich wunderbar! Aber es ist ein Kommando dabei (0xF0) das der FT232R einfach nicht durchlassen will!? Ist es möglich dass der FT232R selbst einige Kommandos kennt mit dem man diesen einstellen könnte? Das Datenblatt habe ich natürlich sorgfältig durchgelesen, aber zu diesem Kommando ist nirgends etwas beschrieben. Kann mir da jemand weiterhelfen? Gruss Pascal
Pascal Bazelli schrieb: > Hallo Forumgemeinde > > Ich suche jemanden, der Erfahrung mit dem FT232R von FTDI hat. > Mein Problem: Ich kommuniziere über den FT232R mit einem anderen Chip an > den ich Kommandos schicke (einfache Hex Werte), die dieser dann > ausführen soll. Das funktioniert soweit eigentlich wunderbar! Aber es > ist ein Kommando dabei (0xF0) das der FT232R einfach nicht durchlassen > will!? Ist es möglich dass der FT232R selbst einige Kommandos kennt mit > dem man diesen einstellen könnte? Das Datenblatt habe ich natürlich > sorgfältig durchgelesen, aber zu diesem Kommando ist nirgends etwas > beschrieben. > Kann mir da jemand weiterhelfen? > > Gruss > Pascal Der FT232R sollte eigentlich alles senden, was ihm gegeben wird. Konfiguriert wird er nicht per RS232 sondern über USB. Kommt überhaupt nichts durch oder wird es verstümmelt? Eventuell 7bit-Ausgewählt?
nein es kommt überhaupt nichts durch. allerdings nur bei diesem kommando. da der rest genauso durchkommt wie es gesendet wird, sollte der FT232R auch nicht auf 7bit eingestellt sein... ich kann mir das nicht erklären.
Dann sieh Dir mal das übertragene Bitmuster an. Und kontrolliere die Baudratenerzeugung in Deinem µC - was ist dessen Taktquelle? Ist die zu ungenau, kann es zu Abtastfehlern beim Empfangen auf der seriellen Schnittstelle kommen, und die dürften sich bei einer Bitfolge wie 0xF0 besonders stark zeigen.
rx und tx am ft232 verbinden, gucken ob alles zurückkommt was du schickst, son kannst du schon mal den ft testen
hmm der ft232 unterstützt software handshake. d.h. giebts zwei bitmuster die man dafür hernimmt aber kp ob das genau eins von denen ist.
Beim 245 muss man unter Linux "stty raw" auf das device, das ftdi_sio anlegt, anwenden, um "einfach alles" zu empfangen. vielleicht ist es hier aehnlich.
Nein, Softwarehandshake (XON/XOFF) ist nicht das Problem. Diese Steuercodes sind komplett andere (Ctrl+S == 0x13 für XOFF, Ctrl+Q == 0x11 für XON).
der vorschlag von rufus mit der baudrate scheint mir am wahrscheinlichsten. aber auch da hab ich meine zweifel, denn die kommunikation zwischen USB und FT232R sollte doch eigentlich nicht von der baudrate abhängig sein, die auf der sekundären seite an der RS232 schnittstelle eingestellt ist, oder? und auch dann sollte ich wenigstens ein signal (dann eben in der falschen baudrate) sehen?!?
> aber auch da hab ich meine zweifel, denn die kommunikation zwischen > USB und FT232R sollte doch eigentlich nicht von der baudrate > abhängig sein, die auf der sekundären seite an der RS232 > schnittstelle eingestellt ist, oder? Nein, das ist sie auch nicht. Aber die Kommunikation zwischen Deinem "anderen Chip" und dem FT232 ist davon abhängig. Wenn Dein "anderer Chip" mit einer fehlerhaften Baudrate (also einer, die ein paar Prozent zu hoch oder zu niedrig ist) sendet, dann kann der Empfänger im FT232 die Daten nicht mehr richtig erkennen. Und das spezifische Bitmuster 0xF0 kann dann durchaus auch komplett unter den Tisch fallen.
dass die baudrate zwischen FT232R und DS2480 ein rolle spielt ist mir soweit klar. die sache ist aber die: wenn ich das kommando 0xF0 an die USB schnittstelle schicke gibt diese diesen wert an den FT232R weiter. der FT232R wandelt das signal in RS232 um und gibt das dann raus (in einer bestimmten baudrate). auch wenn die baudrate nun für den DS2480 nicht die richtige ist, so sollte der FT232R auf der TxD leitung ein signal ausgeben. das passiert aber bei genau diesem kommando nicht! abgesehen davon muss die baudrate stimmen, denn alle anderen kommandos funktionieren einwandrei!
Danke Christian... das ist ein guter Hinweis! Den werd ich mir gleich mal anschauen!
Gut, aus Deiner Beschreibung wurde nicht klar, in welcher Richtung das Problem auftritt. > die sache ist aber die: wenn ich das kommando 0xF0 an die > USB schnittstelle schicke gibt diese diesen wert an den > FT232R weiter. der FT232R wandelt das signal in RS232 um > und gibt das dann raus (in einer bestimmten baudrate). > auch wenn die baudrate nun für den DS2480 nicht die richtige > ist, so sollte der FT232R auf der TxD leitung ein > signal ausgeben. das passiert aber bei genau diesem kommando nicht! Das hast Du mit einem Oszilloskop überprüft? Mit was für einem Programm steuerst Du auf dem PC die (virtuelle) serielle Schnittstelle an?
Tut mir leid wenn ich mich nicht verständlich ausgedrück hatte. Ja ich habe das Signal mit dem Oszilloskop überprüft. Die Software die den virtuellen COM-Port ansteuert habe ich selbst geschrieben.
Pascal Bazelli schrieb: > Ja ich habe das Signal mit dem Oszilloskop überprüft. Die Software die > den virtuellen COM-Port ansteuert habe ich selbst geschrieben. Dann öffne mal ein Hyperterminal und schicke damit 0xF0 ab. Ich bin mir sicher, dann siehst Du es auch. Peter
Dieser Test ist mit dem sogenannten "Terminalprogramm" von Tobi (hterm) einfacher durchzuführen, da das die hexadezimale Eingabe von zu sendenden Daten zulässt. Bei einem richtigen Terminalprogramm wie Hyperterminal dürfte das Eingeben des Zeichens ð auf der Tastatur nicht ganz einfach sein (das ist das ANSI-Zeichen mit dem Code 0xF0).
Rufus t. Firefly schrieb: > Bei einem richtigen Terminalprogramm wie Hyperterminal dürfte das > Eingeben des Zeichens ð auf der Tastatur nicht ganz einfach sein (das > ist das ANSI-Zeichen mit dem Code 0xF0). Danke, dass Du das Zeichen gepostet hast. Jetzt kann man es via Copy&Paste in Hyperterminal einfügen oder, falls man es momentan nicht benötigt, in einer Textdatei abspeichern. Im Ernst: Geht das nicht mit Alt-0240 ?
> Im Ernst: Geht das nicht mit Alt-0240 ?
Doch, natürlich geht das auch.
Vielen Dank für eure Vorschläge. Ich werde das morgen in Ruhe nochmals testen, heute werd ich wohl nicht mehr dazu kommen. Ich halte euch aber sicher auf dem laufenden!
Ich habe das Problem lösen können und möchte hier noch kurz die Lösung posten für alle, die auch auf dieses Problem gestossen sind: Und zwar geht es um den Handshake mit dem FT232R. Man muss darauf achten, dass beim öffnen des Ports die Einstellung für den Handshake auf Xoff eingestellt wird. Da beim COM-Port der Handshake entweder durch Hardware oder durch Software realisiert werden kann, muss man bei einer Lösung mit Hardware den softwaremässigen Handshake ausschalten. 0xF0 wird vom FT232R so interpretiert, dass hier die Nutzdaten enden... Gruss Pascal
Pascal schrieb: > 0xF0 > wird vom FT232R so interpretiert, dass hier die Nutzdaten enden... Nö, der FT232 ist unschuldig. Ihm ist das vollkommen wurscht, der überträgt alles. Die Auswertung des SW-Handshake geschieht erst im UART-Treiber, daher muß man auch dort einstellen, ob man SW-Handshake will oder nicht. Daß Du SW-Handshake aktiviert hast, wurde aber schon vermutet. Natürlich sind dann keine Binärdaten mehr übertragbar, da bestimmte Bytes für Sonderfunktionen reserviert sind. SW-Handshake benutzt man deshalb nur für Textübertragung. Peter
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.