AT90USB1287 SETUP empfangen

[Ugene (Gast)]

Hallo Forum,

bin zur zeit mit usb controller beschäftigt.
Ich gehe dabei so vor:

//initial reset

//enable USB pad regulator

//start PLL, 
  
//enable USB controller
  
//enable OTGPIN, 
    
//Enable clock für USB
    
//Configure USB interface 
  fullspeed 
  setup EP0 (ControlEP)  

//Enable WakeUp interrupt
  
//Enable End of Reset Interrupt
  
//wait for USB VBUS connection
  enable VBUS detection

//attach USB device
  DETACH = 0

//interrupt enable
  sei()
//enable SETUP RECIEVED Interrupt 
         RXSTPE = 1

//wait for valid SETUP Packet 
         wati till RXSTPI = 1  

// start setup process
        ...

Wenn das Gerät(µC) eingeseckt wird, erkennt Windows, dass ein neues USB 
Gerät angeschlossen wurde (-> USB controller erfolgreich gestarttet).
Aber das Gerät wird nicht erkannt, ist auch logisch, weil keine 
Deskriptoren gesendet wurden, da start setup process nicht ausgeführt 
wird.

Problem: RXSTPI wird nie 1, was heißt kein SETUP paket wird empfangen. 
Direkt nach dem Einstecken kann ich 3,5V auf D+ messen, und ein Signal, 
das vermutlich SETUP vom host darstellt (siehe Anhang).

Weiß jemand Rat?

[Ugene (Gast)]

anhang

[Stefan Salewski (Gast)]

>wati till RXSTPI = 1

Einer, der Dir aufgrund Deiner obigen Angaben Helfen kann, kann sicher 
auch fast alle anderen Probleme dieser Welt lösen! Den sollten wir zum 
Bundeskanzler machen -- vielleicht kann er mir auch die nächsten 
Lottozahlen sagen?

Aber mal im Ernst:
Meine freie Firmware für den AT90USB bezeichnest Du als "Etwas 
unübersichtlich, aber ist ja Geschmackssache..."

Meinst Du denn ich habe da absichtlich viel Code eingestreut, damit 
alles schön unübersichtlich und lang wird?

Wenn Du Teile von meinem Code irgendwie mit Atmels Code vermischt bzw. 
Teile weglässt wird es wahrscheinlich nicht funktionieren.

Du drückst Dich stets davor anzugeben was Du überhaupt machen willst, 
welchen Code Du als Grundlage benutzt und machst aus Deinen eigenen Code 
ein großes Geheimnis. Ich habe jedenfalls keine Glaskugel und auch keine 
Zeit zum munteren Raten.

Gruß

Stefan Salewski

[Ugene (Gast)]

> Einer, der Dir aufgrund Deiner obigen Angaben Helfen kann, kann sicher
> auch fast alle anderen Probleme dieser Welt lösen! Den sollten wir zum
> Bundeskanzler machen -- vielleicht kann er mir auch die nächsten
> Lottozahlen sagen?

Bei meinen obigen Angaben wollte ich nicht den ganzen Code hinhauen - 
was sowieso keiner durchlesen würde. Mir gings einfach darum eine groben 
Überblick zu geben was ich schritt für schritt mache.

> Aber mal im Ernst:
> Meine freie Firmware für den AT90USB bezeichnest Du als "Etwas
> unübersichtlich, aber ist ja Geschmackssache..."
> Meinst Du denn ich habe da absichtlich viel Code eingestreut, damit
> alles schön unübersichtlich und lang wird?

Warum reagieren Sie denn so feindlich?
Es war doch kein persönlicher Angriff, sondern nur eine Bemerkung: z.B 
fehlen die Funktionsköpfe, man weiß beim ersten durchlesen überhaupt 
nicht welche parameter geändert werden, was ist rückgabewert, usw.
m Vergleich zum Atmel Code pflegen Sie anderen Still zB.: 
UsbDevEnableUpstreamResumeInt im Vergleich zu Atmel code 
Usb_dev_enable_upstream_resume_int usw.
Ich sage nicht, dass Ihr Code schlecht ist. Sondern für MICH, (also 
MEINEN Geschmack) unübersichtlich auf den ersten Blick gewesen.

