mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AT90USB162 initalisierung


Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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();
}

Autor: Chrisi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@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

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.