Hallo, ich möchte einen kleinen USB-Seriell-Wandler bauen. Die billigen Teile beinhalten meist einen PL2303. Der wird aber nicht von WIN10 unterstützt. Mit alten Treiber geht es, aber wer weiß wie lange noch. VUSB schafft glaube nur 4800 Baud. Auf meiner Suche bin ich auf den MCP2200 gestoßen. Der ist leicht beschaffbar und die Beschaltung ist gering. Desweiteren habe ich den CH330 gefunden. Schön klein und hat nur die Anschlüsse RxD und TxD. Genau die, die ich brauche. Wie sind Eure Meinungen zu den Schaltkreisen? Hab etwas wichtiges übersehen? Was muß man beachten? Viele Grüße Schorsch
Eine schöne vergleichende Übersichtstabelle verschiedener USB-UART ICs wäre mal was. Die CP2102 und FT232R (kann bis 3 MBaud) fehlen noch.
Wenn Du nur Rx/Tx brauchst, wäre da noch der MCP2221A. Der braucht auch keinen Quarz, und er kann auch I2C, was oft extrem nützlich ist, wenn man irgendwas kleines anschließen will. fchk
Such mal nach FT232XS, das ist ein geschrumpfter FT232, hat wirklich nur das nötigste drin.
Hmm, warum kauft Du Dir nicht die Dinger mit dem CH340 aus der Bucht? Die kosten ja fast weniger als die einzelnen Chips. Mit ca. 1.5-2€ bist Du dabei.
CH340 ist auch auf den weit verbreiteten Arduino-Nano Clones drauf. Die Treiberunterstützung sollte also so bald nicht eingestellt werden.
Der große Vorteil der Microchip MCP2200 und MCP2221A ist, dass man eben keine Treiberunterstützung vom Chiphersteller braucht. Diese Chips implementieren nämlich nur die USB-Standardklassen HID und CDC-ACM, und die sind in den ganzen USB-Stacks schon drin. Ok, Microsoft halt da mal wieder etwas länger gebraucht, aber mit Windows 10 braucht man auch kein .inf mehr, sondern kann das Teil einfach so ohne Treiberinstallation einfach anstecken wie bei Mac, Linux, OpenBSD etc auch. fchk
Frank K. schrieb: > USB-Standardklassen HID und CDC-ACM Interessant! Hatte so einen Vogel noch nicht auf dem Tisch, irgendwelche Nachteile bzgl. Datenrate, Latenz, einzelne Bytes verschlucken, Kompatibilität in den Programmen?
Harald schrieb: > Frank K. schrieb: >> USB-Standardklassen HID und CDC-ACM > > Interessant! Hatte so einen Vogel noch nicht auf dem Tisch, irgendwelche > Nachteile bzgl. Datenrate, Latenz, einzelne Bytes verschlucken, > Kompatibilität in den Programmen? Unter Windows ist das auch nur ein COMx, unter Linux ein /dev/ttyACMx statt /dev/ttyUSBx, die ganzen Modemsteuerleitungen (DSR/DTR/DCD/RI) gibts da nicht, aber bis 115k läuft alles ganz normal, und mehr brauche ich nicht und habe ich nie probiert. Einige Arduinos nutzen einen Mega16u2 als USB-UART, und der spricht auch CDC-ACM. Wahrscheinlich war der 16u2 billiger als ein FTDI-UART gewesen. fchk
Frank K. schrieb: > Wahrscheinlich war der 16u2 billiger als ein FTDI-UART gewesen. Diese FTDI-Dinger sind aber proprietär, implementieren kein CDC und deren Support rückt keine Protokollbeschreibung raus. Außerdem sind die teuer. Wenn man einen USB-Host implementieret also unbrauchbar. Ich empfehle die MCP oder implementiere CDC einfach selbst, Microcontroller mit USB sind heute nicht teurer als welche ohne.
Leider haben die CDC Varianten unter Linux gleich zwei Hasenfüße: a) Der Modemmanager (der zumindest bei Ubuntu und Debian standardmäßig installiert ist) hält das Device für ein Modem und versucht es beim Einbstecken mit AT Befehlen zu initialisieren. b) Der Kerne hält das Device für eine Konsole und sendet empfangene Zeichen als Echo zurück. Das passiert so lange, bis man das entweder mit dem stty Befehl abstellt oder den Port mit einem Anwendungsprogramm öffnet. Wenn man das weiß, kann man sich darauf einstellen.
Stefan ⛄ F. schrieb: > Leider haben die CDC Varianten unter Linux gleich zwei Hasenfüße: Macht HID auch Probleme bei Linux?
Michael schrieb: > Macht HID auch Probleme bei Linux? Die kannst du nicht für serielle Kommunikation verwenden, jedenfalls nicht ohne spezielle Treiber. HID ist eigentlich für Tastaturen und Mäuse gedacht.
Stefan ⛄ F. schrieb: > Die kannst du nicht für serielle Kommunikation verwenden, jedenfalls > nicht ohne spezielle Treiber. HID ist eigentlich für Tastaturen und > Mäuse gedacht. Unter Windows kannst du einfach mit einem File Handle darauf zugreifen und beliebige Daten bidirektional senden. Kein spezieller Treiber erforderlich. Was wäre denn aus deiner Sicht die beste Wahl für Linux wenn sowohl CDC als auch HID nicht praktikabel sind?
Danke für Eure Antworten. Den MCP2221 kannte ich noch nicht. Den gibt es auch als THT, daß finde ich interessant. SMD ist doch manchmal ganz schön klein. Mein 1.62€ Teil aus der Bucht entpuppte sich dann als PL2303 und lief nicht standartmäßig unter Win10. Mit alten Treiber geht das schon, aber das will ich nicht. Gruß Schorsch
Michael schrieb: > Was wäre denn aus deiner Sicht die beste Wahl für Linux wenn sowohl CDC > als auch HID nicht praktikabel sind? Die Frage ist falsch formuliert. Ich würde CDC nehmen, weil es praktikabel ist. Man muss sich halt nur auf die Eigenarten einstellen, das kann man in Software alles berücksichtigen.
Die FTDI USB to UART, FT232 und verwandte, sind explizit nur Uarts, die Treiber sind Bestandteil von Windows. Ich verwende immer diese. Der Preis ist mir eigentlich egal, ich fertige keine hohen Stueckzahlen. Wie lange kannst du mit software und Konfigurationen rummachen, um bei zB 100 Stueck die Ersparnis zu verblasen ?
Michael schrieb: > Was wäre denn aus deiner Sicht die beste Wahl für Linux wenn sowohl CDC > als auch HID nicht praktikabel sind? Ich verwendet die Microchip-Teile auch unter Linux, sowohl PC als auch ARM und MIPS. Ja, den Modemmanager muss man zügeln, entweder deinstallieren oder per udev-Regel per USB-Device ID abklemmen:
1 | ATTRS{idVendor}=="04d8" ATTRS{idProduct}=="00df", ENV{ID_MM_DEVICE_IGNORE}="1"
|
Das ist überhaupt kein Problem. Muss man wissen, dann geht das. Läuft ansonsten ohne Probleme und ist sehr wohl praktikabel, und zwar unter allem Architekturen. HID wird bei den Bausteinen nur für die GPIOs, I2C und die Konfiguration verwendet. UART läuft immer und grundsätzlich über CDC-ACM. fchk
Frank K. schrieb: > HID wird bei den Bausteinen nur für die GPIOs, I2C und die Konfiguration > verwendet. UART läuft immer und grundsätzlich über CDC-ACM. Ich meinte das mit HID eher allgemein. Ist HID unter Linux problematisch? (Dass der MCP das nicht kann für die UART kann, blenden wir jetzt Mal aus.)
Michael schrieb: > Ich meinte das mit HID eher allgemein. Ist HID unter Linux > problematisch? Wohl kaum, ich arbeite seit vielen Jahren an einer HID Tastatur und Maus. Kann mich nicht daran erinnern, dass die jemals nicht funktioniert haben - außer wenn die Batterie (der Funkmaus) leer wurde.
Michael schrieb: > Frank K. schrieb: >> HID wird bei den Bausteinen nur für die GPIOs, I2C und die Konfiguration >> verwendet. UART läuft immer und grundsätzlich über CDC-ACM. > > Ich meinte das mit HID eher allgemein. Ist HID unter Linux > problematisch? (Dass der MCP das nicht kann für die UART kann, blenden > wir jetzt Mal aus.) Nein. Die ganzen USB-Standardklassen funktionieren eher besser als bei Windows. Vor allem sowas wie CDC-EEP oder CDC-ECM, wo Microsoft unbedingt sein RNDIS reindrücken musste. Auch USB 2.0 Audio war sehr lange ein Trauerspiel, bis sie endlich einen Treiber eingekauft haben von jemandem, der das besser konnte. fchk
Schorsch schrieb: > Danke für Eure Antworten. > Den MCP2221 kannte ich noch nicht. Den gibt es auch als THT, daß finde > ich interessant. SMD ist doch manchmal ganz schön klein. Vorsicht. Du willst den neueren MCP2221A haben, nicht den älteren MCP2221 ohne A. Der Unterschied ist die maximale Baudrate. fchk
Schorsch schrieb: > Mein 1.62€ Teil aus der Bucht entpuppte sich dann als PL2303 und lief > nicht standartmäßig unter Win10. Naja, da kann man ja auch mal näher definieren was man da kauft. Wenn man die natürlich bei einem chinesischen Textilhändler bestellt....
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.