> Wenn Du Teile von meinem Code irgendwie mit Atmels Code vermischt bzw.
> Teile weglässt wird es wahrscheinlich nicht funktionieren.

Ich versuche eigene Firmware zu schreiben, um vor allem USB 
kommunikation und die AT90USB richtig zu verstehen. Ich kann nürlich die 
freie Firmware copieren, aber es ist nicht der SInn der Sache.
Und: Es wird funktionieren!

> Du drückst Dich stets davor anzugeben was Du überhaupt machen willst,
Ich programmiere USB Schnittstelle auf AT90USB1287. Ziel ist es USB zu 
begreifen, AtmelController selbst zu Porgrammieren.

> welchen Code Du als Grundlage benutzt
Als Grundlage benutze ich Ihre freie Firmware und die Firmware von Atmel 
(at90usb128-demo-template USB Maus).

> und machst aus Deinen eigenen Code ein großes Geheimnis.
Soll ich denn zu jeder Frage 100 Zeilen Code reinstellen? Es geht doch 
ums Prinzip nicht um die Einzelheiten.
Ich hab noch nichts gefunden, dass mir vom 1. Punkt an, Schritt für 
Schritt erklärt: Zuerst das einschalten dann dies, dann hier abfragen...
Überall findet man gesamten Code aber niedrgend ein Ablaufdiagramm oder 
Ähliches damit die Struktur an sich klar wird.

>  Ich habe jedenfalls keine Glaskugel und auch keine Zeit zum munteren
>  Raten.
Ok, danke für Ihre Antwort. Ich habe zwar keine Glaskugel, aber ich 
merke schon dass Sie etwas angespannt auf die Fragen reagieren.

[Stefan Salewski (Gast)]

>Warum reagieren Sie denn so feindlich?

Du kannst mich gerne mit "Du" anreden, wie es hier im Forum allgemein 
üblich ist.

Ich reagiere nicht feindlich, sondern etwas genervt. Du postets hier im 
Forum seit vielen Monaten irgendwelche Fragen zum AT90USB, ohne soviel 
relevante Informationen anzugeben, dass Dir sinnvoll geholfen werden 
kann.

In Deinem obigen Posting ist ja nun endlich etwas Information enthalten, 
damit wird vieles klarer!

>Soll ich denn zu jeder Frage 100 Zeilen Code reinstellen? Es geht doch
>ums Prinzip nicht um die Einzelheiten.

Bei der USB-Firmware-Programmierung geht es eben doch oft um die 
Einzelheiten, oft um einzelne gesetzte Bits und darum, in welcher 
Reihenfolge mit welchem zeitlichen Abstand sie gesetzt werden!

Du hast jetzt ja immerhin angegeben, dass Du eine Kombination meiner 
freien Firmware mit der von Atmel (at90usb128-demo-template USB Maus) 
verwendest. Das kann doch keiner ahnen, insbesondere meine Firmware 
werden hier viele überhaupt nicht kennen!

Nein, den kompletten Code sollst Du hier nicht posten. Aber wenn Du oft 
Hilfe benötigst, wäre es sinnvoll ihn irgendwie zugänglich zu machen.

>Ich versuche eigene Firmware zu schreiben, um vor allem USB
>kommunikation und die AT90USB richtig zu verstehen. Ich kann nürlich die
>freie Firmware copieren, aber es ist nicht der SInn der Sache.
>Und: Es wird funktionieren!
>Ich programmiere USB Schnittstelle auf AT90USB1287. Ziel ist es USB zu
>begreifen, AtmelController selbst zu Porgrammieren.

Das hätte ich an Deiner Stelle ganz zu Anfang mal geschrieben. Ich war 
bis gestern davon ausgegangenen, dass du nur versuchst, den Atmel-Code 
irgendwie an Deine Bedürfnisse anzupassen.

Welche USB-Bücher hast Du denn zur Verfügung. Ich hatte ja H.J. Kelm 
empfohlen, das ist ganz brauchbar.

