Hallo, Projekt in Planungsphase. Ich bin mit dem Rest meiner Schaltung fertig und sehr zufrieden, aber dieses Detail sorgt bei mir für sehr viel Verwirrung und Frust. Ich habe eine Schaltung im Kleinstformat, die vom USB-C Anschluss meines Smartphones betrieben werden soll (Das Smartphone hat einen 16 Pin-Anschluss - Das ist meines Wissens nach nur USB 3.0 mit "2.0 Geschwindigkeit" über D- und D+?). Die Größe und vor allem auch die Dicke sind sehr wichtig, weil ich es in eine flexible Hülle für mein Smartphone integrieren will. Aufbau ist MCU, UART-USB-Konverter, Messinstrumente. Die Schaltung verbraucht in Ruhe <10µA exkl. des UART-USB-Konvertes (wenn ich ihn anlassen sollte). Spitzenverbrauch <300mA. Verbinden würde ich über einen selbstgebauten "180° Stecker" im U-Format. Und ich dachte das reicht mir auch. Doch ich finde es auf einmal doch besser den USB-C Ports meines Smartphones noch für anderes benutzbar zu haben. Beim Laden des Smartphones muss die Brücke ja jetzt ausgesteckt, und nachher wieder angesteckt werden. Das vermeidbar zu machen wäre für mich ein großer Komfortbonus und das An- und Abstecken dieses Verbinders wäre auch eine Abnutzungs-/Sollbruchstelle. Mein primärer Ansatz wäre über einen zweiten USB-C Port auf meiner Schaltung den USB-C Port des Smartphones nutzbar zu machen, sobald in diesen zweiten Port ein Gerät eingesteckt wird (Ladegerät, oder Daten übertragende Geräte). Mein Gerät soll sich dann tot stellen. Insgesamt betrachtet, welche Möglichkeiten zur Umsetzung habe ich? Ich liste mal meine Gedankengänge auf: 1) Verwendung eines USB-Hub-ICs. Wie funktioniert da das (Schnell)Laden? 2) Erkennung der Benutzung des 2. Ports und Abschaltung/Abkopplung von D- und D+ meiner Schaltung mit Hilfe meines MCUs und diskreten Komponenten. Die Erkennung des Ansteckens eines Gerätes ist mir noch schlüssig (Bestromung des Ports abkoppeln, messen, und wenn beide Pole nicht mehr offen sind, durchschalten). Wie erkenne ich die Abkopplung? 3) Manuelles Umschalten per Kippschalter. Den bräuchte ich dann in seitlicher Ausführung in extrem klein (von der Höhe und Breite wie ein weiblicher USB-C Port oder kleiner). Am besten dann noch eine LED dazu. Montierung "auf halber Höhe" mit Ausfräsung der Platine, wie das bei USB-C Ports geht, würde ich vorziehen. 4) Irgendwie die Daten anders übertragen. Leider wäre ein BT-Modul so groß wie meine jetzige WIP-Platine (ich bin jetzt bei 30x20mm), ich weiß auch gar nicht ob man zum Funktionieren einer BT-Verbindung einen Mindestabstand bräuchte (Meine Schaltung wird sehr nah am Smartphone sein)? Kann ich da problemlos die Stromversorgung des USB-Ports für meine Schaltung nutzen, oder führt das zu Problemen beim Anstecken eines Gerätes in den 2. Port? Die Frage ist unter Umständen dumm, ich weiß aber nicht, wie das Protokoll funktioniert. Vielleicht sendet es ja am Anfang, oder wartet auf ein Datenpaket, und wenn es keines bekommt, und nur Strom verbraucht wird, stellt der USB-Host sich dumm und denkt, ich habe permanent ein Ladegerät angesteckt. Das übersteigt meinen Erfahrungsschatz und ich würde mich da über ein paar Gedanken und Anstöße in die richtige Richtung sehr freuen. Vielen Dank!
Keks F. schrieb: > 1) Verwendung eines USB-Hub-ICs. Wie funktioniert da das (Schnell)Laden? Einen PD-fähigen USB-Hub verwenden.
Hallo Harald, vielen Dank für deinen Einwand. Das ist scheinbar vorerst die beste Option, die ich habe. Was mir auch noch eingefallen ist. Gibt es keine Buchsen mit Einsteckerkennung? Ich habe hier etwas darüber gelesen, leider sind die Links nicht mehr aktuell: https://electronics.stackexchange.com/questions/311924/usb-plug-in-detection-for-charging-port Grüße
Hallo, mir fällt gerade noch ein Ansatz an. Ich kann auf die Spec scheißen, und einen der GND Pins offen lassen. Beim Anstecken eines Gerätes wird der ja nach unten gezogen.
Keks F. schrieb: > Aufbau ist MCU, UART-USB-Konverter, Messinstrumente. > Die Schaltung verbraucht in Ruhe <10µA exkl. des UART-USB-Konvertes > (wenn ich ihn anlassen sollte). Spitzenverbrauch <300mA. Wenn Dir die Größe wichtig ist, warum nutzt Du dann nicht einen COntroller mit integrierten Hardware-USB? Gibt ja genug. Oder bekommst Du das nicht gebacken? > 2) Erkennung der Benutzung des 2. Ports und Abschaltung/Abkopplung von > D- und D+ meiner Schaltung mit Hilfe meines MCUs und diskreten > Komponenten. Die Erkennung des Ansteckens eines Gerätes ist mir noch > schlüssig (Bestromung des Ports abkoppeln, messen, und wenn beide Pole > nicht mehr offen sind, durchschalten). Wie erkenne ich die Abkopplung? Diskrete Komponenten solltest Du nicht nehmen. Dafür gibts passende Multiplexer. https://www.onsemi.com/pdf/datasheet/fsusb42-d.pdf Bei USB-C wird das Erkennen von An- und Abstecken, Erkennung der Drehrichtung und Erkennen Host/Device über die CC1 und CC2 Pins gemacht. Die wirst Du auswerten müssen. Lies den USB-C Standard, da steht das alles drin. https://usb.org/document-library/usb-type-cr-cable-and-connector-specification-release-22 fchk
Frank K. schrieb: > Wenn Dir die Größe wichtig ist, warum nutzt Du dann nicht einen > COntroller mit integrierten Hardware-USB? Gibt ja genug. Von WCH gibt es sogar welche, die USB-PD unterstützen, den CH543 mit MCS-51-Kern https://www.wch-ic.com/products/CH543.html und den CH32X035 mit RISC-V-Kern https://www.wch-ic.com/products/CH32X035.html
Frank K. schrieb: > Wenn Dir die Größe wichtig ist, warum nutzt Du dann nicht einen > COntroller mit integrierten Hardware-USB? Gibt ja genug. Oder bekommst > Du das nicht gebacken? Weil Größe und Anordnung der jetzigen Komponenten eine Lücke auf dem PCB (zwangsläufig) lassen (aufgrund des zweiten USB-C Ports), die für den Konverter reichen würden, ich auch 16 Bit PWM brauche, und MCUs, die beides können, teurer sind als MCU und Konverter, und ich für diesen MCU dann andere IDE, Programmierumgebung und Bibliotheken bräuchte. Der Einwand mit den Multiplexern ist gut, und deren Notwendigkeit ebenso. Mir fiel das gestern auch auf und ich habe den Abend verbracht mir 2 Kandidaten dafür rauszusuchen. Da gibt es noch viel mehr Kandidaten für mich, die aber USB MHDL Multiplexer sind. Die Eigenschaften der USB und als MHDL klassifizierten Gates dieser ICs sind im Datenblatt exakt gleich. Meine Notizen vorm zu Bett gehen an mich selbst waren, ich teile mal: 1) Multiplexer verwenden 2) Ein- und Ausstecken über diesen GND-Pin mit Pullup 3) Kann ich einen USB MHDL Multiplexer benutzen, oder muss ich einen nehmen, der für 2 "normale" USB Ausgänge ausgewiesen ist. 4) Beim Multiplexer wird der ESD Schutz übernommen. 5) Wie funktioniert das USB Protokoll treibermäßig? Würde ein USB MCU auf Android nativ unterstützt werden, brauche ich einen extra Treiber dafür? Wie hoch ist neben dem Kostenunterschied der Umstiegsaufwand? Kandidat ATMega8U2.
:
Bearbeitet durch User
Keks F. schrieb: > Der Einwand mit den Multiplexern ist gut, und deren Notwendigkeit > ebenso. Ich halte das für eine Designfehlentscheidung. USB wird durch derartige Spielereien nicht zuverlässiger. Warum nimmst Du keinen PD-fähigen USB-Hub? https://www.microchip.com/en-us/product/USB7252
Ja, ich finde beide Ansätze doof. Der Hub IC ist sehr groß, kostet so viel wie die ganze Platine + Bestückung + Erstellen der Gummihülle für das Smartphone, in der die Platine eingelassen wird, braucht nochmal 3.3V (also nochmal einen Buck- oder Linearregler rein, und ist ein ganzer 4 Port Hub. Und das letzten Ende nur um ein USB 2.0 Datenpaar zu schalten. Der verlinkte IC ist mir nach deinem erstmaligen Posting nach Recherche als Kandidat ins Auge gefallen. Gleichsam ärgert es mich, dass der Knackpunkt einfach ein Erkennen eines mechanischen Einsteckens ist. Ich verstehe dich, ich bin aber mit keiner Lösung zufrieden. Meine Wunschlösung wäre immernoch eine Buchse mit entsprechendem "Sensor"-Pin für's Einstecken. Die konnte ich bis jetzt nur für Typ A-Buchsen finden. Angeblich gibt es eine Typ C-Buchse damit von WE, im Katalog konnte ich die aber nicht finden, eine Verlinkung von Stackexchange geht ins Leere. Ich habe auch mal WE und andere Hersteller angeschrieben, vielleicht ergibt sich auch da etwas. Probleme mit dem einen der 4 GND-Pins weniger stelle ich mir nicht vor. Die SuperSpeed-Leitungen gehen eh nicht. Das ist ja nur Masseanbindung für das Laden. Da hat der Stecker mehr Masse, die Platine hat eh auf der Unterseite komplett GND. Ich finde die Lösung aber auch unschön, und das ärgert mich. Harald K. schrieb: > Von WCH gibt es sogar welche Die finde ich bei lcsc oder octopart gar nicht. Für mich ist momentan der beste Kompromiss mit einem PI3USB102G o.Ä. die zwei Lines abzuschalten, wenn der eine GND-Pin runtergezogen wird (= USB-Gerät im 2. Port angeschlossen). Dazu noch über Mosfets den Rest meiner Schaltung komplett von VBUS zu trennen. Wenn das dann noch auf Geräten mit höherer Ladespannung funktionieren soll, einen kleinen Linearregler dran nur für den Multiplexer und für das Trennen meiner Restschaltung.
:
Bearbeitet durch User
Keks F. schrieb: > Die finde ich bei lcsc oder octopart gar nicht. Aliexpress. WCH höchstselbst betreibt dort einen Store. CH32X035 https://de.aliexpress.com/item/1005005657432204.html Eval Board dafür https://de.aliexpress.com/item/1005005718558442.html
Oh wow, ich hatte selber mal bei Ali das eingegeben aber nichts zurückbekommen. Die verkaufen da ja ihr ganzes Sortiment, und auch sehr günstig. Danke dafür!
Keks F. schrieb: > Die verkaufen da ja ihr ganzes Sortiment Leider nicht wirklich alles, den CH543 beispielsweise bieten sie dort nicht an.
Okay, das ist wirklich alles sehr beeindruckend. Vom Featureset, zum maximalen Stromverbrauch (4mA!), vom Preis (0,60€ pro Stück). Die Dokumentation scheint in Ordnung zu sein, ich bin davon auch sehr überrascht. Ich hoffe der kann meine ATTiny 2-Series MCUs nicht komplett ersetzen, weil ich davon noch sehr sehr viele habe. Eine Frage bleibt aber für mich, wie kommuniziert der CH32X035 dann mit Android? Für die CH340 gibt es eine extra Bibliothek dafür. Ich merke die Entwicklung und das Debugging läuft scheinbar über einen Fork/Addon von Eclipse (und auch auf Linux), von einem Treiber für Windows/Linux/Mac für den CH32X035 konnte ich aber auch (noch) nichts finden. Videos nach zu urteilen scheint er unter Linux "einfach so" zu funktionieren. Wie sieht es auf Android aus? Wie gesagt für den CH340 wird eine Bibliothek bereitgestellt (wenn auch kein Treiber). Es ist ein bisschen unübersichtlich, weil die Seite auch gerne auf Chinesisch wechselt und die Downloads sehr sehr langsam sind. Kurze Frage, die werde ich vielleicht dann morgen ausgeschlafen selber beantworten können. Gibt es da Debugging mit Breakpoints und "Reinschauen"? Vielen Dank nochmal und liebe Grüße
:
Bearbeitet durch User
Keks F. schrieb: > Wie sieht es auf Android aus? Gibt es libusb für Android? Ansonsten muss man halt ein passendes USB-Device-Protokoll implementieren, wie z.B. CDC. Das sollte Android kennen. Keks F. schrieb: > Gibt es da Debugging mit Breakpoints und > "Reinschauen"? Dafür gibt es den Programmier-/Debugadapter WCHLinkE https://www.aliexpress.com/item/1005004881582037.html Wenn man nicht direkt mit dem CH32X035 beginnt, sondern sich erst mal mit einem anderen kleineren RISC-V-µC einarbeiten möchte, empfiehlt sich eines der Kits aus Musterplatine, WCHLinkE und ein paar losen µCs. https://www.aliexpress.com/item/1005004895791296.html Als Entwicklungssoftware ist dann "Mounriver Studio" zu verwenden. Über die µCs gibt es hier auch schon den einen oder anderen Thread, wie z.B. den hier: Beitrag "CH32V003 - Experimente mit dem Zehn Cent-Mikrocontroller" Die genannten 10 Cent sind beinahe korrekt, ein Gurtabschnitt mit 50 CH32V003J4M6 (im SO-8-Gehäuse) ist für etwa 5.70 EUR (allerdings zzgl. Versand) zu bekommen.
Harald K. schrieb: > Gibt es libusb für Android? Ansonsten muss man halt ein passendes > USB-Device-Protokoll implementieren, wie z.B. CDC. Das sollte Android > kennen. Ja, ich sehe damit und mit diesem Ansatz werde ich schon weiterkommen. https://stackoverflow.com/questions/59217443/how-to-read-for-data-from-cdc-device-connected-to-android-using-usb-serial-for-a Harald K. schrieb: > Dafür gibt es den Programmier-/Debugadapter WCHLinkE Da frage ich mich, was er macht. Letztenendes ist es nur ein Konverter. Ich frage mich, wieso das nicht mit einem Evalboard schon drauf ist. Das Evalboard ist leider nur Spannungsregler, Controller, Knöpfe und die Header. Gibt es scheinbar nur im Dreierpack. Ich schaue auf dem Rechner nachher genau, aber für den CH32X035 gibt es glaube ich so ein Kit (wie du unten im Zitat sagst, leider auch nicht). Harald K. schrieb: > Wenn man nicht direkt mit dem CH32X035 beginnt, sondern sich erst mal > mit einem anderen kleineren RISC-V-µC einarbeiten möchte, empfiehlt sich > eines der Kits aus Musterplatine, WCHLinkE und ein paar losen µCs. Da habe ich mich gestern eingelesen, welche sich lohnen. Der Ruhestrom ist bei einigen sehr hoch (10µA). Es gibt einen BLE Chip, der einen sehr niedrigen Ruhestrom hat. Der wäre für mich vielleicht noch interessant. Ich denke ich werde mir gleich den CH32X035 nehmen. Der ersetzt dann bei netzbetriebeben Geräten meine ATTinys. Stromversorgung über USB, auch über PD, finde ich attraktiv und erspart das ein oder andere Netzteil (so ein PD-Netzteil ist evtl. auch günstiger als eines mit Rundstecker aus der Grabbelkiste). Die Schaltung der Evalboards ist öffentlich. Leider sagen mit die nicht zu. Ich will da lieber etwas breadboardfähiges, und beim Selbstbau spare ich mir auch etwas. Ich will das mal direkt riskieren und sehe das als Herausforderung. Harald K. schrieb: > Als Entwicklungssoftware ist dann "Mounriver Studio" zu verwenden. Auch wenn ich die ArduinoIDE hasse, so nutze ich sie für meine ATTinys mit MegaTinyCore. Es gibt scheinbar auch eine "Übersetzungsbibliothek" für den CH32X035 (Link habe ich bei mir auf dem Rechner). Ich werde wohl in beides schnuppern, aber bei meiner IDE bleiben. Ich sehe da eine Möglichkeit Projekte einfacher auf eine andere MCU portieren zu können. Sehe ich das richtig, dass der CH32X035 über PD höhere Spannungen aushandeln kann, zum Betrieb aber trotzdem einen Spannungswandler auf seine maximal 5V braucht?
Keks F. schrieb: > Da frage ich mich, was er macht. Letztenendes ist es nur ein Konverter. Das kann man von jedem anderen JTAG/SBW/ISP/Debugwire/pipapo-Adapter auch sagen, und man sollte erkennen, daß das die falsche Fragestellung ist. Der WCHLink spricht das (JTAG-artige) 1-Draht-Protokoll, das die µCs von WCH in Hardware zum Debuggen und Programmieren anbieten. Man könnte den auch auf den Testplatinen unterbringen, nur würde das denjenigen nicht weiterhelfen, die diese Platinen nicht einsetzen (und die Platinen verteuern).
Harald K. schrieb: > Der WCHLink spricht das (JTAG-artige) 1-Draht-Protokoll, das die µCs von > WCH in Hardware zum Debuggen und Programmieren anbieten. Ah, das erklärt das. Harald K. schrieb: > (und die Platinen verteuern) Gut, 3€ pro Platine. Ich hätte mich gefreut, ist halt ein Eval-Board. Andererseits holt man das einmal und kann das dann überall benutzen. Ich verstehe schon.
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.