USB Stack für AT90USB162

Schau dir mal LUFA an.

Danke für die schnelle Antwort.
auf LUFA bin ich bei meiner Suche auch schon gestoßen.
Ich sehe nur bei dem Wust an Dateien nicht ganz durch welche die 
richtigen sind. Am liebsten hätte ich ein Beispielprojekt wo man nur die 
Dateien dabei hat die nötig sind. Ich arbeite mit dem AVR-Studio5 und 
habe die "AVR Entwicklungsplatine AT90USB162" hier aus dem shop.

Danke Klaus für den "Teensy" Tip.

Hat jemand damit schon Erfahrungen gesammelt? Soweit kann ich alles 
Kompilieren und die Software läuft auch. Nur unter Windows wird statt 
dem von mir erhofften HID Gerät nur ein unbekanntes Gerät angezeigt.
Ich benutze das Beispiel RAW-HID.
Die Funktion

1

usb_init();

 wird noch durchlaufen.
Aus der Schleife while

1

(!usb_configured()) /* wait */ ;

 kommt er dann nicht mehr raus. Was wohl darauf zurück zu führen ist das 
die Kommunikation mit dem Rechner nicht richtig hin haut. Aber warum das 
weiß ich leider nicht.
Ich benutze das AVR Studio5 auf einer XP Maschine.
Anbei mein Quellcode evt. hab ihr ja ne Idee waran es liegen könnte.
Ach ja ich habe einen Teil des originalen Codes gelöscht da ich die 
ganze Sache mit dem ADC nicht brauche.

ich glaube ich hab den Grund gefunden warum er hier

1

(!usb_configured())

 nicht weiter kommt. weil er nie den

1

USB_COM_vect

 anspringt. Die Interrupts sind Global freigegeben und funktionieren 
auch. Aber ich weiß nicht genau ob und wo dieser Interrupt freigeben 
wird. Komischerweise heißt der im Datenblatt auch "USB Endpoint 
Interrupt request" was ja nicht stört wenn hinter beidem die Gleiche 
Adresse liegt.
Hat da wer ne Ahnung?

Tobias Pfundt schrieb:
> Komischerweise heißt der im Datenblatt auch "USB Endpoint
> Interrupt request"

Das hängt damit zusammen, dass es außerdem noch den "USB General
Interrupt" gibt.

Das USB Endpoint Interrupt Enable Register hat den Namen UEIENX.

In "USB General Interrupt" kommt das Programm auch rein, dort wird dann 
im UEIENX Register das RXSTPE (Received SETUP Interrupt Enable Flag) 
gesetzt.
Wenn ich das richtig verstehe sollte doch damit Software seitig alles so 
sein das der Interrupt ausgelöst werden sollte so bald der Pc versucht 
das Device zu installieren oder?

Tobias Pfundt schrieb:
> Wenn ich das richtig verstehe sollte doch damit Software seitig alles so
> sein das der Interrupt ausgelöst werden sollte so bald der Pc versucht
> das Device zu installieren oder?

Keine Ahnung, ohne in den Code reinzugucken.  All die Abläufe sind
ziemlich komplex, und man kann das praktisch nur stückweise
debuggen.  In dem Moment, da dein Debugger einen Breakpoint erreicht,
rennt die ganze Prozedur seitens des USB-Hosts sofort in einen
Timeout, und das Gerät wird danach im Host-USB-Stack "abgeschrieben".

Die ganze Abfolge der verschiedenen Setup-Sequenzen ist der
schwierigste Schritt, den man meistern muss, um so einen USB-Controller
an einen Host ranzubekommen.  Während man das in Betrieb nimmt, nimmt
man zwangsläufig auch all die Dinge in Betrieb, die man später für
den eigentlichen Datentransfer braucht.

Bin wieder einen Schritt weiter. Jetzt wird das Board vom Rechner 
erkannt.
Denke das Problem lag im PLLCSR-Register dort wird ja der Takt für die 
USB-Anbindung erzeugt. Die Teensy-Sticks verfügen über einen 16Mhz Quarz 
weswegen der Vorteiler auf 2 gesetzt war( (16Mhz/2)*6=48Mhz ). Da die 
"AVR Entwicklungsplatine AT90USB162" nur über einen 8Mhz Quarz verfügt 
muss kein Vorteiler gesetzt werden.

Danke für die Antwort Jörg!

Hab auch irgendwie das Gefühl das über USB zu flashen mit Flip nicht so 
richtig zuverlässig hin haut.