>Es war doch kein persönlicher Angriff, sondern nur eine Bemerkung: z.B
>fehlen die Funktionsköpfe, man weiß beim ersten durchlesen überhaupt
>nicht welche parameter geändert werden, was ist rückgabewert, usw.
>m Vergleich zum Atmel Code pflegen Sie anderen Still zB.:
>UsbDevEnableUpstreamResumeInt im Vergleich zu Atmel code
>Usb_dev_enable_upstream_resume_int usw.
>Ich sage nicht, dass Ihr Code schlecht ist. Sondern für MICH, (also
>MEINEN Geschmack) unübersichtlich auf den ersten Blick gewesen.

Das klingt schon ganz anders!
Mit den Funktionsköpfen ist es in der Tat Stil- oder Geschmackssache. 
Atmel verwendet sie, in der Unix-Welt werden sie eher selten verwendet. 
Ich habe mich schon sehr bemüht, meinen Code verständlich und 
übersichtlich zu gestalten, allein schon weil ich ihn in 10 Jahren auch 
noch selbst (wieder) verstehen will. Funktionsköpfe werden da aber nicht 
viel helfen. Ein paar Diagramme wären vielleicht ganz gut. Problem ist 
eben immer, dass man meist wenig Zeit hat, und dass die Firmware 
eventuell auch weiterentwickelt wird, dann muss man die ganze 
Dokumentation wieder anpassen. Ich müsste die Beschreibung auch 
unbedingt ins englische übersetzen, dass kostet mich auch wieder ein 
paar Tage.

Das sich meine Firmware stark von der Atmels unterscheidet, auch mit der 
Namensgebung, liegt daran, dass Atmels Firmware eben unfrei ist. Hätte 
ich da irgendwas übernommen, wenn auch nur Bezeichnernamen, hätte ich 
meine Firmwäre nicht unter einer freien Lizenz (GPL) freigeben können.

Ich arbeite übrigens derzeit nicht an USB, sondern an anderen Projekten. 
Daher habe ich die Einzelheiten meiner Firmware derzeit nicht so gut 
parat, und mit der (unfreien) Atmel-Firmware habe ich mich so gut wie 
überhaupt nicht beschäftigt. Aber jetzt, nachdem Du mehr Informationen 
preis gegeben hast (hatte schon gedacht, du arbeitest an einem 
Geheimprojekt) können Dir wahrscheinlich auch Andere helfen.

Gruß

Stefan Salewski

[Ugene (Gast)]

> Du postets hier im
> Forum seit vielen Monaten irgendwelche Fragen zum AT90USB, ohne soviel
> relevante Informationen anzugeben, dass Dir sinnvoll geholfen werden
> kann.
Grund dafür ist, dass nur sehr Wenige sich mit AT90USB beschäftigt 
haben. Deshalb bleiben meine Fragen oft unbeantwortet. Außerdem nutze 
ich dieses Forum erst seitdem ich mit meinem USB Projekt angefangen 
habe. Mir war vorher nicht klar, dass nur wenige an AT90USB interessiert 
sind.

> Das hätte ich an Deiner Stelle ganz zu Anfang mal geschrieben. Ich war
> bis gestern davon ausgegangenen, dass du nur versuchst, den Atmel-Code
> irgendwie an Deine Bedürfnisse anzupassen.

Hab versucht mich immer so kurz wie möglich zu fassen, um mein Problem 
besser zu extrahieren. Hat mich auch bis vor Kurzem keiner gefragt, was 
mein "Wissensstand" ist...

> Welche USB-Bücher hast Du denn zur Verfügung. Ich hatte ja H.J. Kelm
> empfohlen, das ist ganz brauchbar.

Ich benutze USB 2.0 von Jan Axelson, ist soweit alles verständlich, aber 
auch viele allgemeine Sachen (HOST, DLL, CHIPAUSWAHL ect.).
Dass du das Kelm Buch benutzt hast habe ich im Code gesehen. Die 
Hinweise auf jeweiligen Seiten im Buch ist eine gute Idee.

> Ein paar Diagramme wären vielleicht ganz gut. Problem ist eben immer,
> dass man meist wenig Zeit hat

