Hi!
Sorry, ich weiß nicht, wonach ich noch suchen soll. Mag an mir liegen, aber ich finde nichts.
Also ich würde für ein Device mit integriertem Akku gerne einen USB-C Anschluss vorsehen, über den ich sowohl den Akku laden, als auch mit dem µC Board sprechen kann, zum programmieren oder für eine serielle Schnittstelle. Gibt es da Lösungen auf Breakout-Board, die beides ermöglichen?
Wenn ich google, dann finde ich nur Stromversorgung des µC über USB oder "Programm laden" oder was auch immer.
Wenn dein USB-Gerät zur Kommunikation oder Firmware-Upload verbunden ist, stellt der Host auch Strom bereit, mit dem du z.B. deinen Akku laden könntest.
d.H., das was du dir wünscht und nicht finden kannst, ist eine elementare Grundfunktion die gefühlt jedes µC/USB-"Breakout-Board" mitbringt. Es wäre sehr aufwändig, das wegzubekommen.
einen USB-C
Anschluss vorsehen, über den ich sowohl den Akku laden, als auch mit dem
µC Board sprechen kann
Dann nimmst Du am besten ein moderneres µC-Board, das den USB-C Anschluss und auch einen Ladecontroller für den Akku schon On-Board hat. Mögliche Kandidaten wären z.B. einige der Seeed XIAO-Boards, z.B. der hier:
Danke für die Rückmeldung!
Das „Problem“, wenn man es so nennen will, liegt weniger an der grundsätzlichen Funktion, sondern eher an der praktischen Umsetzung: Viele der gängigen USB-zu-Seriell-Chips auf Breakout-Boards melden gegenüber dem Host keine höhere Stromaufnahme an (z. B. für USB-C >500 mA). Dadurch wird das Board zwar versorgt, aber ein angeschlossener Akku lässt sich nur sehr langsam laden, weil einfach nicht genug Strom zur Verfügung steht — selbst wenn die Stromquelle eigentlich mehr liefern könnte.
Mir geht es darum, beides sauber zu kombinieren: schnelle Ladefunktion und Datenverbindung über einen gemeinsamen USB-C-Port, idealerweise ohne gleich eine eigene USB-PD-Lösung oder Lade-IC-Schaltung aufbauen zu müssen.
einen USB-C
Anschluss vorsehen, über den ich sowohl den Akku laden, als auch mit dem
µC Board sprechen kann
Dann nimmst Du am besten ein moderneres µC-Board, das den USB-C
Anschluss und auch einen Ladecontroller für den Akku schon On-Board hat.
Mögliche Kandidaten wären z.B. einige der Seeed XIAO-Boards, z.B. der
hier:
Danke! Den schaue ich mir an! Aber es gibt ja auch noch andere Gründe sich für das eine oder andere Board zu entscheiden. Da wäre eine allgemeinere Lösung natürlich ganz nett.
Mir geht es darum, beides sauber zu kombinieren: schnelle Ladefunktion
und Datenverbindung über einen gemeinsamen USB-C-Port, idealerweise ohne
gleich eine eigene USB-PD-Lösung oder Lade-IC-Schaltung aufbauen zu
müssen.
Naja, einen Laderegler wird Du je nach Akku ohnehin brauchen, und wenn Du mehr Strom oder höhere Spannungen haben willst, wirst Du auch um PD nicht drumrum kommen. Aber da gibts Lösungen:
einen USB-C
Anschluss vorsehen, über den ich sowohl den Akku laden, als auch mit dem
µC Board sprechen kann
Dann nimmst Du am besten ein moderneres µC-Board, das den USB-C
Anschluss und auch einen Ladecontroller für den Akku schon On-Board hat.
Mögliche Kandidaten wären z.B. einige der Seeed XIAO-Boards, z.B. der
hier:
Das ist aber ein schlechtes Beispiel. Hast Du Dir den Schaltplan angesehen? Die CC-Pins sind nur mit den üblichen 5.1k gegen Gnd beschaltet. Mehr nicht. Das Board ist schon von der Hardware her nicht in der Lage, mehr Strom oder höhere Spannungen auszuhandeln, und mehr wie 500mA kann man im USB-Deskriptor bei USB 2.0 eben nicht angeben.
Naja, einen Laderegler wird Du je nach Akku ohnehin brauchen, und wenn
Du mehr Strom oder höhere Spannungen haben willst, wirst Du auch um PD
nicht drumrum kommen. Aber da gibts Lösungen:
Perfekt! Ja, den Laderegler brauche ich natürlich. Aber mit zwei Anschlüssen, einen zum Laden und einen zum Flashen, find ich unschön. Schaue ich mir an!
Das ist aber ein schlechtes Beispiel. Hast Du Dir den Schaltplan
angesehen? Die CC-Pins sind nur mit den üblichen 5.1k gegen Gnd
beschaltet. Mehr nicht. Das Board ist schon von der Hardware her nicht
in der Lage, mehr Strom oder höhere Spannungen auszuhandeln, und mehr
wie 500mA kann man im USB-Deskriptor bei USB 2.0 eben nicht angeben.
Ja. Zum Zeitpunkt meines Posts hatte Michael noch nicht mit der Information herausgerückt, dass er für sein Gerät offenbar sehr viel Leistung braucht und daher USB-PD erforderlich ist. USB-C kann man sich ja auch noch aus einigen anderen Gründen wünschen.
Ich brauche jetzt auch gar kein PD im Moment, aber das wäre ja ein Anwendungsfall. Mehr als 500mA bei 5V würde ich aber schon gerne verwenden können, wenn die Quelle das bereitstellen kann.
Ich brauche jetzt auch gar kein PD im Moment, aber das wäre ja ein
Anwendungsfall. Mehr als 500mA bei 5V würde ich aber schon gerne
verwenden können, wenn die Quelle das bereitstellen kann.
Früher(tm) wurde der Strombedarf des Geräts mittels des Device Descriptors angemeldet, und zwar in 2 mA-Schritten bis maximal 500 mA. Das war ein ganz normaler Bestandteil des USB-Datenprotokolls.
Neuerdings, d.h. seit dem Steckertyp USB C, laufen das Aushandeln der Stromversorgung und der Datenverkehr jedoch völlig separat. Im einfachsten Fall sieht man einfach die 5,1 kOhm-Widerständen an den beiden CC-Pins vor, beim Wunsch nach mehr Spannung oder noch mehr Strom hängt man eben einen PD-Controller an die CC-Leitungen. Dieser Controller kann, aber muss nicht separat vom normalen USB-Controller laufen. Hierfür sehr zu empfehlen ist z.B. ein STM32G0, für den es von ST auch die entsprechenden PD-Bibliotheken gibt. (Tipp: nicht die veraltete und verkorkste Version verwenden, die STM32CubeMX generiert, sondern die jeweils neueste direkt vom Github-Repository verwenden!)
Ich habe erst kürzlich ein Gerät entwickelt, bei dem zuerst ein G0 das USB PD aushandelt und nach erfolgreichem Aushandeln von mindestens 12V/3A die Spannungsregler für die anderen Schaltungsteile aktiviert, so auch den STM32H7 für die Hauptfunktionalität, der an den USB-Dateileitungen hängt.
Früher(tm) hatte man ja immer das Problem, dass der "dicke" Prozessor mit den maximal 5 V/100 mA auskommen musste, die während der USB-Enumeration zur Verfügung standen. Das ist seit PD-Zeiten somit viel besser gelöst. Viele Geräte halten sich aber auch nicht an die 100 mA-Grenze, sondern saugen von Anfang an schon deutlich mehr, in der Hoffnung, die z.B. 500 mA auch wirklich zugeteilt zu bekommen.
Möglicherweise lassen sich zwei Fliegen mit einer Klatsche erschlagen, wenn man als µC den CH32X035 einsetzt. Der enthält einen USB-Device-Controller und weiß mit USB PD umzugehen.
USB-PD-Controller: FUSB302 , FUSB303, FUSB307..
Lässt sich mit βC relaiv einfach konfigurieren und die entsprechende Ladespannung(5V,9V,12V,15V,20V) und Stromstärke anfordern.(bis 3A)
Auch eine Umschaltung der Stromrichtung ist möglich.
Super! Danke, das sind erstmal ausreichend Infos! Auf einen spezifischen µC zu schwenken, "nur" um die Stromversorgung auszuhandeln, mag in Einzelfällen ok sein, aber wie ich schon schrieb hängen die Entscheidungen an anderen Eigenschaften. Die CC Leitungen durch eine separaten Controller zu bedienen, das ist genau, was mir nicht klar war.
Super! Danke, das sind erstmal ausreichend Infos! Auf einen spezifischen
µC zu schwenken, "nur" um die Stromversorgung auszuhandeln, mag in
Einzelfällen ok sein, aber wie ich schon schrieb hängen die
Entscheidungen an anderen Eigenschaften. Die CC Leitungen durch eine
separaten Controller zu bedienen, das ist genau, was mir nicht klar war.
Das ist heutzutage kein Einzelfall. Viele Geräte enthalten heutzutage eigenen Power-Management-Controller, die nur für das zeitlich korrekte Aktivieren der Versorgungsspannungen zuständig sind. Und dementsprechend ist es SEHR ratsam, auch das USB PD darüber laufen zu lassen. Und der Hauptprozessor startet erst dann, wenn der PMC festgestellt hat, dass der Ladezustand des Akkus ausreicht, diese oder jene externe Spanungsversorgung hinreichend stabil anliegt und/oder der nötige Saft per USB PD ausgehandelt wurde und tatsächlich als Vbus auch anliegt. Und den separaten Resetgenerator spart man sich ggf. auch. Neben dem Hochfahren geht es ja auch noch ums kontrollierte Ausschalten und ggf. um die Akkuüberwachung und -ladung in ausgeschaltetem Zustand. Wenn man versucht, das alles auf dem Hauptprozessor zu erledigen, muss man schlechte Kompromisse eingehen oder einen Bauteilemehraufwand eingehen, der deutlich über dem für einen winzigen Zusatzcontroller liegt. Mittlerweile gibt es ja auch schon einige dedizierte Spannungswandler, die solch einen programmierbaren Controllerkern integriert haben.
