Hallo, ein Gerät soll über einen USB-C Port verfügen. Für diesen gibt es zwei Use cases: Role #1: Gerät ist mit Laptop verbunden. Device Mode, Self Powered. Role #2: Ein USB-Stick ist eingesteckt. (Reduced) Host Mode, Source 5V/0.5A. Kommt man hier mit Widerständen an den CC-Pins aus, die mit einem Tranistor über einen UC geschaltet werden? Kann der UC erkennen, ob ein Host eingesteckt ist (Für eine automatische Role Umschaltung), also so wie bei Micro-USB der ID-Pin? Oder braucht es in diesem Fall einen Spezial-Chip für Source/Sink?
Du brauchst eine USB OTG Schnittstelle mit dazu passender Programmierung. Manche Mikrocontroller können das, aber noch lange nicht alle.
Richtig. So war das bei Mini-Micro-USB. Bei USB-C braucht man auch noch einen neueren UC, der das Protokoll der CC-Leitungen kann, zumindest wenn man USB-PD braucht (>5V, ...). Die Frage ist, ob man in diesem Fall darum herumkommt.
Steffen K. schrieb: > Kann der UC erkennen, ob ein Host eingesteckt ist Der Host speist den Port, der USB Stick nicht. Also: 5V vorhanden = Host angeschlossen. Die Frage ist also eher ob der µC erkennen kann das ein USB Stick gesteckt wird, damit er die USB Versorgung bereitstellt. Mittels Weak Pullups (1M?) an den Data Leitungen des µC sollte das zu bewerkstelligen sein. Ein unversorgter Stick zieht Data auf <1V runter.
Michael schrieb: > Steffen K. schrieb: >> Kann der UC erkennen, ob ein Host eingesteckt ist > > Der Host speist den Port, der USB Stick nicht. > Also: 5V vorhanden = Host angeschlossen. Aber nicht bei USB-C. Da schaut er erst auf den CC Pins, was da dran hängt und wie rum der Stecker steckt. Steht alles im Standard, muss man nur lesen & verstehen. Und genau dafür gibts DRP Controller. Den hier z.B. https://www.ti.com/lit/ds/symlink/hd3ss3220.pdf ST hat auch was: https://www.st.com/content/dam/AME/2019/developers-conference-2019/presentations/STDevCon19_6.3_UsbTypeC.pdf fchk
:
Bearbeitet durch User
Jetzt habe ich gefunden was benötigt wird: https://www.ti.com/lit/wp/slyy109b/slyy109b.pdf Auf Seite 5: USB Type-C DFP: USB 2.0 without USB PD - USB C ist unplugged ohne VBUS. - Sobald ein UFP (USB-Stick) eingesteckt wird, wird das über die CC Signale erkannt. - Dann wird der OTG USB Controller im (Reduced) Host Modus betrieben - Unplugged wird der OTG USB Controller im Device Modus betrieben - Wenn ein Laptop angeschlossen wird, kommt so eine Verbindung zustande. Jetzt brauche ich nur noch einen passenden Chip als Käfer, kein QFN etc. Multiplexer für D+/D- wird nicht benötigt. High-Speed reicht völlig aus.
Der TPS25810 geht in die richtige Richtung, mit eingebautem MOSFET. Jedoch ist das niedrigste Current Limit mit 1,7A viel zu hoch, 0,8A wären gut. Und D+/D- Protection hat der auch nicht. Kennt jemand was passenderes?
Steffen K. schrieb: > - Sobald ein UFP (USB-Stick) eingesteckt wird, wird das über die CC > Signale erkannt. USB Typ A hat nur Power und Data. Nix mit CC Signalen.
Michael schrieb: > Steffen K. schrieb: >> - Sobald ein UFP (USB-Stick) eingesteckt wird, wird das über die CC >> Signale erkannt. > > USB Typ A hat nur Power und Data. > Nix mit CC Signalen. Einen USB-Stick mit A-Stecker kann man in eine C-Buchse gar nicht einstecken. Dafür braucht es einen Adapter mit A-Buchse. Der hat dann vermutlich die entsprechenden Widerstände nach GND integriert.
Steffen K. schrieb: > Michael schrieb: >> Steffen K. schrieb: >>> - Sobald ein UFP (USB-Stick) eingesteckt wird, wird das über die CC >>> Signale erkannt. >> >> USB Typ A hat nur Power und Data. >> Nix mit CC Signalen. > > Einen USB-Stick mit A-Stecker kann man in eine C-Buchse gar nicht > einstecken. Dafür braucht es einen Adapter mit A-Buchse. Der hat dann > vermutlich die entsprechenden Widerstände nach GND integriert. Wieso vermutet Ihr nur und schaut nicht in den Standard? Da stehts nämlich genau drin. In der USB Type-C Cable and Connector Specification Rev 2.0 steht auf Seite 86, wie man einen Adapter von USB-C Stecker auf USB-A Buchse verdrahtet. Da steht auch, wo der 5.1k Widerstand hin muss und wo der 10nF Kondensator hin muss. Lesen bildet. Echt! fchk
Steffen K. schrieb: > Jetzt brauche ich nur noch einen passenden Chip als Käfer, kein QFN etc. Das wirst Du vermutlich vergessen können. Mag sein, daß es das TSSOP o.ä. gibt, aber als SO oder gar DIP wird es das ganz, ganz sicher nicht geben.
TSSOP ist auch ein Käfer da die Pins seitlich rauskommen.
Frank K. schrieb: > Wieso vermutet Ihr nur und schaut nicht in den Standard? 2.2 ist aktuell, da ist es S.90 und Du must auch auf die Feinheiten achten bevor Du hier den Oberlehrer gibst: 'Pin A5 (CC) of the USB Type-C plug shall be connected to GND through a resistor Rd (5.1 kΩ± 20%)' Von 10nF steht da nix. SHALL bedeutet nicht MUST! Shall, should, assumes. Die ganze USB Spec sieht so aus. Eigentlich kann man fast machen was man will und bleibt immer konform, weil man zwar sollte, aber nicht muss. Und deswegen ist die Lage so beschissen wie sie ist und deswegen geht der Kram mal und dann wieder nicht. Ich sehe eben keinen Grund für die Aufgabe des TO solche Klimmzüge zu machen wenn es doch so einfach auch geht.
Michael schrieb: > Ich sehe eben keinen Grund für die Aufgabe des TO solche Klimmzüge zu > machen wenn es doch so einfach auch geht. Einfach VBUS mit +5V verbinden und die CC Leitungen mit Pullup versehen?
Michael schrieb: > Frank K. schrieb: >> Wieso vermutet Ihr nur und schaut nicht in den Standard? > > 2.2 ist aktuell, da ist es S.90 und Du must auch auf die Feinheiten > achten bevor Du hier den Oberlehrer gibst: > 'Pin A5 (CC) of the USB Type-C plug shall be connected to GND through a > resistor Rd (5.1 kΩ± 20%)' > Von 10nF steht da nix. Lies Fußnote 4. > SHALL bedeutet nicht MUST! Seite 26 in Rev 2.2, "1.4.2.7 Shall" "Shall is a keyword indicating a mandatory (normative) requirement. Designers are mandated to implement all such requirements to ensure interoperability with other compliant Devices." Das liest sich hier aber anders. > Ich sehe eben keinen Grund für die Aufgabe des TO solche Klimmzüge zu > machen wenn es doch so einfach auch geht. Du bist der Auftragnehmer? fchk
Steffen K. schrieb: > Michael schrieb: >> Ich sehe eben keinen Grund für die Aufgabe des TO solche Klimmzüge zu >> machen wenn es doch so einfach auch geht. > > Einfach VBUS mit +5V verbinden und die CC Leitungen mit Pullup versehen? Funktioniert für einen Dual Role Port schon mal gar nicht. https://usb.org/document-library/usb-type-cr-cable-and-connector-specification-release-22 Für einen Source-only Port ist das nicht standardkonform. Siehe Standarddokument (siehe Link oben) Seite 161 "Table 4-11 Source (Host) and Sink (Device) Behaviors by State". Im State "Nothing attached" steht ganz klar "Sense CC pins for attach" und "Do not apply VBUS or VCONN". Im State "Sink attached" steht "Sense CC for orientation", "Sense CC for detach" und "Apply VBUS and VCONN". Da steht doch alles. fchk
Michael schrieb: > SHALL bedeutet nicht MUST! > Shall, should, assumes. Nope. "Thou shalt not kill". https://en.wikipedia.org/wiki/Thou_shalt_not_kill Das ist eines der zehn Gebote, und ist mitnichten mit "Du solltest nicht töten" zu übersetzen.
Wenn das UFP Device (USB-Stick) über die CC-Pulldowns erkannt wird, über einen Spannungsteiler mit Pullups im Gerät, kann das ein UC mit ADC-Eingängen erkennen und dann VBUS einschalten. Und über CC dann auch wieder einen disconnect erkennen und VBUS abschalten. So weit so gut. Aber der Laptop toggelt wohl abwechselnd PU und PD bei CC am USB-C-Port, um sowohl UFP und DFP Devices erkennen zu können. Wenn also im Gerät CC PU aktiv ist, würde das dann zu einem falschen Verhalten führen. So geht wohl Auto-Detect wie bei Micro-USB AB mit dem ID-Pin nicht. Und man muss den Modus über Software selektieren.
Frank K. schrieb: >>> Ich sehe eben keinen Grund für die Aufgabe des TO solche Klimmzüge zu >>> machen wenn es doch so einfach auch geht. >> >> Einfach VBUS mit +5V verbinden und die CC Leitungen mit Pullup versehen? Würdest Du bitte nicht über fehlerhaftes Zitieren zwei Aussagen miteinander verbinden die nichts miteinander zu tun haben? Harald K. schrieb: > Nope. "Thou shalt not kill". > https://en.wikipedia.org/wiki/Thou_shalt_not_kill > > Das ist eines der zehn Gebote, und ist mitnichten mit "Du solltest nicht > töten" zu übersetzen. So ein Blödsinn. In der Bibel wird gemordet auf Teufel komm raus und der allergrößte Massenmörder ist gleich Gott selbst, mit seinen Plagen, der Sinnflut und beliebigem hinwegmetzeln wenn ihm irgendwas quer liegt. Nach unserer Rechtssprechung wäre Gott lebenslang weggesperrt, mit ungünstiger Sozialprognose und in anschliessender Sicherheitsverwahrung. Wahnhaft, Obsessiv und vollkommen außerstande die Unrechtmässigkeit seiner Taten zu begreifen weil er sich als über allem stehend sieht.
Michael schrieb: > So ein Blödsinn. > In der Bibel wird gemordet auf Teufel komm raus Das mag alles sein, allein, es ersetzt nicht das fehlende Sprachverständnis. Wer kein Englisch kann, sollte sich nicht aus dem Fenster lehnen und versuchen, die Bedeutung von "shall" zu erklären. (Daß die "Bibel" ein von Hass triefendes Werk ist, müssen wir hier nicht ausdiskutieren, ich habe das sog. "Gebot" nur als Verständnishilfe für die des Englischen weniger mächtigen zitiert)
Harald K. schrieb: > Wer kein Englisch kann, sollte sich nicht aus dem > Fenster lehnen und versuchen, die Bedeutung von "shall" zu erklären. Sagt jemand der 'shall' nicht korrekt übersetzen kann? Shall bedeutet sollte. Und genau das bedeutet Dein Exkurs ins biblische. Da SOLLTE man nicht töten, aber es gibt reichlich Beispiele wo das auf Befehl oder mit Billigung Gottes getan wird. Das 'Shall' durch einen versteckten Nachsatz irgendwo im Kleingedruckten der USB Spec. eine neue Bedeutung gegeben wird, indem herumgewurstelt wird das sei schon irgendwie wichtiger und es sei hier eine Aufgabe übertragen worden, OHNE einmal 'must' zu verwenden, ist ein Eigenart der Spec, nicht der englischen Sprache. Mein Ursprünglicher Vorschlag, die Unterscheidung der Rollen danach zu treffen ob gespeist wird oder nicht, verletzt auch keine USB Spec. Es hätte nur bedeutet das man sich um den CC nicht kümmert und darum ob ein Adapter nach Typ A Spec Konform ist oder nicht.
Michael schrieb: > Sagt jemand der 'shall' nicht korrekt übersetzen kann? > Shall bedeutet sollte. Und genau das bedeutet Dein Exkurs ins biblische. Seufz. Nein, es bedeutet nicht "sollte".
Michael schrieb: > Sagt jemand der 'shall' nicht korrekt übersetzen kann? > Shall bedeutet sollte von dict.cc sb. shall [do sth.] -> jd. ist verpflichtet [etw. zu tun] "Shall" ist die Standardformulierung für verpflichtende Requirements. Siehe auch Herr der Ringe: "You shall not pass"
:
Bearbeitet durch User
Harald K. schrieb: > Das ist eines der zehn Gebote, und ist mitnichten mit "Du solltest nicht > töten" zu übersetzen. Doch, Gott hat das Töten unter gewissen Umständen nicht nur erlaubt, sondern auch befohlen. "Soll" ist schon richtig. Harald K. schrieb: > Das mag alles sein, allein, es ersetzt nicht das fehlende > Sprachverständnis. Wer kein Englisch kann, sollte sich nicht aus dem > Fenster lehnen und versuchen, die Bedeutung von "shall" zu erklären. Der Unterschied zwischen "shall" und "must" wurde korrekt erklärt. Das das sogar manche Engländer und Amerikaner ihre eigene Sprache uneindeutig bis falsch verwenden, sollte speziell uns deutsche nicht überraschen. Bestelle mal in Düsseldorf ein Glas Wasser und ein Sprudel. Dann mache das gleiche in Paderborn. Viel Spaß! Torben H. schrieb: > sb. shall [do sth.] -> jd. ist verpflichtet [etw. zu tun] > "Shall" ist die Standardformulierung für verpflichtende Requirements. Du bist auch verpflichtet, Mitmenschen in Not zu helfen. Wie vielen Menschen hast du gestern nicht geholfen? Dennoch läufst du frei herum und fühlst dich dabei wohl.
:
Bearbeitet durch User
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.