Weiß jemand, ob es ein Open Source/Open Hardware Projekt gibt, um schnell einen USB zu TTL-UART aufzubauen? Einen FTDI Chip und USB Lötstecker für Platinen hätte ich noch. Sonst irgendwie direkt aus USB-Signalen und passenden Driver dazu, der ein /dev/tty (macOS/Linux) bzw. COM-Device (Windows 10) erzeugt? Habe so'n Ding in der Bucht bestellt für 3,45€ inkl. Versand, dauert aber.
Christoph K. schrieb: > Sonst irgendwie direkt aus > USB-Signalen und passenden Driver dazu, der ein /dev/tty (macOS/Linux) > bzw. COM-Device (Windows 10) erzeugt? So funktioniert USB leider nicht. Schon gar nicht, was Pegel angeht. Christoph K. schrieb: > Einen FTDI Chip und USB > Lötstecker für Platinen hätte ich noch Den könntest du doch nutzen. Die Schaltung drumherum ist kein Geheimnis, könnte auf Lochraster nur ein bisschen spannend werden. Ansonsten kommt es halt drauf an, was du noch so da hast. Arduinos, Blue Pills,... Alle können das mit mehr oder weniger Aufwand
Christoph K. schrieb: > Weiß jemand, ob es ein Open Source/Open Hardware Projekt gibt, um > schnell einen USB zu TTL-UART aufzubauen? Einen FTDI Chip und USB > Lötstecker für Platinen hätte ich noch. Sonst irgendwie direkt aus > USB-Signalen und passenden Driver dazu, der ein /dev/tty (macOS/Linux) > bzw. COM-Device (Windows 10) erzeugt? "einen FTDI-Chip" ist gut. FTDI hat viele verschiedene. Zu jedem gibts ein Datenblatt. Da gibts auch einen Schaltplan. Aber ohne passende Leiterplatte wird das nichts. Das einzige, womit Du einen USB-UART auf Lochraster aufbauen kannst, ist ein Microchip MCP2221A-I/P. https://www.microchip.com/en-us/product/MCP2221A fchk
Gast
#7090843
Ist ein Arduino zur Hand? Da ist alles drauf, was benötigt wird. Ganz ohne Programmierung. Ist ein ATtiny85 zur Hand? Da gibt es Soft-USB, das sich leicht um einen virtuellen Com-Port erweitern ließe. Die FTDI232 und CH340G melden sich nativ auch als Com-Port beim Rechner an. Also: Viele Wege führen nach Com1.
Gast
#7090854
Fan von Yussif schrieb: > Ist ein ATtiny85 zur Hand? Da gibt es Soft-USB, das sich leicht um einen > virtuellen Com-Port erweitern ließe. Das ist außerhalb der USB-Spezifikation, die die hier verwendete CDC-Geräteklasse für Low-Speed-Geräte nicht kennt. Manche Betriebssysteme sind so tolerant, das zu erlauben, aber nicht alle tun das. > Die FTDI232 und CH340G melden sich nativ auch als Com-Port beim Rechner > an. Die sind keine CDCs und brauchen ihre eigenen Devicetreiber, die irgendwer installieren muss (oder bei manchen Betriebssystemen im Lieferumfang enthalten sind).
Fan von Yussif schrieb: > Ist ein Arduino zur Hand? > Da ist alles drauf, was benötigt wird. Ganz ohne Programmierung. > > Ist ein ATtiny85 zur Hand? Da gibt es Soft-USB, das sich leicht um einen > virtuellen Com-Port erweitern ließe. > > Die FTDI232 und CH340G melden sich nativ auch als Com-Port beim Rechner > an. > > Also: Viele Wege führen nach Com1. Habe so einen Bluepill mit STM32F103C8T6. Wenn mir jemand den Weg aufzeigen könnte, wie ich daraus einen USB zu UART/TTL machen könnte, würde ich gleich loslegen. Restliche Programmierumgebung wäre ja vorhanden.
Angehängte Dateien:
-
IMG_3201.jpg
(240 KB)
Christoph K. schrieb: > Wenn mir jemand den Weg > aufzeigen könnte, wie ich daraus einen USB zu UART/TTL machen könnte Google wäre ein Weg, aber okay. Such dir was aus: https://github.com/r2axz/bluepill-serial-monster https://donneyfan.com/blog/usb-serial-for-blue-pill-stm32-with-platformio https://satoshinm.github.io/blog/171223_stm32serial_triple_usb-to-serial_adapter_using_stm32_blue_pill.html http://dangerousprototypes.com/blog/2017/06/21/how-to-stm32f103c8t6-as-an-usb-device-virtual-serial-port-cdc/ https://medium.com/@pasindusandima/stm32-usb-virtual-com-port-vcp-bc7cb1bd5f5
Gast
#7090885
> dauert aber.
Selber schuld. Wer jede Schraube in-time kauft, kommt halt nicht voran.
Logistiker schrieb: >> dauert aber. > > Selber schuld. Wer jede Schraube in-time kauft, kommt halt nicht voran. Stimmt zwar irgendwo, aber in diesem Falle ist (vermutlich) etwas kaputtgegangen - mein einziger vorhandener FTDI-Serial USB Adapter.
Christoph K. schrieb: > Habe so einen Bluepill mit STM32F103C8T6. Wenn mir jemand den Weg > aufzeigen könnte, wie ich daraus einen USB zu UART/TTL machen könnte, z.B. indem du meine USB-CDC-Software drauf flashst: https://github.com/Erlkoenig90/f1usb/releases/tag/v1.1 Damit hast du dann 3 serielle Ports. Pinbelegung: * VCP0: TX=PA9, RX=PA10, DTR=PA1, RTS=PA5 * VCP1: TX=PA2, RX=PA3, DTR=PA6, RTS=PA7 * VCP2: TX=PB10, RX=PB11, DTR=PC0, RTS=PC1
Gast
#7090914
Christoph K. schrieb: > Stimmt zwar irgendwo, aber in diesem Falle ist (vermutlich) etwas > kaputtgegangen - mein einziger vorhandener FTDI-Serial USB Adapter. Eben, Logistiker hat Recht. USB-TTL-Adapter, hat man besser immer in Reserve liegen. Aber wie bekommt man so ein Ding kaputt und was heißt in diesem Zusammenhang "vermutlich"? Ging er vorher noch und jetzt nicht mehr oder hat das Ding bei dir noch nie funktioniert?
Gast
#7090927
Schmeiß das FTDI Zeug weg. Eventuell ist der ftdi chip nicht defekt gegangen sondern war ein fake der per update absichtlich zerstört wurde. WCH CH340c wäre eine Alternative. Etwas robuster CP2102. Höhre baud als der Ch340C hat z.B. der CH343G.
Wolfgang schrieb: > Christoph K. schrieb: >> Stimmt zwar irgendwo, aber in diesem Falle ist (vermutlich) etwas >> kaputtgegangen - mein einziger vorhandener FTDI-Serial USB Adapter. > > Eben, Logistiker hat Recht. > > USB-TTL-Adapter, hat man besser immer in Reserve liegen. > > Aber wie bekommt man so ein Ding kaputt und was heißt in diesem > Zusammenhang "vermutlich"? Ging er vorher noch und jetzt nicht mehr oder > hat das Ding bei dir noch nie funktioniert? Ich konnte ihn letztens noch benutzen, um mit Demonstrator GUI seriell einen STM32F407VGT6 programmieren. Seitdem versuche ich vergeblich, das noch mal zu wiederholen. Auch geht Echo mit Konsoleprogramm (OC Console, auch mit niedriger Baudrate) nicht, wenn ich Tx mit Rx verbinde. Als /dev/cua.dingsbums wird der Chip noch gesehen. Ich hatte ja die TTL-Signale direkt vom Chip abegriffen.
Gast
#7090996
Äh schrieb: > sondern war ein fake > der per update absichtlich zerstört wurde. Das gibts schon seit zehn Jahren nicht mehr. Stattdessen den komplett undokumentierten "Winchip"-Crap zu empfehlen ist supi. Das Zeug ist noch übler als Prolific.
Gast
#7091005
Wenn es auch ein CP2104 sein darf: https://www.mechapro.de/shop/Schrittmotor-Steuerungen/Einzelachsen-Takt-Richtung-offene-Bauform/smOOver-prg-Programmieradapter-f-smOOver-drv::279.html Ist allerdings etwas teurer als von Ali-Express, da Made in Germany. Dafür wohl ab Lager lieferbar. Gruß Tom
Gast
#7091015
DerEinzigeBernd schrieb: > Das gibts schon seit zehn Jahren nicht mehr. War übel genug als das die Ihren Namen auf jahrzehnte verbrannt haben. DerEinzigeBernd schrieb: > Stattdessen den komplett > undokumentierten "Winchip"-Crap zu empfehlen ist supi. Jaja. Komplett undokumentiert. Gibt Datenblätter und die Software für die CH340B, etc. bekommst du ohne irgendwelches contact us. Vertraust deren Software nicht? Github hat da auch noch was. Außerdem nur weil die CH340 empfindlich sind, heißt nicht, dass alle deren Chips so sind zumal der CH343 komplett anderes design nutzt. Neben WCH gibt es auch noch das bereits erwähnte Silicon Labs.
Gast
#7091087
Äh schrieb: > War übel genug als das die Ihren Namen auf jahrzehnte verbrannt haben. Aber auch nur bei Dir. > Gibt Datenblätter und die Software für die CH340B, Es gibt sehr flüchtige Beschreibungen, und eine Übersetzung solch einer Beschreibung ins Englische. Mit einem Datenblatt hat das nichts zu tun. > Neben WCH gibt es auch noch das bereits erwähnte Silicon Labs. Richtig, SiLabs ist eindeutig zu bevorzugen. Die haben Datenblätter. Anders als Winchip und Prolific.
Gast
#7091245
Äh schrieb: > Schmeiß das FTDI Zeug weg. > Eventuell ist der ftdi chip nicht defekt gegangen sondern war ein fake > der per update absichtlich zerstört wurde. Davon abgesehen, dass die Treiberversion, auf die Du anspielst, uralt ist, wurde gar nichts zerstört. FTDI hat lediglich bei Fake-Chips die unrechtmässig verwendete USB-VID/PID überschrieben. Lässt sich rückgängig machen, wobei ich sowas eher dem Lieferanten auf den Tisch knallen würde. Äh schrieb: > War übel genug als das die Ihren Namen auf jahrzehnte verbrannt haben. Ich verbaue seitdem noch lieber FTDI-Chips. Dass sie aktiv gegen Plagiate vorgehen, erhöht die Wahrscheinlichkeit, dass Fake-Chips direkt auffallen, statt durch unauffälliges Fehlverhalten Schaden anzurichten.
Gast
#7091254
Sebastian R. schrieb: > Such dir was aus: Oder auch das Beispielprogramm von unserem Mitglied Niklas G: http://stefanfrings.de/stm32/3-Fach-USB-UART.zip (Im Release Order liegt der Binärcode, den du mit dem STM32 Cube Programmer auf das Board laden kannst)
Stefan ⛄ F. schrieb: > Sebastian R. schrieb: >> Such dir was aus: > > Oder auch das Beispielprogramm von unserem Mitglied Niklas G: > http://stefanfrings.de/stm32/3-Fach-USB-UART.zip > > (Im Release Order liegt der Binärcode, den du mit dem STM32 Cube > Programmer auf das Board laden kannst) Auch schön. Mein Problem: ich muß erst mal eine Konfiguration finden, wie ich das bluePill-Board jetzt mit STM32CubeIDE (ist das = Cube Programmer?) angesprochen bekomme. Bisher hatte ich meine Targets über das STLINK-V2 SWD-Interface des DISCO-Boards angeschlossen und debuggt. Ich hatte irgendwie dumpf in Erinnerung, daß ich SWCLK und SWDIO nicht an die pins des bluPill Boards, die da horizontal herauskommen, anschließen muß, sondern an irgendwelche PA09/PA10 oder sowas oder irre ich mich?
Gast
#7091284
Christoph K. schrieb: > Auch schön. Mein Problem: ich muß erst mal eine Konfiguration finden, > wie ich das bluePill-Board jetzt mit STM32CubeIDE (ist das = Cube > Programmer?) > angesprochen bekomme. Bisher hatte ich meine Targets über das STLINK-V2 > SWD-Interface des DISCO-Boards angeschlossen und debuggt Dann mach das doch wieder so. Setze den Boot0 Jumper auf 1 und verbinde den ST-Link mit dem Board. Alternativ bietet sich der serielle Bootloader an, einen Adapter dazu hast du ja auch.
Gast
#7091316
Christoph K. schrieb: > Habe so'n Ding in der Bucht bestellt für 3,45€ inkl. Versand, dauert > aber. Da gibt es jede Menge Schrott. Laufen nicht durch, oder haben alle die gleiche Serien Nummer, usw. STMs wie oben zu flashen wird besser sein
Gast
#7091357
Schrotti schrieb: > STMs wie oben zu flashen wird besser sein Wenn sie sich denn flashen lassen. Da gibt's ja auch wieder oft Probleme mit den Fakes.
Stefan ⛄ F. schrieb: > Christoph K. schrieb: >> Auch schön. Mein Problem: ich muß erst mal eine Konfiguration finden, >> wie ich das bluePill-Board jetzt mit STM32CubeIDE (ist das = Cube >> Programmer?) >> angesprochen bekomme. Bisher hatte ich meine Targets über das STLINK-V2 >> SWD-Interface des DISCO-Boards angeschlossen und debuggt > > Dann mach das doch wieder so. Setze den Boot0 Jumper auf 1 und verbinde > den ST-Link mit dem Board. > > Alternativ bietet sich der serielle Bootloader an, einen Adapter dazu > hast du ja auch. Einen Adapter, der vermeintlich kaputt ist und den zu ersetzen es genau gilt :) Gut, aber Programmierung hat geklappt über die an der blue pill herausgeführten Pins und BOOT0 auf 1. Aber jetzt brauche ich doch Hilfe von Niklas (erlkoenig): Ich schließe die BluePill über USB-C-Kabel an mein MacbookPro an. Ein USB-Device "Fluxcompensator" wird gefunden. Ich weise es dem Mac zu (weil sich die Parallels Windows10 VM auch darum bewirbt) und es kommt gleich wieder eine neue USB-Verbindungsanfrage. Es scheint, als könne das Device nicht dauerhaft verbunden werden. EDIT: könnte vielleicht auch ein "faulty board" sein. Ich messe R10=10k bzw. sehe es auch.
Auswechseln von R10 (10K -> 1,8K) half nicht, die USB-Verbindungsloop zu reparieren.
Christoph K. schrieb: > Auswechseln von R10 (10K -> 1,8K) half nicht, die USB-Verbindungsloop zu > reparieren. Welche Software? Was heißt "Loop"? Welches OS? Kannst du es unter Linux versuchen und die Kernel-Meldungen zeigen?
Niklas G. schrieb: > Christoph K. schrieb: >> Auswechseln von R10 (10K -> 1,8K) half nicht, die USB-Verbindungsloop zu >> reparieren. > > Welche Software? Was heißt "Loop"? Welches OS? Kannst du es unter Linux > versuchen und die Kernel-Meldungen zeigen? macOS 11.6.6 (BigSur), f1usb-binary-images/vcp.bin Linux:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
Sieht doch gut aus, wo ist da eine "Loop"? Wenn die Enumeration so weit klappt kann es eigentlich nicht mehr am Widerstand liegen. Eher Wackelkontakt oder so.
Niklas G. schrieb: > Sieht doch gut aus, wo ist da eine "Loop"? Wenn die Enumeration so weit > klappt kann es eigentlich nicht mehr am Widerstand liegen. Eher > Wackelkontakt oder so. Das war jetzt Linux (auf Deine Bitte hin). Was nicht geht, ist macOS. Da wird's allerdings schwierig, was ich das schicken soll.
Christoph K. schrieb: > Was nicht geht, ist macOS. Damit kenne ich mich nicht aus, habe die USB-Software damit auch nie getestet. Unter Windows sollte es gehen (Bootcamp?). Gibt es unter macOS einen Kernel Log?
Niklas G. schrieb: > Christoph K. schrieb: >> Was nicht geht, ist macOS. > > Damit kenne ich mich nicht aus, habe die USB-Software damit auch nie > getestet. Unter Windows sollte es gehen (Bootcamp?). Gibt es unter macOS > einen Kernel Log? Ich hänge einen Auszug des system.log an von dem Moment an, wo ich das USB-Device eingestöpselt habe.
Da steht überhaupt nichts von USB o.ä. ... Was passiert wenn du Windows oder Linux nativ (keine VM) auf dem mac bootest? Wenn es dann klappt, liegt es nicht an der Hardware. Geht die Power-LED auf dem Board ständig aus / an? Das würde heißen dass macOS die Spannungsversorgung vom USB-Port kappt um das Gerät neu zu verbinden. Das würde bedeuten dass macOS irgendwas am Gerät nicht passt. Das Gerät kann sich gar nicht selbsttätig trennen, weil der Widerstand nicht schaltbar ist.
Niklas G. schrieb: > Da steht überhaupt nichts von USB o.ä. ... Was passiert wenn du Windows > oder Linux nativ (keine VM) auf dem mac bootest? Wenn es dann klappt, > liegt es nicht an der Hardware. Ich weiß eben jetzt auch nicht genau, wo USB-Diagnostics zu finden sind. Windows, Linux native auf Mac?. Weiß nicht, ob sowas überhaupt geht, wäre aber auch nicht das, was ich anstrebe. Danke erst mal. Ich versuche die Hardware erst mal mit einem der anderen Pakete zu verifizieren. Danke trotzdem.
Niklas G. schrieb: > Damit kenne ich mich nicht aus, habe die USB-Software damit auch nie > getestet. Dein Code benutzt doch IAD Descrptors wenn ich mich richtig erinnere. Das wurde (wird?) auf dem Mac nicht unterstützt
Thomas Z. schrieb: > Dein Code benutzt doch IAD Descrptors wenn ich mich richtig erinnere. Richtig, weil Windows sonst keine mehrfachen USB-CDC-ACM-Geräte unterstützt, obwohl die USB-Spec das vorsieht. > Das wurde (wird?) auf dem Mac nicht unterstützt Ernsthaft?? Das ist doch mittlerweile Teil der USB-Spec und eine Menge USB-Geräte sind heutzutage Verbundgeräte (IAD), gehen die alle nicht? Man kann die Software modifizieren dass sie nur einen Port hat, oder klassisch direkt mehrere CDC-ACM-Kanäle hat statt IAD, aber da hab ich jetzt grad keine Zeit für...
Niklas G. schrieb: > Richtig, weil Windows sonst keine mehrfachen USB-ACM-CDC-Geräte > unterstützt, obwohl die USB-Spec das vorsieht. nein das funktioniert unter Win auch ohne IAD mit mehreren CDCs. IAD ist zwar für neuere Compount Devices vorgeschrieben, aber selbst bei den neueren USB specs ist sich die USB org da nicht so ganz einig. Beispiel: usbmidi2.0 müsste IAD haben hat es aber nicht. > Ernsthaft?? Das ist doch mittlerweile Teil der USB-Spec und eine Menge > USB-Geräte sind heutzutage Verbundgeräte (IAD), gehen die alle nicht? Ich hab das mal auf Stackoverflow gelesen, ist aber schon eine ganze Zeit her, da ich keinen Mac habe kann ich nicht sagen ob das noch aktuell ist. IAD ist strenggenommen auch nicht für Compound Devices sondern nur dazu da wenn mehrere Interfaces auf die gleiche Device Function gehen. Das betrifft Device Functions die ein Control Interface und ein Daten Interface haben. Beispiele: CDC, Audio (ab 2.0), Midi (ab 2.0)
Thomas Z. schrieb: > nein das funktioniert unter Win auch ohne IAD mit mehreren CDCs. Hat es bei mir nicht als ich es getestet hatte (möglicherweise noch zu Win8-Zeiten), während es unter Linux ging (IIRC).
Niklas G. schrieb: > Hat es bei mir nicht als ich es getestet hatte (möglicherweise noch zu > Win8-Zeiten), während es unter Linux ging (IIRC). Ich kann für W7 und W10 sprechen. Bei W10 geht es direkt bei W7 brauchts halt infs die auf die einzelnen Interfaces zielen. W7 braucht ja aber sowieso eine inf damit der CDC funktioniert.
ich hab den Artikel jetzt gefunden: https://stackoverflow.com/questions/5508304/usb-communications-device-with-multiple-serial-ports-working-on-all-platforms/37522988#37522988
Christoph K. schrieb: > [ 134.096408] usb 3-2: Product: Fluxkompensator Wußte doch, daß ich das Gerät kannte :) "Zurück in die Zukunft"
Christoph K. schrieb: > Wußte doch, daß ich das Gerät kannte :) "Zurück in die Zukunft" Eben, und weil Macs aus der Vergangenheit sind kommen die damit nicht klar.
Niklas G. schrieb: > > Geht die Power-LED auf dem Board ständig aus / an? Das würde heißen dass Nein, die ist permanent an, nur um das noch beantwortet zu haben.
Gast
#7092506
Warum sind kommerzielle Betriebssystem eigentlich so schlecht?
Gast
#7092573
Dichter schrieb: > Warum sind kommerzielle Betriebssystem eigentlich so schlecht? Psssst, das darfst du doch nicht sagen!
Für den USBasp für verschiedene AVRs gibt es eine Firmware-Erweiterung mit Unterstützung eines seriellen Ports: https://github.com/akrasuski1/usbasp-uart
Gast
#7093883
Das dürfte nur funktionieren, wenn das Betriebssystem die nicht standardkonforme Kombination von CDC mit Low-Speed-USB erlaubt. USBasp nutzt bitbanging (VUSB) und kann daher nur Low-Speed (1.5 MBit), und standardkonform können Low-Speed-Devices keine "bulk transfers" durchführen. Die aber werden von CDC benötigt.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.