Da ich ja noch immer beim kennenlernen und erlernen der µC von Atmel bin. Mich nun ein wenig mit dem Assembler beschäftigt habe, schon mal ein bisschen ATtiny2313 & ATmega88 berührt habe, habe ich nun so ein Dragon bekommen. Habe da noch keine Ahnung was ich mit dem machen soll / kann aber schauen wir mal. Unter anderem wollte ich nun auch mal ein wenig am AT90USB rum schnuppern. Die erste Aufgabe die ich mir gestellt habe ist mit dem AT90USB zu kommunizieren und zwar über USB. Hoffe das ich als erstes so eine virtuelle Schnittstelle hinbekomme so das ich auf der PC Seite erst mal keine Baustelle anfangen muss. Also so wie beim ATMega88 bzw. ATtiny2313 LEDON an den AT90USB senden und der macht halt einen Port Low damit die LED an geht. Soweit ich mich nun schlau gemacht habe ist das gar nicht so einfach da die USB-Schnittstelle von AT90USB eigentlich nix kann. Somit müsste ich alles was ich für eine Virtuelle COM benötige selber Programmieren. Sehe ich das richtig? Habe auch schon einiges gefunden im Netz LUFA zum Beispiel ist aber alles in C. Ich möchte dem Assembler treu bleiben. Ich suche auch nix fertiges, ich möchte ja verstehen was ich da mache doch wäre ein richtungsweisender Weg schon hilfreich. Könnte mich da mal jemand an die Hand nehmen? Was den DRAGON betrifft, habe von dem Teil echt noch keine Ahnung eventuell könnte man ja diesen auf diesem Weg miteinbeziehen.
Holger P. schrieb: > Ich möchte dem Assembler treu bleiben. Viel Vergnügen dann. Das Zusammenspiel zwischen Host und Device beim Eingliedern ("enumeration") eines USB-Geräts in den Host ist von vielfältiger Kommunikation dominiert. Der Host fordert das Gerät auf, sogenannte Deskriptoren rüberzureichen. Anhand der darin enthaltenen Daten versucht er dann, einen passenden Treiber zuzuordnen. Erst, wenn all dies reibungslos abläuft, wird man auf dem Host irgendetwas anderes als eine Fehlermeldung vom Gerät wahrnehmen können. Sicher kann man alles in Assembler bauen, aber wenn du ein Haus bauen willst, fängst du vermutlich auch nicht damit an, den Brennofen für die Ziegel zu nehmen und die Ziegel selbst zu machen, oder? Ich würde mir an deiner Stelle zumindest einmal die C-Beispiele herannehmen um zu verstehen, was da so abläuft. Dann kannst du dir immer noch überlegen, ob du das alles neu schreiben willst oder lieber eben einfach nur als Baustein in dein Projekt einbindest, damit du dich deinen eigentlichen Aufgaben zuwenden kannst. Wenn dir LUFA zu komplex ist, ich habe mal für µracoli eine Minimalimplementierung eines CDC (communication device class) geschrieben, die letztlich komplett in diesen beiden Dateien enthalten ist: http://hg.savannah.gnu.org/hgweb/uracoli/file/0ab76d1d8fd6/Src/Lib/Ioutil/hif_at90usb.c http://hg.savannah.gnu.org/hgweb/uracoli/file/0ab76d1d8fd6/Src/Lib/Ioutil/hif_usb.h Ich habe eine Weile gebraucht, bis ich alle Deskriptoren dabei in einer Form hatte, in der sie einerseits minimal waren, andererseits die entsprechenden CDC-Treiber aller mir zugänglichen Betriebssysteme gewillt waren, das Gerät als ein gültiges anzuerkennen. So ein Kram wie die "call management functional descriptor" oder "abstract control management functional descriptor" muss daher enthalten sein, auch wenn man diese Dinge eigentlich nicht braucht. Auch der interrupt endpoint muss da sein.
Danke Dir für die klasse Antwort. Es geht mir ja nicht darum etwas zu entwickeln sondern darum etwas zu verstehen.. Eben habe ich folgendes gefunden: http://www.weigu.lu/b/usb/key/vendor/index.html Dort wird so einiges erklärt. Eventuell bringt mich das weiter. Wie gesagt ich möchte ja nur auf den richtig Weg gebracht werden. Und wissen um was es geht.
Holger P. schrieb: > Eben habe ich folgendes gefunden: > http://www.weigu.lu/b/usb/key/vendor/index.html Die sind zwar auf der Controllerseite noch etwas einfacher gehalten, dafür brauchen sie (zumindest unter Windows) auf Host-Seite einen expliziten Treiber. Der Vorteil der CDC-Implementierung dagegen ist, dass alle gängigen Betriebssysteme dafür bereits Treiber mitbringen, und dass man dort dann einen "virtual COM port" geliefert bekommt. Aber dafür hast du natürlich dein gewünschtes Assemblerbeispiel. ;-)
OK soweit ich das verstanden habe ist das für den usb1287 und ich habe ja den AT90USB646 aber ich hoffe dadurch einwenig zu verstehen um was es geht. Nun erst mal auf der Windows Seite würde mir reichen. Kleine Brötchen backen. Doch ist natürlich Deine Geschichte wesentlich besser wenn man keinen Treiber benötigt und das auch noch Betriebssystem unabhängig ist. Doch ob ich jemals so weit komme. Bekomme ja immer nur etwas hingelegt und gesagt. Da haste wieder was zum spielen. Wie wo was ich damit machen kann ???? So auch mit dem Dragon. Väter halt.
Holger P. schrieb: > OK soweit ich das verstanden habe ist das für den usb1287 und ich habe > ja den AT90USB646 aber ich hoffe dadurch einwenig zu verstehen um was es > geht. AT90USB646,647,1286,1287 sind zueinander kompatibel. Klar, der offensichtliche Unterschied ist, dass die 64x nur 64 KiB Flash haben, und die 6er haben jeweils keine "USB OTG"-Funktionalität (on-the-go, so eine Art Mini-USB-Host). Aber als Device sind sie untereinander gleich zu handhaben. Lediglich die kleineren AT90USB82/162 bzw. deren Nachfolger (ATmega*U2) sind ein wenig anders, denen fehlt ein Teil der Hilfsfunktionen, die die "großen" AT90USB bereits in Hardware haben. > Nun erst mal auf der Windows Seite würde mir reichen. Kleine Brötchen > backen. Windows ist in dieser Hinsicht übrigens der mit Abstand schwierigere Gegenpart. Die Opensource-Unixe sind da allesamt viel angenehmer, weil sie bereits von Haus aus einen generischen USB-Gerätetreiber mitbringen, auf den sie zurückfallen, wenn kein spezifischer Treiber passt. Auf diesem kann man dann mit seiner Applikation immer per libusb aufsetzen. Das einzige zu lösende Problem ist dann das mit den Rechten, aber das hat man unter Windows ohnehin auch ("Neue Hardware gefunden ..."). Bei Windows gibt's sowas nicht. Entweder man schreibt ein Gerät, welches auf einen der wenigen Standard-Gerätetreiber passt (HID oder CDC sind da die beliebtesten, weshalb es halt allerlei Geräte in der freien Wildbahn gibt, die "HID" sein wollen, obwohl sie mit "Human Interface" im ursprünglichen Sinne nichts zu tun haben), oder aber man muss zumindest einen eigenen Stub-Treiber liefern. Sowas gibt's bei der LibUSB-Win32 wohl als Beispiel. > Bekomme ja immer nur etwas hingelegt und gesagt. Da haste wieder was zum > spielen. Versuche zu verstehen, was da passiert.
Jörg Wunsch schrieb: > Versuche zu verstehen, was da passiert. Genau so, und nachher sagen siehste geht doch. Er weiß es ja, aber sagt mir nix grrrr
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.