Forum: Mikrocontroller und Digitale Elektronik FT232R (USB zu seriell) lässt nicht alles durch


von Pascal B. (pbazelli)


Lesenswert?

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

von Christian H. (netzwanze) Benutzerseite


Lesenswert?

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?

von Pascal B. (pbazelli)


Lesenswert?

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.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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.

von ... .. (docean) Benutzerseite


Lesenswert?

rx und tx am ft232 verbinden, gucken ob alles zurückkommt was du 
schickst, son kannst du schon mal den ft testen

von Kr2 K. (kr2)


Lesenswert?

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.

von faustian (Gast)


Lesenswert?

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.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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).

von Pascal B. (pbazelli)


Lesenswert?

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?!?

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

> 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.

von Pascal B. (pbazelli)


Lesenswert?

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!

von Christian H. (netzwanze) Benutzerseite


Lesenswert?

DS2490 verwenden. Das ist ein USB auf 1-Wire Master.
Da brauchst Du keinen FT232 dazwischen.

von Pascal B. (pbazelli)


Lesenswert?

Danke Christian... das ist ein guter Hinweis! Den werd ich mir gleich 
mal anschauen!

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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?

von Pascal B. (pbazelli)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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).

von Severino R. (severino)


Lesenswert?

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 ?

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

> Im Ernst: Geht das nicht mit Alt-0240 ?

Doch, natürlich geht das auch.

von Pascal B. (pbazelli)


Lesenswert?

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!

von Pascal (Gast)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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
Noch kein Account? Hier anmelden.