Guten Morgen, auf dem STM32 Mikrocontroller nutze ich die USB_OTG_FS Schnittstelle um Daten zum PC auszutauschen. Die Beispielapplikation läuft als Virtueller Com Port. Nun soll nicht der Mikrocontroller die Spannung (VBUS) für den USB Port versorgen sondern der USB PC Port soll den Mikrocontroller mit Spannung versorgen. Wie müsste ich den USB Port an den Mikrocontroller beschalten, so dass zum einen die Mikrocontroller Pins bzw. USB PC Port nicht beschädigt werden ?
Wenn die Spannungsversorgung vom PC kommt, dann wird der IC STMPS2141 nicht mehr benötigt. WIe müsste ich dann den Pin VBUS an den Mikrocontroller vebinden ?
im Datasheet der MCU gibt es ein Schaubild dazu VBUS der Buchse bleibt direkt verbunden mit dem VBUS-Pin der CPU nur brauchst du noch einen Spannungswandler 5V->3,3V der aus den 5V die Betriebsspannung der CPU erzeugt Gruss Uwe
Einen Spannungswandler brauche ich nicht. Bin mir nicht ganz sicher. In sämtlichen Schaltplänen mit STM32 Mikrocontroller wo ich gefunden habe, konnte ich keinen Spannungswandler finden. Was du meinst ist, dass über den USB Port die komplette Schaltung versorgt wird. In meiner Schaltung soll der Mikrocontroller die ganze Zeit mit Spannungsversorgt werden nicht über USB.
was sollte dann dieser Satz : >Nun soll nicht der Mikrocontroller die Spannung (VBUS) für den >USB Port versorgen sondern der USB PC Port >soll den Mikrocontroller mit Spannung versorgen. und was willst du GENAU machen ? willst du den USB-Port als HOST Anwendung betreiben oder als Device als HOST musst du 5V liefern im anderen Fall bekommst du 5V (die du aber nicht unbedingt benutzten musst)
Der STM32 soll als Device arbeiten. Dies bedeutet die Spannungsversorgung soll vom USB PC Port kommen. Im Prinzip müsste ich den VBUS Pin vom USB Port an den STM32 Pin PA9 verbinden.
>Im Prinzip müsste ich >den VBUS Pin vom USB Port an den STM32 Pin PA9 verbinden. genau (so wie auf deinem Schaltplan gezeigt) nur das IC "U1 / STMPS2141" kannst du dir dann sparen >Der STM32 soll als Device arbeiten. Dies bedeutet die >Spannungsversorgung soll vom USB PC Port kommen hier widersprichst du dir wieder mit dem Post oben : >In meiner Schaltung soll der Mikrocontroller die ganze Zeit mit >Spannungsversorgt werden nicht über USB nochmal langsam : 1. du willst ein USB-Device bauen -> ok 2. von welcher Spannungsquelle soll die CPU versorgt werden ? 2a. von einem externen 3,3V Netzteil -> dann brauchst du keinen Spannungswandler 2b. vom PC über das USB-Kabel -> dann brauchst du auf der Platine einen Spannungswandler, weil aus dem USB-Anschluß 5V rauskommen, die CPU aber nur 3,3V verträgt
Die CPU wird von einer externen Spannungsquelle versorgt. Sorry hab mich etwas ungeschickt ausgedrückt. Muss ich dann in diesem Fall VBUS mit der CPU Pin PA9 verbinden?
>Muss ich dann in diesem Fall VBUS mit der >CPU Pin PA9 verbinden? Ja wobei "muss" nicht ganz richtig ist PA9 wird ja als "VBUS-Sens" Signal benutzt damit kann die CPU erkennen ob ein HOST angeschlossen ist oder nicht (durch den Spannungspegel an VBUS) falls du das nicht brauchst kannst du die Verbindung auch weglassen und in der Software das Signal ignorieren ich würde es aber reinmachen "kost ja kein Geld" Gruss
Guten Morgen, der VBUS Anschluss vom USB Port müsste doch nicht direkt mit dem STM32 Pin PA9 verbunden werden. In sämtlichen Schaltplänen die ich gefunden habe war der nicht direkt mit dem STM32 Pin PA9 verbunden. Wie sieht es eigentlich aus mit einer Schutzbeschaltung von den Leitungen DM bzw. DP ?
Guten Morgen, von STM habe ich mir die STM32_USB-Host-Device_Lib_V2.1.0 heruntergeladen und nutze die Virtual Com Port Applikation. Mir sind hier einige Dinge unklar: 1) In der C-Datei usbd_cdc_vcp.c gibt 7 Funktionen. Wozu dienen diese Funktionen? Sind diese nur für Debugzwecke da? 2) In der C-Datei usbd_usr.c gibt 5 Funktionen. Wo wird die Funktion VCP_DataRx aufgerufen beim Empfang von Daten? Wozu dient die Funktion VCP_Ctrl?
Bin leider noch nicht weitergekommen, wozu genau die C Datei usbd_cdc_vcp.c dient und wo genau die Funktion VCP_DataRx von der C Datei usbd_usr.c aufgerufen wird. Für jegliche Hilfe wäre ich sehr dankbar!
Tja, das ist eben immer das Problem mit den tollen Universal-Quellen, die von den Herstellern gelegentlich angeboten werden: Sie lösen nicht die Probleme, sondern verlagern sie bloß. Die Funktionen in usbd_usr.c sind eigentlich nur Platzhalter, damit beim Compilieren alles durchläuft. Natürlich könnte man sowas anders organisieren und z.B. nur eine Funktion "start()" vorsehen, die beim Öffnen einer seriellen Schnittstelle im PC aufgerufen wird und die dann die Puffer für den Transfer initialisiert und ggf. ne Startmeldung in den Ausgangspuffer setzt usw. - aber sowas wäre den Programmierern bei ST, NXP und Konsorten ja zu einfach. Die Funktionen in usbd_cdc_vcp.c hingegen sollten eigentlich richtig ausgefüllt sein. Klar, sie sind auch nur Platzhalter, aber solche, die auf USB-Botschaften reagieren sollen. Dazu zählt das Empfangen und Senden der Schnittstellen-Einrichtung (Baudrate, Bitanzahl, Stoppbits, Parität..) und das Empfangen von rts/cts usw. Bei einer internen Verwendung der Datenströme ist das zwar egal, aber so einfach schnöd garnix tun ist auch nicht richtig. Tja, und die Handhabung der eigentlichen Datenströme ist zumeist auch lausig. Wenn man nen virtuellen COM Port benutzen will, dann will man dort auch asynchron und byteweise damit verkehren und nicht blockweise. Ich hab das (allerdings bei nem Nuvoton NUC120) etwa so gemacht: Für IN und OUT gibt es jeweils treiberinterne Ringpuffer. Der für IN (also vom Device zum Host) braucht nur so groß zu sein wie die zugehörige Endpoint-Puffergröße. Abgefragt wird er über den 1 ms USB-Tick. Der Puffer für OUT hingegen sollte mindestens größer als die doppelte Endpoint-Puffergröße sein. Kommt ein Paket an, dann wird es erstmal angenommen und in den Puffer gepackt. Ist danach noch genug leerer Platz im Puffer für eine nächstes Paket, dann wird der Endpoint wieder empfangsbereit geschaltet. Ist hingegen nicht mehr genug Platz im Puffer, dann wird der Endpoint auf Länge 0 gesetzt, d.h. er sagt dem Host, daß er nur noch Blöcke mit 0 Byte Länge annehmen wird, quasi NAK. Das geht dann so lange, bis (asynchron geleert) wieder genug platz im Ringpuffer ist. W.S.
Bitte 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.