Das ist Wahr. Sobald ein Codestück funktioniert, widmet man sich dem 
nächsten Problem, so geht es mir zur Zeit.

[Ugene (Gast)]

@Salewski
Suche jetzt schon seit fast zwei Tagen den BUG in meiner Firmware bzgl. 
des nicht empfangenen SETUP Befehls.

In Verlzweifelung, dass mein AT90USB harwareseitig nicht funktioniert, 
habe ich deine freie Firmware draufgespielt. Und folgendes beobachtet:

beim 1. Einstecken an Host kamm die selbe Meldung vom Windows, dass das 
Gerät beschädigt ist und nicht funktioniert usw. -> AT90USB rausgezogen, 
wieder eingesteck, Flash löschen, wieder beschreiben und es ging:

nach dem 2. Einstecken lief dan die Enumeration an, also SETUP wurde 
richtig empfangen. (Dies sehe ich an einer LED die ich einschalte, wenn 
enumeration-routine aufgerufen wird.)
Das Gerät wird richtig enumeriert: Windows fordert Treiber an.

Also Harware ist es nicht. Das ist schon mal gut. Nun widme ich mich 
ganz euphorisch wieder meiner Firmware zu...

[Stefan Salewski (Gast)]

>nach dem 2. Einstecken lief dan die Enumeration an,

Ist schon etwas seltsam.
Der AT90USB wird doch vorgabemäßig mit einem Atmel-USB-Bootloader 
ausgeliefert. Damit hat man doch schon mal eine Möglichkeit, die 
Hardware gleich zu Anfang zu testen. (Bei erster Inbetriebnahme, oder 
später, wenn man beim Reset einen bestimmten Pin auf Masse legt, ist der 
Bootloader aktiv. Wenn man natürlich einmal per ISP programmiert hat, 
hat man den USB-Bootloader überschrieben.)
Ich habe bisher nie mit Windows getestet, aber einige Male unter Linux 
etwas ähnliches erlebt: Wenn ich Atmels Bootloader aktiviere, und mit 
dem Linux-Tool DFU-Programmer (statt Atmels FLIP für Windows) Firmware 
per USB aufspielen wollte, wurde das Gerät nicht erkannt. Beim nächsten 
Versuch ging es dann wieder. Ich vermute zwei mögliche Ursachen:

1. DFU-Programmer verträgt sich nicht 100%tig mit Atmels Bootloader.

2. Mein 16-MHz-Quarz schwingt nicht immer ganz sauber an, daher könnte 
das USB-Timing unsauber sein.

Ich habe das nicht weiter untersucht, da es selten auftrat, und auch nur 
mit DFU-Programmer, jedoch nie mit meiner eigenen Firmware. Was man tun 
könnte: Statt 16-MHz-Quarz mit einem 8-MHz-Quarz arbeiten, das ist wohl 
unkritischer. Oder eventuell die FUSE-bits anpassen. Ich habe sie stets 
auf den DEFAULT-Einstellungen belassen, das ist aber optimal für 8-MHz. 
Für 16 MHz sollte man sie eventuell umstellen wie im Datenblatt 
angegeben.

Gruß

Stefan Salewski

[Ugene (Gast)]

> Statt 16-MHz-Quarz mit einem 8-MHz-Quarz arbeiten, das ist wohl
> unkritischer. Oder eventuell die FUSE-bits anpassen. Ich habe sie stets
> auf den DEFAULT-Einstellungen belassen, das ist aber optimal für 8-MHz.
> Für 16 MHz sollte man sie eventuell umstellen wie im Datenblatt
> angegeben.

Betriebsfrequenz, Prescaler und PLL, ich denke irgendwo hier liegt mein 
Fehler.

Ich betreibe AT90USB ebenfalls mit 16MHz. Ich setze Prescaler auf 0, 
ähnlich wie in deiner Firmware:

CLKPR = (1<<7);
CLKPR = 0;

