Moin, Vielleicht wäre die Info im Markt besser aufgehoben - aber ich stell's mal hier rein. Am Wochenende habe ich mich mit einem Arduino Nano Klon herumgeschlagen. Die serielle Kommunikation über den FTDI Chip wollte einfach nicht funktionieren. Es kamen immer nur null character <00> am PC an (Windows7/64). Mit FTprog habe ich die Einstellungen des Chips geprüft - alles OK. In meiner Verzweiflung habe ich dann TX und Rx am FT232 hochgebogen und verbunden: Im Loopback kamen trotzdem nur Nullen an. Google brachte dann die Erleuchtung: http://axotron.se/blog/non-functional-arduinos-from-banggood-com/ Es sind offensichtlich gefälsche FTDI Chips auf dem Markt. Nach dem Tausch des FT232 funktioniert jetzt alles. Und dabei habe ich den Klon nicht direkt aus China, sondern aus Europa geordert. OK - ist wohl ein Chinese mit Lager in Deutschland. Also, wenn jemand Probleme mit FTDI Chips hat: Sie könnten gefälscht sein. Gruß Einhart ...und bevor die Arduino Diskussion losbricht: Ich benutze die Umgebung nicht - ich brauchte die Hardware ;-)
Angehängte Dateien:
-
FTDIcounterfeit.jpg
170 KB -
FTDIorig.jpg
120 KB
Das ist nichts Neues. Mir ist es schon mit einem USB-RS232 Kabel von Reichelt passiert, dass das nach einem Update des FTDI-Treibers nicht mehr lief. Da habe ich dann bei FTDI einen entsprechenden Hinweis gefunden. Eigentlich hätte ich Reichelt das Kabel um die Ohren hauen müssen, aber ich wahr zu faul die Rechnungen mehrerer Jahre durchzugehen, um eine Reklamation wegen ein paar Euro starten zu können. Mit freundlichen Grüßen Thorsten Ostermann
Ich kenne das ebenfalls von einem USB-RS232 Wandler. Der hat anfangs funktioniert. Manchmal ging er, manchmal nicht. Alles sehr unzuverlässig. Als ich ihn geöffnet habe konnte ich sehen, dass die Stützkondensatoren für die Ladungspumpen eingespart wurden. Dementsprechend sah der RS232 Pegel aus. Nach dem einlöten ging der Wandler schon besser. Aber auch dann hat er ab und zu noch Ärger gemacht. Ich denke mir wer an zwei 1µF Kondensatoren spart hat wahrscheinlich auch nicht den original FTDI Chip verbaut.
Dieses Thema hat mich jetzt 3 Wochen und 3 Tage sowie 10 untersuchte Exemplare gekostet. Bei 9k6 laufen die Teile in der Regel problemlos. Bei 38k4 nur noch in Sonderfällen. Eines davon sogar eine ganze Woche und dann war Schluss. In meinem Fall RS485 zum Anschluss von ABB Stromzählern. Die USB Treiber von FTDI merken gar nichts und die Enumeration funktioniert grundsätzlich tadellos. Der Datenstrom der dann kommt ist aber Schrott und die Probleme liegen immer auf der seriellen Seite. Die Chips sind im Übrigen abgeschliffen oder waren gar nie bedruckt. Sie sind noch immer im Handel und werden für den Raspi beworben. Die Fehlersucher ist aber definitiv nichts für Anfänger oder gar als Lehrspielzeug: Eine Charge gekauft bei Reichelt: https://www.reichelt.de/haus-und-sicherheitstechnik-c2712.html der Rest der Exemplare wurde vom Chinesen selbst verkauft: https://eckstein-shop.de/QITAUSBRS485KonverterBusAdapterSeriellSchnittstelleRaspberryPi Die deutsche Geiz ist Geil Mentalität ist halt genauso hohl wie die Unverfrorenheit der Chinesen.
:
Bearbeitet durch User
>>> Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt. >> Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt. J. V. schrieb: > Dieses Thema hat mich jetzt 3 Wochen und 3 Tage sowie 10 untersuchte > Exemplare gekostet. Schön, dass Du das nach 10 Jahren auch schon mitbekommen hast. > Die deutsche Geiz ist Geil Mentalität ist halt genauso hohl wie die > Unverfrorenheit der Chinesen. Schwachsinniges Eigentor: Du hättest gerne über zuverlässige Kanäle anstatt beim Chinavertreiber kaufen können.
Angehängte Dateien:
-
dscf6686.jpg
220 KB
Reichelt sollte das nach 10 Jahren mal mitkriegen und nicht immer noch so einen Schrott verkaufen. Auf dem Foto die Adresse des Berliner Importeuers. Hier der korrekte Link: https://www.reichelt.de/raspberry-pi-usb-rs485-schnittstelle-ch340c-rpi-usb-rs485-p242783.html
:
Bearbeitet durch User
J. V. schrieb: > Reichelt sollte was hat "Gefälschte FT232RL" mit CH340C zu tun?
:
Bearbeitet durch User
J. V. schrieb: > Reichelt sollte das nach 10 Jahren mal mitkriegen und nicht immer noch > so einen Schrott verkaufen. Auf dem Foto die Adresse des Berliner > Importeuers. Hier der korrekte Link: > > https://www.reichelt.de/raspberry-pi-usb-rs485-schnittstelle-ch340c-rpi-usb-rs485-p242783.html Hier geht es nicht um FT232, wie im ursprünglichen Faden, sondern um ch340/ch341. Außerdem ist das wohl, wie auch beim PL2303 ein Windows-only Problem. Reichelt bietet das Modul als Zubehör für den RasPi an, auf dem läuft üblicherweise Linux, damit funktionieren auch die Billigchips üblicherweise zuverlässig.
Angehängte Dateien:
-
DSCF6705.JPG
200 KB
Es hat damit zu tun, daß es ein mutmasslich gefälschter FTDI Chip ist, welcher den ganzen Ärger macht. Außerdem werden die FTDI Treiber bei fremden Chips vermutlich abseits ihrer Lizenzen betrieben und der Hersteller wird auch keine Rechte haben den Chip mit dem FTDI Logo zu markieren bzw. deren VID / PID zu benutzen. Ob es nun ein FT232 oder irgend ein anderes nachgebautes Modell ist bleibt egal. Es ist auch kein Windows only Problem wie bei Prolific. Ich habe zwar auch unter Windows probiert und zufällig auch unter Ubuntu. Mein Hauptbetriebssystem war in diesem Fall aber Linux. Um ganz genau zu sein war es Venus OS in den Versionen 3.0.0 und 3.0.1 und das läuft sehr wohl auch auf einem Raspi. https://github.com/victronenergy/venus Das oben abgebildete USB Kabel ist das von Reichelt. Es wurde dort letztes Jahr gekauft. Ob das aktuell angebotene Kabel noch aus der identischen Charge ist, weis ich natürlich nicht. Hier noch das Foto der Platine zur Identifikation.
:
Bearbeitet durch User
Das geht ja noch, bei mir lag der Chip CH340 lose im Grhäuse und beim Ersatz war kein Quarz drin.
Ja, Quarz ist bei mir auch nicht bestückt. Zwei Dinge sind noch bemerkenswert: Reichelt schreibt im Artikel, daß das Kabel funktionieren soll und sie es selbst an einem Raspi ausprobiert haben. Offensichtlich hat es also schon häufiger Reklamationen gegeben bis sowas in die Artikelbeschreibung kommt. Es gibt natürlich schon Fälle wo mit dem Teil irgendwas funktioniert. Bei mir hängt aber die gesamte Stromversorgung vom Gebäude dran. Der SW Regler der daran läuft, liest die Modbus RTU Daten des Stromzählers aus um eine Nulleinspeisung auszuregeln. Im aufgezeichneten 24 Stunden Betrieb fallen da natürlich alle Unregelmässigkeiten sofort auf. Natürlich kann man behaupten daß der Raspi nur ein Lehrspielzeug ist aber gerade da hat es problemlos zu funktionieren. Es ist auch komisch, daß andere vergleichbare USB Kabel (ebenfalls mit FTDI) um vielleicht 10 Euro in der gleichen Situation und der gleichen Hardware problemlos funktionieren.
:
Bearbeitet durch User
Ingo W. schrieb: > Hier geht es nicht um FT232, wie im ursprünglichen Faden, sondern um > ch340/ch341. Dann mach dafür einen neuen Thread auf. Dieser (alte) Thread hier heißt "Gefälschte FT232RL" J. V. schrieb: > Das oben abgebildete USB Kabel ist das von Reichelt. Was auch immer das zeigt, einen FT232 zeigt es nicht. Zu sehen ist ein Chip im SO-16-Gehäuse, keine Variante des FT232 wurde jemals in diesem Gehäuse hergestellt. Der FT232RL hat 28 Pins. Welche VID/PID rückt denn der Chip auf dieser Platine raus? (Die kann Dir der Gerätemanager anzeigen)
Wenn man sich das Foto genau anschaut, kann man tatsächlich die Aufschrift "FTDI" erkennen, was natürlich bedenklich ist, weil FTDI keine ICs mit dieser Gehäuseform herstellt. Die Anschlussbelegung (soweit man diese erkennen kann) entspricht der eines CH340B oder CH340C. Lt. Reichelt ist es ein CH340C, was dann wohl stimmen wird. Wenn die RS-485-Kommunikation mit dem ABB-Zähler Probleme macht, muss die Ursache dafür nicht unbedingt in einem gefälschten IC liegen. Es kann genauso gut ein Problem in der Verkabelung oder ein Fehler in der Anwendungssoftware sein. Verkabelung: RS-485 arbeitet zwar differentiell, dennoch dürfen die absoluten Pegel an den A- und B-Leitungen bezogen auf das jeweilige Bezugspotential gewisse Grenzen nicht überschreiten. Im Foto mit dem Zähler ist der GND-Anschluss (C) unbelegt. Damit ist nicht unbedingt sichergestellt, dass die Differenz zwischen den Bezugspotentialen von Zähler und USB-RS-485-Interface innerhalb der Toleranz liegt. Auch eine nur kurzzeitige Überschreitung der Toleranz, bspw. durch Störspitzen, kann zu Problemen führen. Wenn die Kommunikation mit einem anderen USB-RS-485-Interface besser funktioniert, kann dies daran liegen, dass der verwendete RS-485-Treiber toleranter ist. Software: Einer der kritischen Punkte bei der RS-485-Kommunikation ist das korrekte Timing beim Umschalten von Senden auf Empfangen. Einerseits darf die Umschaltung erst erfolgen, wenn das letzte gesendete Bit die Schnittstelle verlassen hat, andererseits muss die Umschaltung schnell genug erfolgen, um beim Empfang keine Daten zu verpassen. Ist man sich dieser (eigentlich trivialer) Punkte nicht bewusst, kann das zu Übertragungsfehlern führen. Wenn die Kommunikation mit einem anderen USB-RS-485-Interface besser funktioniert, kann dies daran liegen, dass das interne Timing in diesem Interface ein anderes ist und damit den Softwarefehler kaschiert.
Einhart P. schrieb: > In meiner Verzweiflung habe ich dann TX und Rx am FT232 hochgebogen und > verbunden Man kann sie auch einfach außen an der Stiftleiste (D0, D1) brücken und den AVR mittels Dauer-Reset still legen.
dein problem mit dem usb-rs485 suchst du besser bei der terminierung/bias auf dem bus sowie der tx/rx umschaltung. der arme USB Uart chip macht sicher nichts falsch.
übrigens sendet der aktuelle ftdi windowstreiber so etwas wie 'warning counterfit part' und nicht mehr 0x00 0x00
Yalu X. schrieb: > Einer der kritischen Punkte bei der RS-485-Kommunikation ist das > korrekte Timing beim Umschalten von Senden auf Empfangen. Warum der Adapter dann keinen CH340T, -R oder -B verwendet, verstehe ich nicht, denn diese besitzen das Signal "TNOW" (CH340T/E/B: Ongoing data transmission status indicator, active high), zu welchem der Hersteller schreibt: "The TNOW pin can be used to control DE (high active send enable) and RE# (low active receive enable) pin of RS485 transceiver." Der CH340B kann auch programmiert werden, so dass jede Anwendung eine eigene Seriennummer, Produktbeschreibung oder gar Product- und/oder Vendor-ID erhalten kann. Damit hat dann das Ratespiel des zugehörigen Devices ein Ende (zumindest unter Linux :-). Wie der CH340B unter Verwendung der libUSB programmiert werden kann, habe ich hier beschrieben: https://www.dr-bosch.com/volker/reparatur/index.html#CH340B Grüßle, Volker
Angehängte Dateien:
-
ftdi1.JPG
110 KB
Der Chip war mal mit FTDI gestempelt. Das Logo ist schlampig abgeschliffen und FTDI stellt kein einziges IC im SO16 Gehäuse her. Der FT220 ist im SSOP16 was deutlich kleiner ist. Vermutlich haben die Teile riesen Ärger gemacht und deshalb wurden sie abgeschliffen und jetzt als CH340 verkauft. Tatsächlich kann man den WCH Treiber unter W10 laden. >dein problem mit dem usb-rs485 suchst du besser bei der >terminierung/bias auf dem bus sowie der tx/rx umschaltung. der arme USB >Uart chip macht sicher nichts falsch. Nein, ich habe terminiert und auf dem Foto der Leiterplatte siehst du auch den zusätzlichen GND den ich angelötet habe weil der nicht rausgeführt ist.
:
Bearbeitet durch User
J. V. schrieb: > Vermutlich haben die Teile > riesen Ärger gemacht und deshalb wurden sie abgeschliffen und jetzt als > CH340 verkauft. Tatsächlich kann man den WCH Treiber unter W10 laden. Wenn sich eine Device mit VID0403 meldet, wird Windows keinen WCH-Treiber akzeptieren, WCH hat 1A86. Dann ist da noch etwas mit VID0781 zu sehen, die gehört SanDisk für USB-Speicher. Du weisst nicht, was Du tust und Dein Screenshot gibt keinen Sinn.
J. V. schrieb: > Vermutlich haben die Teile > riesen Ärger gemacht und deshalb wurden sie abgeschliffen und jetzt als > CH340 verkauft. Tatsächlich kann man den WCH Treiber unter W10 laden. Vielleicht handelt es sich doch um den CH340B, da bei diesem Vendor- und Product-ID beliebig umprogrammiert werden können. Das Indiz, dass der der IC ohne Quarz arbeitet, spricht schon einmal dafür. Du könntest mit den einschlägigen Programmiertools versuchen die IDs auf die Default-Werte des CH340B zurückzusetzen (gem. Datenblatt: VID 1A86H, PID 7523H), damit der WCH-Treiber wieder den CH340 erkennt (und hoffen, dass der Fälscher das Schreibschutzbyte nicht aktiviert hat). Die ersten beiden URLs führen zur originalen Windosen Software des Herstellers, die dritte zu einem Freeware-Programm, ebenfalls für Mikey$oft: http://www.wch-ic.com/downloads/CH34xSerCfg_ZIP.html https://www.shotech.de/de/ch340b.html https://github.com/senthilnathant/tools-ch340b-configuration Viel Erfolg! Volker
Thread beobachten
Seitenaufteilung abschaltenBitte 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.