Hallo, Wir sitzen seit Stunden vor dem Problem der Initialisierung des AT90USB162. Wir haben uns bei der init-Reihenfolge des USB interfaces an die Reihenfolge im Datenblatt gehalten (s. 191 Datenblatt) an dem Punkt "Configure USB interface (USB Endpoint 0 configuration)" frage wir das CFGOK ab, ob es gesetzt ist vgl (s. 193 Datenblatt) und dort bleibt der Controller hängen, alle zuvorigen Schritte werden erfolgreich durchgeführt. Nachfolgende hab ich den Code für den schritt "Configure USB interface (USB Endpoint 0 configuration)" angehängt ... ich hoffe es kann mir einer helfen warum das das Bit nicht gesetzt wird. Lg Stefan p.s. die Funktion initDEVICE wird in der MAIN aufgerufen um die komplette init durchzuführen. /* ******************************************** */ /* initPLL */ /* ******************************************** */ void initPLL (void) { PLLCSR |= (1 << PLLP0) | (1 << PLLE); // Set preescaleler to 2 for 8MHz CLK while( !(PLLCSR & (1 << PLOCK)) ); // wait until PLL is locked } /* ******************************************** */ /* initUSB */ /* ******************************************** */ void initUSB (void) { USBCON |= (1 << USBE); // enable USB; USBCON &= (0 << FRZCLK); // enable extern CLK } /* ******************************************** */ /* initEP0 */ /* ******************************************** */ void initEP0 (void) { //UENUM = 0x00 is defaultsetting for EP0 UECONX |= (1 << EPEN); //UECFG0X = 0x00 is control mode (default) UECFG1X |= (1 << EPSIZE1) | (1 << EPSIZE0) | (1 << ALLOC); while ( !(UESTA0X & (1 << CFGOK))) { PORTB |= 0x40; } } /* ******************************************** */ /* initDEVICE */ /* ******************************************** */ void initDEVICE (void) { initPLL(); initUSB(); initEP0(); }
Woran erkennt Ihr, dass der Controller da hängen bleibt? Schließlich wird das Debug-Bit in der Schleife zwar ständig gesetzt, aber ich würde es nach der Schleife rücksetzen. Sonst sieht man ja nix :-) Naja, vielleicht ist der Code auch nur nicht gepostet.
Ein anderer Stefan schrieb: >Wir sitzen seit Stunden vor dem Problem der Initialisierung des >AT90USB162. Stunden? Ist doch gar nichts, ich habe über eine Woche herumprobiert. Beim AT90USB1287 war es das OTGPADE Bit, das man setzen musste. War nicht im Datenblatt angegeben, aber sonst blieb der USB-Teil tot. Kann beim AT90USB162 natürlich anders sein. USBCON = ((1<<USBE) | (1<<OTGPADE)); Siehe Datei usb_drv.c auf http://www.ssalewski.de/Misc.html.de
Sorry! Die LED blinkt normalerweiße einfach in der main. Das heißt nach dem initialisieren müsste die LED wieder anfangen zu blinken bzw. sie dürfte wahrscheinlich gar nicht leuten oder jedenfalls so kurz das man es nicht sieht. @Stefan Das OTGPADE Bit hat der AT90USB162 leider nicht soweit ich das jetzt noch im kopf habe.. Leider sind wir mit dem Code von dir auch genau an dieser Stelle stecken geblieben.. Gibt es von Atmel vielleicht eine Application Note in der steht wie die initialisierungsphase zu handeln ist? Hab schon gesucht leider nicht wirklich was gefunden. Ein ablaufdiagramm/struktogram wie es für das setzen und löschen von den Endpoints gibt wäre nicht schlecht.. gruß Dominik
>@Stefan >Das OTGPADE Bit hat der AT90USB162 leider nicht soweit ich das jetzt >noch im kopf habe.. Leider sind wir mit dem Code von dir auch genau an >dieser Stelle stecken geblieben.. Ah ja, der AT90USB162 ist wohl ein reiner Device-Controller ohne HOST/OTG Funktionalität, dann macht OTGPADE auch wenig Sinn. Das Ihr so viel Mühe habt den USB-Teil in Betrieb zu nehmen lässt erwarten, dass das Datenblatt bezüglich USB nicht sehr klar/vollständig ist -- war ja beim AT90USB1287 leider auch so. Warum habt ihr nicht den AT90USB1287 genommen -- nur wegen Preisvorteil? Ich kenne noch niemenden, der den AT90USB162 mit eigener oder Atmels Software in Betreib hat. Notfalls müsst Ihr bei Atmel anfragen oder euch deren Code ansehen. Gruß Stefan Salewski
Haben den Controller jetzt zum laufen gebracht .. der Fehler war wirklich sau blöd.. ==> USBCON &= (0 << FRZCLK); // enable extern CLK kann natürlich nicht gehen keine ahnung was wir uns dabei gedacht haben.. als nächstes werden wir uns jetzt mal um den diskriptorenaustausch bemühen. hierzu gleich mal eine Frage: Im groben hab ich das so verstanden.. - der Host schickt dem Controller den Befehl GET_DESCRIPTOR - der Controller fängt die Ankommenden Daten mit dem Interrupt START_OF_FRAME ab - Im Interrupt muss ich dann schauen für welchen Endpoint die Daten waren - Dann ich im Register UDPADDH das DPACC: DPRAM Direct Access Bit setzen um anschließend - mit dem Register UPDATX Die Daten vom Host Byte weiße aus dem FIFO zu lesen - Diese wertet dann meine Firmware aus und erkennt zb das er den Befehl GET_DESCRIPTOR geschickt wurde. - Jetzt muss ich nur noch den Device_Descriptor mittels UPDATX in den FIFO Byte weiße schreiben - muss ich jetzt dem Host noch ein ACK oder ähnliches schicken oder erkennt der beim nächsten Pollen automatisch das Daten im Endpoint0 zur verfügung stehen und holt die sich dann.. gruß Dominik
>Haben den Controller jetzt zum laufen gebracht .. der Fehler war >wirklich sau blöd.. >==> USBCON &= (0 << FRZCLK); // enable extern CLK Ups, das ist ärgerlich. Das Problem ist, dass die Notation in C nicht gerade übersichtlich ist, und insbesondere, dass man bei solchen Problemen (Neuer Controller, der nicht laufen will) die Probleme überall vermutet, aber zuletzt bei einen einfachen Tippfehler. Das der Controller jetzt läuft bedeutet ja, dass Atmel das Datenblatt diesmal doch klarer und insbesondere vollständig gestaltet hat -- daher zunächst ein kleines Lob an Atmel! Ich würde an Eurer Stelle übrigens recht bald auf das direkte Setzen und Löschen von Bits verzichten und mir dafür Makros wie "USB_Enable_Clk" oder ähnliches basteln. Das wird viel übersichtlicher und obiger Tippfehler hätte sich dann gar nicht einschleichen können. Wenn der Kontroller jetzt aktiviert ist, sollte die Enumeration ja sehr ähnlich wie beim AT90USB1287 ablaufen -- ihr solltet meinen Code also weitgehend übernehmen können. Die Grundlagen sind im Buch von H.J. Kelm recht gut beschrieben, alle frei zugänglichen Erklärungen (die ich kenne) sind für Anfänger leider zu knapp. Die Erläuterungen zu meiner freien Firmware sind jetzt übrigens auch in englischer Sprache verfügbar: http://www.ssalewski.de/AT90USB_firmware.html.en Gruß Stefan Salewski
Muss zugeben ich bin kein wirklicher Freund von Makros. Finde die tragen leider gar nicht zur Lesbarkeit bei. Gerade wenn man versucht einen Code nach zu vollziehen kann dieses ständige springen zwischen den Header- und Quellcode dateien wirklich nervig und hinderlich sein. Wo du allerdings recht hast beugt man damit auch Fehlern vor. Für die Enumeration hab ich mir jetzt doch auch mal ein Buch geholt (USB 2.0 Handbuch für Entwickler) scheint mir ganz gut und ausführlich zu sein. mal schaun wie weit wir damit kommen die Diskriptoren zu schreiben war ja nicht so schwer. gruß
>Muss zugeben ich bin kein wirklicher Freund von Makros. Finde die tragen >leider gar nicht zur Lesbarkeit bei. Gerade wenn man versucht einen Code >nach zu vollziehen kann dieses ständige springen zwischen den Header- >und Quellcode dateien wirklich nervig und hinderlich sein. >Wo du allerdings recht hast beugt man damit auch Fehlern vor. Ja, dass ist schon richtig. Aber wenn man keine SINNVOLL BENANNTEN Makros benutzt, wird es schnell extrem unübersichtlich. Ich hatte bei meiner Firmware auch mit direkten Bitoperationen angefangen, aber schon nach ein paar Dutzend Code-Zeilen und einigen Wochen habe ich dann selbst nicht mehr exakt gewusst, was die einzelnen Bits konkret bewirken. Das Erstellen der Makros, insbesondere das Finden guter aussagekräftiger Namen, ist schon etwas Arbeit, aber dann doch eine Erleichterung. >Für die Enumeration hab ich mir jetzt doch auch mal ein Buch geholt (USB >2.0 Handbuch für Entwickler) scheint mir ganz gut und ausführlich zu >sein. Ja, ohne Buch geht es wohl nicht. Das von Dir genannte Buch ist ja von Axelson. Ich habe "USB Complete" von Axelson, hab dann aber doch fast ausschließlich das Buch von von H.J. Kelm verwendet (Das mir übrigens Benedikt Sauter empfohlen hatte). Kelm stellt auf den ersten 100 Seiten die Grundlagen des USB schon recht verständlich dar, weder zu knapp noch zu geschwätzig. Gruß Stefan Salewski
Super das Buch gibts in unserer Uni Bibiliothek das werde ich mir am Montag gleicht mal holen vielen Dank für den Tipp Gruß Dominik
Hallo ich sitze seit tagen über einem Problem (falls es eines ist und ich nicht nur etwas falsch verstehe) und zwar hab ich in meiner Firmware 3 Endpunkte einen Control einen Iterrupt IN und einen Bulk OUT.. aktiviere ich nun im UEIENX Register die Interrupts RXSTPE,TXINE und RXOUTE bekomme ich nach der enumeration meines Gerätes ständig Interrups die mein mainprogramm völlig blockieren. meinem verständnis nach sollte lediglich alle 255ms (so im Interrupt IN Endpunkt descriptor festgelegt) ein TXINI Interrupt kommen da dieser ja vom Host gepollt wird (Frage am rande: mach das pollen der treiber auf dem pc oder muss das die software machen die das gerät anspricht.) der RXSTPI kommt immer dann wenn ich einen control Transfer initiiere das funktioniert soweit. RXOUTE kommt gar nicht wenn ich ein bulk_out sende. meinem verständniss nach müsste doch die Interrupt Routine aufgerufen werden wenn einer der 3 Interrupts kommt. Danach schau ich im UEINT Register für welchen Endpunkt der Interrupt bestimmt war. Anschließend aktiviere ich den entsprechenden Enpunkt lösche die Interrupt flags nach so wie es im Datenblatt unter Endpoint Management steht.. leider funktioniert das ja mal gar nicht.. hab ich irgendwo einen denkfehler? gruß
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.