Schon hier kann ich beim Debuggen (JTAGICE MKII) sehen, dass die bits im 
CLKPR sich gar nicht ändern. OK, im Datenblatt auf S.49 ist erklärt, 
dass Fuse CKDIV8 im ausgelieferten Zustand programmiert ist und somit 
die Änderung des Prescalers per Software ignoriert wird. Also lösche ich 
die FUSE und prescaler wird = 0 gesetzt. Soweit so gut.

Beim Starten der PLL für USB muss ebenfalls ein prescaler für PLL 
gewählt werden. PLL  muss 48MHz aus FCPU generieren. Dazu flührt man:
FCPU/ x  = 2MHz.
Dann werden 2MHz mit Faktor 24 multipliziert und man bekommt 48MHz. Der 
prescaler x muss also 16NHz/2MHz = 8 sein. Laut Tabelle auf S.51 muss 
PLLP2=1, PLLP1=1, PLLP0=0 sein.
Ich beachte alle diese Hinweise, aber meine Firmware funktioniert nicht. 
Ich vermute, dsss die PLL oder FCPU nicht ganz stimmen und somit das 
ankommende 48NHz- SETUP Signal nicht als solches detektiert werden kann.

Paradoxie:
Ich setze wieder Fuse CKDIV8, spiele deine Firmware auf. Schließe das 
Gerät an und es läuft. Beim Debuggen sehe ich, dass in deiner Firmware:

1. Prescaler für die FCPU keine Auswirkung hat (klar, weil CKDIV8 
gesetzt)
2. Prescaler für PLL widersprüchlich zu Angaben im Datenblat ist: 
PLLP2=1, PLLP1=0, PLLP0=1 (Ähnliches finde ich auch in Atmel-Firmware)

Ich verwende das Datenblatt 7593D–AVR–07/06

[Stefan Salewski (Gast)]

>Betriebsfrequenz, Prescaler und PLL, ich denke irgendwo hier liegt mein
>Fehler.

Ich hatte dein vorhergehendes Posting so verstanden, dass Dein Gerät mal 
funktioniert, mal nicht, also zufälliges Verhalten.

Darauf hatte ich mich bezogen.

Wenn Prescaler oder PLL falls gesetzt sind funktioniert USB nie, auch 
nicht ab und zu mal.

Bei USB ist das Timing recht kritisch, d.h. der Quarz muss sauber mit 
fester Frequenz schwingen. (Prescaler usw. muss natürlich auch passen.)

