Hallo wieder einmal... Ich habe jetzt einen neuen Thread eröffnet, obwohl das Thema evtl schon breitgetreten ist. Ich will mit meinem STM32F4 Discovery debug Ausgaben (printf, etc...) machen können. Um mir zuerst mal das Löten zu ersparen (UART -> MAX 232 ->etc...) möchte ich den USB Anschluss als VCP verwenden. Es gibt ja schon unzählige Diskussionen und Links, sodass ich nicht weiß, wonach ich letztlich greifen sollte. Hat da jemand Erfahrung, welcher Ansatz tatsächlich funktioniert? Ich möchte den VCP nur "benutzen und nicht verstehen", da es mir momentan noch um grundlegenderer Dinge geht... Danke
Das vereinfacht die Sache aber nicht gerade. Besorg dir besser einen 3€ USB/seriell Adapter und steck die 3 Kabel an.
Hi ARM Einsteiger, >Ich möchte den VCP nur >"benutzen und nicht verstehen" das ist zwar kein sehr guter Ansatz...aber jeder wie er will hier gibt es ein fertiges CooCox Beispiel für USB-CDC über die OTG-Buchse (CN5) vom Discovery-Board du brauchst allerdings ein USB-Kabel dazu mit Mikro-Stecker http://mikrocontroller.bplaced.de Gruss Uwe
hp-freund schrieb: > Besorg dir besser einen 3€ USB/seriell Adapter und steck die 3 Kabel an. Das mach ich auch. Es gibt fertige Adaptoren (um 3€ hab ich nix gefunden, ...): http://at.rs-online.com/web/p/entwicklungskits-interface/7511172/ oder http://www.conrad.at/ce/de/product/197326/Conrad-Mini-USB-zu-UART-Konverter?queryFromSuggest=true Das Kabel von FTDI ist etwas teuer. Ist der Zweite Adapter wohl brauchbar? Sollte ja auch nur ein FTDI Ding drin sein, oder? Eine "dumme" Nebenfrage: Wenn ich Steckpins wie auf der Buchsenleiste des zweiten Produkts untereinander verbinden will, ohne zu löten, gibt es da fertige female pin Verbinder , die man an ein Kabel dranlötet, oder die es schon als kurze Verbindungselemente (Kabel) gibt?
Warum kompliziert Debugen über UART? Das F4Discovery Board hat einen Programmer onboard der aus SWG unterstützt, spricht Debuging on Chip. Nutz doch das! Da kannst du überall Brakepoints setzen, Variablen beobachten etc... wesentlich komfortabler wie über UART.
Inzwischen gibt es auch tausende fertige Projekte fertig eingerichtet mit CooCox.
Martin K. schrieb: > Warum kompliziert Debugen über UART? Das F4Discovery Board hat einen > Programmer onboard der aus SWG unterstützt, spricht Debuging on Chip. es geht nicht nur um Debuggen, sondern auch darum, mit dem Ding "sprechen" zu könnnen. Ich wille eine bereits vorhandene App zum Laufen bringen, die man über ein Hyterterminal aussteuert. ;-)
ARM Einsteiger schrieb im Beitrag #3159776: > gibt es da fertige female pin Verbinder , die man an ein Kabel dranlötet, > oder die es schon als kurze Verbindungselemente (Kabel) gibt? ebay 190685792376 Kosten zwar etwas weniger ;-) , hab ich aber auch im Einsatz. Davon kann man ruhig ein paar liegen haben. Das Problem mit den Verbindern ist auch gelöst...
und der Treiber dazu? Ist der dabei? oder ein Link? Oder sind es eh nur die FTDI Treiber?
Ist ein CP2102. Linux erkennt den sofort, Win7 hat einen Treiber gefunden.
Bei mir steht Hong Kong. Hatte aber noch nie Probleme. Musst eben 2-3 Wochen warten können.
Uwe B. schrieb: > du brauchst allerdings ein USB-Kabel dazu mit Mikro-Stecker ...und die Treiber von ST, gelle? Eine richtige CDC Firmware zu schreiben, die mit den beim jeweiligen Betriebssystem vorhandenen Treibern auskommt, ist hingegen eine viel schwierigere Nummer. Ich hab genau aus diesem Grunde schon öfters einen Chip von FTDI verwendet, obwohl der eigentliche uC selber nen USB-Port hat. W.S.
>Ich hab genau aus diesem Grunde schon öfters >einen Chip von FTDI verwendet, obwohl der eigentliche uC selber nen >USB-Port hat. VCP eignet sich in Verbindung mit einem JTAG Debugger sowieso nicht für Degug Ausgaben. Wenn man mal mit dem JTAG in Single Step geht und die CPU anhält meldet Win sofort den VCP ab. Was das Terminal das die Debugausgaben vom VCP bekommen soll dann macht wenn ihm der COM Port unterm Arsch weggezogen wird ist eine andere Sache.
Ich habe eine reine Verständnisfrage (es ist keine Expertenfrage und hat eigentlich auch nichts mit einem speziellen Controller zu tun, also nicht gleich auf mich eindreschen, wenn die Frage etwas holprig rüberkommt für Leute, die schon 10 Jahre nichts anderes machen...): Ich hab mir http://mikrocontroller.bplaced.net/wordpress/?page_id=1263 angesehen, wo ein findiger Kopf eine CDC auf einem STM32F4 implementiert hat. Ich habe die Applikation soweit zum Laufen gebracht, dass am PC ein COM Port geöffnet wird, sobald ich mein Discovery Board über dem Micro USB anschließe. Leider geht nichts, wenn ich Daten über "Tera Term" sende. Aber das ist jetzt nicht das Problem, sondern ich möchte jetzt nur wissen, wie das ganze PRINZIPIELL mal funktioniert. Das Thema USB lässt mir seitdem keine Ruhe mehr, da ich (bis zu einem gewissen Grad) verstehen möchte, wie die Schnittstelle funktioniert, insbesondere so ein "VCP". So wie ich das bisher verstanden habe, gibt es eine Device Class "CDC", die diese Aufgabe realisiert. Stimmt das einmal? Ist CDC = VCP ? Da dies sicher nicht der Fall ist ;-), wo ist dann die Abgrenzung? Wann spricht man von VCP, wann von CDC? Die Spezifikation für CDC ist ja unter http://www.usb.org/developers/devclass_docs/usbcdc11.pdf zu finden. Dies scheint also ein "Standard" zu sein. Wenn es einen Standard gibt, wieso gibt es dann nicht Standard Treiber auf PC Seite, die schon eingebaut sind? Es gibt ja Treiber von ST, von FTDI, etc, ...? Wo ist da der herstellerspezifische Unterschied? Und wenn ich (rein theoretisch) einen Device Controller im Gerät implementieren möchte (wie im Beispiel), gegen welche Spezifikation müsste ich dann implementieren? Gegen die obige? Falls ja: heißt das, das alles wa da drinsteht, irgendwie in meinem Beispielcode abgebildet ist? So wahnsinnig umfangreich kommt mir der nämlich nicht vor, und die SPEC erscheint mir recht komplex... Und was wäre dann herstellerspezifisch zu tun? Der obige Code beruht ja auf dem ST Treiber, den man am PC installieren muss, damit es läuft. Und wo lese ich das dann nach? Und Wie grenzt sich das vom Standard ab? Vielleicht kann mir da jemand auf die Sprünge helfen? Danke!
ARM Einsteiger schrieb im Beitrag #3162773: > Ist CDC = VCP ? Nö. Also, VCP heißt Virtueller Com Port. Die richtigen COM-Ports werden ja vom Betriebssystem bedient und gepuffert - und als Anwendungsprogramm greift man nicht direkt auf so einen Port zu, sondern auf API-Funktionen des BS, die ihrerseits alles Nötige tun. Ein virtueller Com Port ist nun einer, auf den man genauso mit den gleichen API-Funktionen zugreift, obwohl dahinter was ganz anderes als ein COM-Port stecken kann. Das braucht nicht mal USB zu sein. CDC ist ne Geräteklasse am USB, konkret eine bestimmte Zahl in einem Byte (oder Word) in einer Descriptortafel, die das USB-Gerät an den PC liefern muß, wenn dieser danach fragt. Ich glaub, die 2 war CDC. Aber wie sich im Einzelnen nun so ein uC verhält, der sich am USB als CDC ausgibt, also wie im Detail er serielle Daten zu Paketen zusammenfasst, wie er gesendete Daten puffert und ausgibt und so weiter, das ist ne ganz andere Frage. Obendrein kennt Windows ja eigentlich gar kein Gerät, sondern fragt Hersteller- und Geräte-ID ab und sucht dann verzweifelt in seinen 1000 Inf-Files danach. Wenn sich dort was findet, dann wird das genommen, was dort drin steht (was auch immer) - wenn nicht, dann ist Neese.. W.S.
Ja, aber wie ist dann zu verstehen, wenn unter https://de.wikipedia.org/wiki/Universal_Serial_Bus#Ger.C3.A4teklassen geschrieben steht, dass CDC als Geräteklasse 0Ah bloß einen generischen Treiber benötigt, und man aber trotzdem einen spezifischen Treiber installieren muss? Ich musste für das genannte Beispiel einen ST Treiber installieren...
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.