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
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.
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...
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...