Vor ca. einem halben Jahr hatte hier jemand gepostet, dass der Quarz 
eventuell nicht sauber schwingt, wenn die FUSE-Bits nicht optimal sind. 
Ich hatte mich auf die FUSE-Bits für den Quarz bezogen. (Im Prinzip kann 
der Oszillator mit geringerer Amplitude Schwingen, um Energie zu sparen. 
Bei 16 MHz ist das aber evtl. ungünstig. Einige AVRs haben ein 
spezielles FUSE-Bit für die Amplitude, der AT90USB wohl nicht. Aber im 
Datenblatt ist angegeben was man einstellen soll. Ich glaube CLKOPT oder 
so war die Bezeichnung der Fusebits für den Oszillator, musst Du mal 
nachlesen.

Eine andere Möglichkeit wäre, wenn es mal geht und mal nicht: 
Uninitialisierte Variablen/Register mit zufälligem Inhalt.

[Stefan Salewski (Gast)]

>Ich glaube CLKOPT oder so

CKSEL3..1 meinte ich, Table 6-3 im Datenblatt auf Seite 43.
Für mehr als 8 MHz sollen die auf "111" stehen, was sie vorgabemäßig 
wohl nicht tun.

[Ugene (Gast)]

> CKSEL3..1 meinte ich, Table 6-3 im Datenblatt auf Seite 43.
> Für mehr als 8 MHz sollen die auf "111" stehen, was sie vorgabemäßig
> wohl nicht tun.

Das hatte ich übersehen. Als die FCPU  und PLL Prescaler anpasste, wurde 
mein AT90USB auch erkannt. Also lag der Bug daran, dass der PLL 
prescaler und der CKSEL nicht ganz richtig eingestellt waren. Die Freude 
ist nun unbeschreibbar!!

Nun habe das Gerät installiert, mittels LibUSB Win-32 und der editierten 
.INF datei. (Bild im Anhang). OK so weit kennt nur Windows mein Gerät.

Nun möchte ich zuerst eine LED auf dem Board steuern. Dazu werde ich 
bestimmte Comandos definieren: z.B 0 für AUS, 1 für EIN, 2 für BLINKEN 
usw.

Ich versuche zuerst mittels weiter unten stehenden Code AT90USB 
anzusprechen. Beim 1. Ausführen wird mein Gerät gefunden, wenn ich die 
Anwendung noch mal ausführe, wird das Gerät nicht mehr gefunden. Aber 
nach Ausstecken und erneutem Einstecken wird es gefunden.
Aber ich schließe das Gerät mit usb_close(handle) ordentlich ab.

Weiß jemand wo das Problem liegt?

// Usb Test.cpp : Definiert den Einstiegspunkt für die Konsolenanwendung.
//

#include "stdafx.h"
#include <windows.h>
#include <iostream> 
#include "usb.h"
#pragma comment(lib, "libusb.lib") 

#define VENDORID    0x03eb 
#define PRODUCTID   0x0001



struct usb_device *device_init( unsigned int vendorid, unsigned int productid )
{
    struct usb_bus *usb_bus;
    struct usb_device *dev;

    /* Generic USB library bus structure traversal */
    usb_find_busses( );
    usb_find_devices( );

    /* Scan device tree for vendor ID/product ID match */
    for ( usb_bus = usb_get_busses( ); usb_bus; usb_bus = usb_bus -> next )
    {
        for ( dev = usb_bus -> devices; dev; dev = dev -> next )
        {
            if (( dev->descriptor.idVendor == vendorid ) &&
                ( dev->descriptor.idProduct == productid ) )
                    return dev;
        }
    }

    return NULL;
}

int _tmain(int argc, _TCHAR* argv[])
{
  struct usb_device *usb_dev;
  usb_dev_handle *handle;


    /* Initialize USB library */
    usb_init( );

    /* Make initial connection */
    usb_dev = device_init( VENDORID, PRODUCTID );
    
  fprintf( stderr, "Initial connect --> " );
    if ( usb_dev == NULL )
    {
        fprintf( stderr, "Device not found\n" );
        printf( "\nPress any key to continue\n" );
    }
  else
    {
        fprintf( stderr, "Device found, VENDORID = %04x, PRODUCTID = %04x\n\n", VENDORID, PRODUCTID );
    handle = usb_open(usb_dev);
    usb_set_configuration(handle, 1);
    usb_claim_interface(handle, 0);

    usb_release_interface(handle, 0);
    usb_close(handle);
    fprintf(stderr, "DEVICE CLOSED\n");
  }
  int a;
  fprintf(stderr, "Press x to exit\n" );
  while (std::cin >> a) 
  {    
    if (a == -1) break;
    std::cout << "You entered " << a << '\n';
  }

  return 0;
}

[Stefan Salewski (Gast)]

>Beim 1. Ausführen wird mein Gerät gefunden, wenn ich die
>Anwendung noch mal ausführe, wird das Gerät nicht mehr gefunden. Aber
>nach Ausstecken und erneutem Einstecken wird es gefunden.

Ich hab jetzt deinen geposteten Code nicht angesehen (gerade wenig Zeit) 
aber das könnte das Problem mit DATA0 und DATA1 sein 
(Data-Toggle-Mechanismus).
Wurde hier schonmal gefragt in Verbindung mit Atmels Firmware für 
AT90USB und Windows und von mir kurz beantwortet, müsste vor ca. einem 
halben Jahr gewesen sein. Mit Google finde ich es nicht, da müsstetst Du 
mal selbst hier im Forum suchen.

Gruß

Stefan Salewski

[Ugene (Gast)]

danke für den Hiweis, ich glaube es schon mal gelesen zu haben. Mal 
sehen ob ich es wieder finde..

[Stefan S. (ssalewski)]

Es war dieser Thread:

Beitrag "AT90USB1287 BulkTransfer unter Linux mit libusb ?!"

[Ugene (Gast)]

Ich denke gemeint ist dieses Posting hier:
Beitrag "AT90USB1287 BulkTransfer unter Linux mit libusb ?!"
zielt eher auf Atmel-Code und Linux ab, also das Gegenteil was ich 
mache.

hier konnte ich noch weitere Infos einholen, bzgl. LibUSB-Win32:
http://www.nabble.com/LibUSB-Dev---Win32-f14233.html

ich hab die funktion usb_set_debug(X) eingesetzt. Es bewirkt folgendes, 
beim Ausführen des Testprogramms werden (je nach eingestellter Tiefe X) 
die Aktivitäten der LIBUSB.dll mit dokumentiert und im Fester 
dargestellt. Hab davon ein Screenshot im Anhang.

Wie man sieht, wird mein AT90USB am bus#0 erkannt (atmel VendorID). In 
der nächsten Zeile wird eine Fehlermeldung ausgegeben: sending control 
message failed. Ich denke LibUSB wird hier vom Betriebssystem geblockt 
o.ä.

Das Problem scheint am usb_set_configuration(handle, 1); zu liegen. Denn 
schon hier bekomme ich Rückgabewert = -22

Muss werde mal weiter recherchieren.

[Thomas P. (pototschnig)]

>> Du postets hier im
>> Forum seit vielen Monaten irgendwelche Fragen zum AT90USB, ohne soviel
>> relevante Informationen anzugeben, dass Dir sinnvoll geholfen werden
>> kann.
> Grund dafür ist, dass nur sehr Wenige sich mit AT90USB beschäftigt
> haben. Deshalb bleiben meine Fragen oft unbeantwortet. Außerdem nutze
> ich dieses Forum erst seitdem ich mit meinem USB Projekt angefangen
> habe. Mir war vorher nicht klar, dass nur wenige an AT90USB interessiert
> sind.

Ich wusste garnicht, dass es die USB-AVRs überhaupt schon gibt!? Wo 
kriegt man die denn her? Hab nur mal Preise gefunden ...

Ich bin stattdessen gleich auf die SAM7 umgestiegen, weil die mehr 
können und sogar günstiger sind als die AT90USB ...

Mfg
Thomas Pototschnig

[Ugene (Gast)]

> Ich wusste garnicht, dass es die USB-AVRs überhaupt schon gibt!? Wo
> kriegt man die denn her? Hab nur mal Preise gefunden ...

Hallo Thomas,
die AT90USB1287 gibt es schon seit Anfang 2006. Kaufen kann man z.B. bei 
Spoerle oder Farnell. Preise 10-15 Euro

[Ugene (Gast)]

> Muss werde mal weiter recherchieren.

Ich habe mit Debuggen und meiner Anwendung etwas rumgespielt. Auf der 
SUche nach dieser Stelle im Code, die diesen Fehler provoziert:

LIBUSB_DLL: error: usb_control_msg: sending control message failed, win error: Der E/A-Vorgang wurde wegen eines Threadendes oder einer Anwendungsanforderung abgebrochen.

Dazu fallen mir Zwei möglichkeiten ein:
#1: Irgendeine Standard Anfrage wird nicht mit Handshake beantwortet 
(danach habe ich bisher gesucht)
#2: Es liegt an dem Toggle von DATA0 und DATA1. Diese Variante habe ich 
nciht gleich verfolgt, weil 
Beitrag "AT90USB1287 BulkTransfer unter Linux mit libusb ?!"
diesem Posting nach, führt es unter Linux zum Problem, ich dagegen 
versuche es mit WindowsXP.

Es liegt also nicht wie vorher vermutete an

usb_set_configuration(handle, 1);

sondern noch frührer: sendig_control_msg failed. Das heißt PC sendet 
eine Control Message. Was ist das, Control Transfer? Wenn ja, muss ich 
mich in PC-Anwendung darum kümmern? ICh denke EP0 ist automatisch 
Control Transfer, den habe ich auch so in der FIrmware definiert. Und 
die Enumeration läuft über EP0 problemlos.

=> Werde mal weiter recherchieren und debuggen bis ich umfalle.