AT90USB162 Endpoint Interrupts funktionieren nicht

Marvin K. schrieb:
> Mein AT90USB wird von Windows als USB Gerät erkannt, die generellen USB
> Interrupts werden korrekt aufgerufen und der USB Controller + Endpunkte
> konfiguriert, aber nach einigen Sekunden sagt Windows, das der AT90
> nicht auf die Anforderung einer Gerätebeschreibung reagiert hat (SETUP
> Packet ist wurde nicht beantwortet).

Ich sehen in dem Code oben keine korrekte Implementation des 
nicht-trivialen EP0, über den alle Desktriptoren abgerufen werden.

Ein Code 43 ist dann die normale Reaktion von Windows.

Die PLL Initialisierung ist auch irgendwie komisch. Welchen Quarz bzw 
Clock benutzt du?

Beitrag "Re: AT90USB162 Endpoint Interrupts funktionieren nicht"

(Ich weis nicht ob ich das mit dem Verweisen auf einen Beitrag richtig 
gemacht hab)

Ich nutze einen 8MHz Quartz, laut dem Datenblatt des uCs müsste ich die 
PLLP0-PLLP2 Bits des PLL Registers dann auf 000 setzen, ich habe das im 
Beispiel in 3 einzelnen Zeilen gemacht, da ich die beiden verschiedenen 
Einstellungen getestet hab, man könnte es aber auch in eine Zeile 
schreiben oder weg lassen (000 ist Standart soweit ich weis).

Beitrag "Re: AT90USB162 Endpoint Interrupts funktionieren nicht"

Ich konfiguriere EP0 doch im USB_GEN_vect Interrupt, oder hab ich da was 
falsch verstanden?

1

UENUM = 0;              // EP0 Anwählen

2

UECONX |= (1 << EPEN);        // EP0 Aktivieren

3

UECFG0X = 0;            // Controll-EP

4

UECFG1X = 16;            // 16 Byte, one Bank

5

UECFG1X |= (1 << ALLOC);      // Allocate memory

6

while (UESTA0X & (1 << CFGOK) == 0);// Warten auf "CFGOK"

Ich habe hier die Fehlererkennung wenn das setzen des ALLOC Bits 
fehlschlägt weggelassen, damit der Code übersichtlich bleibt, und die 
aktuelle Konfiguration scheint ja auch zu Funktionieren (CFGOK wird 
gesetzt).
Und ich hab auch schon verschiedene Konfigurationen für UECFG1X 
ausprobiert, diese hier hab ich aus einem Beispiel-Code von GitHub.

Wenn ich hier was falsch habe, wäre das schonmal ein großer Vorschritt, 
ich finde nämlich kaum Infos zum konfigurieren der Endpunkte, das ist 
das einzige was ich finden konnte.

Marvin K. schrieb:
> Ich konfiguriere EP0 doch im USB_GEN_vect Interrupt, oder hab ich da was
> falsch verstanden?

ja und die LED1 geht ja auch an wie du selbst schreibst. Es gibt aber 
keinerlei Code für die Chapter9 Requests.
Du must mindestens GetDescriptor(Device und Config), SetAddress() und 
SetConfig implementieren, zusätzlich ist es hilfreich den USB Reset 
auszuwerten und dort alle wichtigen Variablen zurücksetzen.
Solange das nicht implementiert ist enumeriert nichts. Wo sind den deine 
Deskriptoren?

Der Ablauf unter Win ist etwa folgender
- UsbReset
- GetDescriptor(Device)
- UsbReset
- SetAddr()
- GetDescriptor(Device)
- GetDescriptor(Configuration)
- SetConfig()

Ich weis, das hab ich aber in diesem Beispiel weg gelassen, wie ich oben 
schon geschrieben habe, das Problem ist das die USB_COM_vect Interrupts 
nicht funktionieren, ich kann diese Requests ja nicht einfach wahllos 
senden, sondern muss auf das SETUP des Hosts warten, ich empfange aber 
keins -> LED 2 leuchtet nicht.

Zusammengefasst bin ich an dem Punkt wo ich auf das erste SETUP Request 
des Hosts warte, aber irgendwie keins bekomme.

nun das Datenblatt sagt
CONTROL endpoints should not be managed by interrupts, but only by 
polling the status bits

Das hast du wohl auch probiert aber die EP Nummer nicht auf 0 gestellt.

Oh, das habe ich in dem Beispielcode tatsächlich vergessen, aber ich hab 
es gerade ergänzt, und wie in den Vorherigen versuchen auch, keine 
änderung:

1

while (1)

2

{

3

  UENUM = 0;

4

  if (UEINT & (1 << RXSTPI)) PORTD |= (1 << LED_2);

5

}

Das entsprechende Bit wird einfach nie gesetzt.

Ich muss ehrlicher weise zugeben dass ich kein ATMega Profi bin. Der 
Initialisierungsteil sieht aber für mich ok aus, auch wenn die magic 
numbers nicht so mein Ding sind.

Dann bleibt natürlich noch D+ und D- vertauscht als Fehler Quelle oder 
eine fUSB != 48Mhz. Wobei ich sagen würde die PLL passt für 8 MHz und 
ext. Quarz

Edit: Muss da nicht irgendwo der Usb Speicherblock eingestellt werden. 
So kenne ich das jedenfalls von anderen Chips.

Also, egal was ich bisher gemacht habe, ich habe noch keinen einzigen 
Endpoint Interrupt zum auslösen gebracht (sowohl USB_COM_vect, als auch 
die Bits im Register).

Und was meinst du mit Speicherblock ?
Ich kenne nur die Einstellung ob es eine "one Bank" oder eine "double 
Bank" ist, da ich bisher nicht wirklich rausfinden konnte, was damit 
überhaupt gemeint ist, hab ich es wie in allen Beispielen die ich bisher 
gefunden hab auch, bei "one Bank" belassen.

nochwas 16 Byte EP0  Fifo ist nicht so üblich ich mach immer 8 Bytes.
Es fehlt m.M. noch ein EpFifo Reset
UERST= 1; EP0 Fifo
UERST= 0;

Thomas Z. schrieb:
> nochwas 16 Byte EP0  Fifo ist nicht so üblich ich mach immer 8 Bytes.

Sicher?

Ich habe hier nur Code für die größeren USB-AVRs, aber da habe ich 16 
Byte für den Interrupt-EP (der bei CDC zwingend vorhanden sein muss, 
auch wenn er nichts macht) und 64 Byte für alle anderen EPs.

Auf Anhieb sehe ich jetzt auch nichts. Ich gehe mal davon aus, dass die 
PLL einrastet, weil ansonsten auch die erste LED wohl nicht angehen 
sollte.

Jörg W. schrieb:
> Sicher?

ja ganz sicher BULK EPs sind immer 64Byte das ist sogar in der Spec für 
fullspeed vorgeschrieben. Control mach ich immer 8 Bytes, den unnützen 
Interrupt EP bei CDC auch. Das vor allem weil bei den meisten Chips nur 
begrenzt Fifo Ram vorhanden ist.

Das macht zwar den GetDescriptor Request etwas langsamer weil ev. 
mehrere DataStages notwendig sind aber damit kann ich leben. Oft werden 
64Bytes für den Control Ep nur dehalb verwendet, weil die FW nicht mit 
mehren DataStages korrekt umgehen kann.

@Marvin
OneBank / TwoBank heist bei anderen Chips double buffer.
Zum Speicher siehe 19.6 Memory management.

Thomas Z. schrieb:
> Oft werden 64Bytes für den Control Ep nur dehalb verwendet, weil die FW
> nicht mit mehren DataStages korrekt umgehen kann.

Nö, das funktioniert bei mir schon, irgendeine der SETUP-Geschichten 
passt auch in 64 Byte nicht mehr direkt rein.

Andererseits haben die großen USB-AVRs deutlich mehr FIFO. Die kleinen 
haben nur 176 Bytes, wenn man 2 x 64 für die Daten-Endpunkte abzieht, 
bleiben nur noch 48 für den Rest. 8 verplempert man für den 
Interrupt-EP, damit kann der Control-EP aber trotzdem noch 16 oder 32 
Byte groß sein.

Double buffering fällt bei dem bissel FIFO sowieso aus.

Also, mein Code sieht jetzt so aus:

1

#include <avr/io.h>

2

#include <util/delay.h>

3

#include <avr/interrupt.h>

4

5

#define LED_1 PD4

6

#define LED_2 PD5

7

8

ISR(USB_GEN_vect, ISR_BLOCK)

9

{

10

  uint8_t uint = UDINT;

11

  UDINT = 0;

12

  if (uint & (1 << EORSTI))

13

  {

14

15

    UERST = 31;              // Reset FIFO

16

    UERST = 0;

17

18

    UENUM = 0;              // EP0 Anwählen

19

    UECONX |= (1 << EPEN);        // EP0 Aktivieren

20

    UECFG0X = 0;            // Controll-EP

21

    UECFG1X = 0;            // 8 Byte, one Bank

22

    UECFG1X |= (1 << ALLOC);      // Allocate memory

23

    while (UESTA0X & (1 << CFGOK) == 0);// Warten auf "CFGOK"

24

25

    PORTD |= (1 << LED_1);

26

27

  }

28

}

29

30

int main(void)

31

{

32

33

  DDRD |= (1 << LED_1) | (1 << LED_2);

34

35

  PLLCSR = 

36

  PLLCSR |= (1 << PLLE);

37

  while ((PLLCSR & (1 << PLOCK)) == 0);

38

  USBCON |= (1 << USBE);

39

  USBCON &= ~(1 << FRZCLK);

40

  UDCON &= ~(1 << DETACH);

41

42

  sei();

43

  UDIEN |= (1 << EORSTE);

44

  UEIENX |= (1 << RXSTPE);

45

46

  while (1)

47

  {

48

    UENUM = 0;

49

    if (UEINT & (1 << RXSTPI)) PORTD |= (1 << LED_2);

50

  }

51

52

}

Aber es hat sich nichts geändert, ich hab auch schon alle möglichen EP0 
FIFO Größen ausprobiert, und auch schon diverse andere Einstellungen 
variiert, es bleibt dabei das weder ein Interrupt noch das RXSTPI Bit 
gesetzt wird, ich auch schon D+/D- getauscht um diesen Fehler 
auszuschließen.

Ich habe übrigens auch mit dem Windows Tool USBView mal versucht ein par 
Infos zu erhalten, es sagt allerdings nur FailedEnumeration und ERROR No 
open Pipses, kann das mit dem Endpunkt zusammenhängen, oder liegt das 
nur an dem Fehlenden SETUP Package ?

USBView Ausgabe als Bild im Angang.
Die Ausgabe ist immer identisch, egal ob ich die Requests implementiere 
oder nicht, oder welchen Code ich verwende.

solange bist du noch lange nicht. USB View kann erst funktionieren wenn 
dein Device zumindest halbwegs durch die EMUM kommt.

Hat eventuell jemand einen Beispielcode für den AT90USB162 der 
Funktioniert?

vielleicht hilft das weiter.
https://stackoverflow.com/questions/7946244/cdc-demo-com-port-code-on-at90usb162-minimus-avr

Nicht wirklich, ich kann kein Chinesisch (Übersetzen geht nicht, das 
sind offenbar Bilder), und die anderen Links führen alle zu "404 Seite 
nicht gefunden" ...

http://www.ssalewski.de/AT90USB_firmware.html.de

Ich wollte mich eigentlich nicht mit LUFA beschäftigen, ich habe es mal 
ausprobiert, und ca 500 Fehlermeldungen über nicht vorhandene 
Definitionen und Fehlende Dateien bekommen (hab eines der Beispiel 
Projekte geöffnet).

Generell war mein Ziel eigentlich mir selber eine minimalistische 
Bibliothek für diverse USB Projekte erstellen wollte.

Marvin K. schrieb:
> Generell war mein Ziel eigentlich mir selber eine minimalistische
> Bibliothek für diverse USB Projekte erstellen wollte.

Das ist an sich auch kein schlechter Ansatz. Habe ich damals in μracoli 
auch gemacht, nachdem ich mir andere Beispiele angesehen habe und als zu 
komplex fand.

Muss heute Abend mal schauen, ob ich für die kleinen AVRs noch was 
finde.

Schau mal, das hier habe ich noch gefunden. Das stammt von

https://www.circuitben.com/node/4

(Das entsprechende Interface hatte ich mir damals für meinen Tek492 
gebaut.)

Die Funktionen read_reg() und write_reg() gehen auf den 
Mikrocontroller-Bus des Tek492, den man auf diese Weise über USB (über 
ein vendor class device) zugreifen kann.

Das alles sollte doch klein und fein genug sein, als Basis für 
Experimente zu dienen, denke ich mal. Ich habe auch noch ein kleines 
Devboard mit einem AT90USB162 da liegen. Falls du nicht weiter kommst, 
kann ich damit auch ein wenig spielen.

Ich werde das morgen mal Ausprobieren.

Ich hätte da noch ne kure Frage, die nur indirekt mit dem Problem zu tun 
hat, ich wollte gerade mal einen Schaltplan in KiCad erstellen von dem 
aktuellen Aufbau mit dem AT90USB, allerdings hab ich eine verbuggte 
globale Bibliothek die das Importieren meiner ganzen Bauteile (Darunter 
der AT90) verhindert, weis einer wie man Bibliotheken in KiCad löscht 
(finde dazu nichts im Internet) ?

Erstens kannst du sie natürlich über Preferences -> Manage Symbol 
Libraries warten. Zweitens kannst du auch ganz brutal mit dem File 
Manager die entsprechende Datei aus dem Weg räumen. Das gibt dann 'ne 
Warnung, aber danach geht es weiter.

Danke, ich hab es dauernd über diesen Bibliothekseditor versucht, aber 
der dient wohl nur zum Anzeigen der Bibliotheken, und die Datei löschen 
geht nicht, da ich keine Datei habe, das ist das Problem mit der 
Bibliothek, die lag auf einer Festplatte die nicht mehr Existiert.
Ich konnte sie aber über die Einstellungen löschen.

Ich habe eben mal den Code (usb_429) auf den AT90 geladen, hat ohne 
Probleme geklappt. Ich hab es einfach mal am PC eingesteckt, es wurde 
wieder nicht erkannt, mir ist schon klar das ich wahrscheinlich ein par 
Anpassungen vornehmen muss, ich wollte nur mal testen ob was passiert. 
Und eine Sache hat sich verändert, ich weis aber nicht ob das was zu 
bedeuten hat:

USBView zeigt jetzt etwas mehr Infos an, es sagt jetzt
"Companion Port Number: 10"
und
"Companion Hub Symbolic Link Name: USB#ROOT_HUB..."

Bei meinen vorherigen Versuchen waren diese Felder immer 0 oder gar 
nicht Vorhanden.

Marvin K. schrieb:
> USBView zeigt jetzt etwas mehr Infos an, es sagt jetzt
> "Companion Port Number: 10"
> und
> "Companion Hub Symbolic Link Name: USB#ROOT_HUB..."

das ist weil u nun einen anderen Port benutzt und hat nichts zu sagen.
Ich gehe dvon aus das der Code von Jörg auch ohne Änderungen läuft.

Du hast ein HW Problem (kaputtes Kabel, falsche Verbindung, D+, D- 
vertauscht)

Ich glaube auch das es irgend was mit der Hardware zu tun hat, da ich 
noch weiter AT90USB habe, werde ich später mal einen anderen testen, ich 
bezweifle nämlich das einer der Der Wiederstände oder Kondensatoren 
einen Fehler hat (habe ja mit dem Multimeter mal alle Spannungen und mit 
dem Oszilloskop D+ und D- gemessen).

Ansonsten zeigt der Code auch nach dem ich alle Vendor Requests und I/O 
Pins deaktiviert habe (so das nur noch der SETUP und Request Teil 
läuft), exakt das selbe verhalten, bis zum USB_GEN_vect EORSTI läuft 
alles, aber das RXTSPI Bit wird nicht gesetzt.

Mir ist auch aufgefallen das der Setup Teil hier über das USB_COM_vect 
Interrupt gehandelt wird, ich dachte das sollte sp nicht sein.

Ich zeichne jetzt wo ich meine KiCad Bibliothek laden konnte mal kurz 
einen Schaltplan von meinem Aufbau, eventuell liegt da ja ein Fehler den 
ich nicht finde.

Ich hab meinen Versuchsaufbau mal als Schaltplan gezeichnet, alles ist 
auf einem Steckbrett aufgebaut, und mit Jumper-Kabeln verbunden.
Ich konnte durch Messungen bisher keine Elektrischen Fehler feststellen, 
aber
2 Besonderheiten sind zu beachten:

1. Ich hatte keinen 22 Ohm Wiederstand für die D+/D- Leitungen, und habe 
daher 2 11 Ohm Wiederständer genommen, sollte aber eingendlich kein 
Problem sein, oder ?
Beide Leitungen haben jetzt einen Wiederstand von 20 Ohm (Habe durch 
Messungen mit einem Multimeter versucht, zumindest gleiche Werte durch 
Variieren der Wiederstände zu bekommen, auf 22 Ohm hab ich es nicht 
bekommen).

2. Der AT90USB162 ist nicht in einem DIL/DIP Gehäuse erhältlich, ich 
habe eine Adapterplatte gefräst und ihn aufgelötet.
Ich habe alles durchgemessen und die Kontakte sind soweit ich das sagen 
kann alle in Ordnung, nur ein I/O Pin hatte ein Problem (Beschädigte 
Lötstelle), aber den benutze ich in der Schaltung nicht.

Ein Annotationsfehler hat die Wiederstandswerte überschrieben, ich 
musste den Schaltplan neu hochladen, allerdings hab ich nicht 
rausgefunden wie ich den Fehlerhaften lösche.

Die Widerstände sind nicht besonders kritisch. Kritischer würde ich 
sehen dass nicht alle Gnds und Vcc angeschlossen sind. Aber das müssen 
Leute kommentieren die sich besser mit AVR auskennen.

Thomas Z. schrieb:
> Kritischer würde ich sehen dass nicht alle Gnds und Vcc angeschlossen
> sind.

Sie müssen alle angeschlossen und alle abgeblockt sein – am besten 
gleich auf der Adapterplatine. Kleine SMD-Cs lassen sich direkt zwischen 
die Pins löten.

Mir ist auch gerade nicht klar, ob das nun "bus-powered" oder 
"self-powered" sein soll. Die entsprechenden grundsätzlichen 
Applikationsschaltungen finden sich im Datenblatt, mit Varianten für 
unterschiedliche Versorgungsspannungen.

Leider gibt's für das "Minimus AVR USB"-Board, welches ich habe, keine 
Schaltpläne und auch nur noch eine historische Version der Webseite:

https://web.archive.org/web/20140105020019/http://www.minimususb.com/

Ich ich habe alle VCC und GND abgesehen von den für die Analog Sachen 
angeschlossen, ich habe gerade bemerkt das da noch ein Fehler im 
Schaltplan ist (UGND nicht angeschlossen).

Ich habe gerade mal die Adapterplatte mit dem AT90USB vom Steckbrett 
entfernt, und alle Löstellen neu angelötet, ich habe vorher und nachher 
die Wiederstände gemessen, und keine wirkliche Änderung festgestellt.
Alle bei ~0 Ohm (ein Standard Multimeter ist halt auch nicht so genau, 
denke ich mal)

Ich habe den Chip wieder eingebaut, und nochmal mit dem PC verbunden, 
dieses mal wurde er erkannt, beide LEDs leuchten und USBView zeigt die 
Descriptoren an.

Ich weis nicht was das Problem war und was es behoben hat, aber ich 
vermute mal ein Wackelkontakt bei einem der Pins, der durch die 
Messspitze des Multimeters immer zusammengedrückt wurde, und daher bei 
der Messung immer als OK durch ging.

Ich werde jetzt nochmal meinen original Code drauf spielen, mit eigenen 
Descriptoren und Requesthandler.

Interesant, laut USBView hängt mein Code nach dem ersten Descriptor.
Es wartet auf den nächsten und zeigt "Enumerating" an, ich hätte nicht 
gedacht das Windows so eine Geduld hat und jetzt bestimmt schon 20 
Sekunden wartet, bis es einen Fehler anzeigt.

Auf jeden fall funktioniert jetzt die Hardware, ich werde mich dann mal 
weiter mit dem Code beschäftigen, und diesen Fehler beheben.

Mein Code läuft jetzt übrigens wie auch das Beispiel "usb_429" (ich weis 
leider nicht den richtigen Name des Projektes) komplett über Interrupts, 
also auch die Setup Requests, auch wenn es laut USB Spezifikation nicht 
gewollt ist, scheint es problemlos zu funktionieren.

Marvin K. schrieb:
> Ich ich habe alle VCC und GND abgesehen von den für die Analog Sachen

Auch AVcc muss angeschlossen sein. Dient bei diesem AVR insbesondere 
auch der Spannungsversorgung der PLL.

Also, die Hardware funktioniert jetzt, aber beider Software macht jetzt 
nichts sinn.
Der Beispielcode funktioniert, aber selbst wenn ich nur ein par 
konstanten verschiebe, nicht ändere nur z.B. ganz oben im Code sammle, 
funktioniert es nicht mehr (es kompiliert und lässt sich aufspielen, 
aber der AT90 wird dann nicht mehr erkannt).
Es wäre mir neu das das ändern der reinfolge der Konstanten eine 
änderung ihres wertes zur folge hat (ich rede von einfach Konstanten wie

1

#define INTF_SIZE 9

).

Ich werde morgen nochmal von Grund auf neu anfangen, und versuchen zu 
verstehen was da vor sich geht.

Nur mal so: Compiler-Optimierung hast du eingeschaltet, ja?

Diese Einstellung kenne ich nicht, wo finde ich das den, und was bewirkt 
es ?

Ich hab den Code jetzt so weit, das ich die Requests empfange und 
auslesen kann (auch schon getestet, Daten werden richtig übertragen, ich 
empfange einen GET_DESCRIPTOR request).

Aber wenn ich dann antworte, und den DeviceDescriptor übergebe, bekommt 
ich nur immer wieder einen USB Reset vom host, das widerholt sich ca 4-5 
mal, dann bricht er ab und es kommt wieder "USB Gerät nicht erkannt".

USBView zeigt wieder überall 0 an, wobei ich nicht weis ob es überhaupt 
was anderes anzeigen würde bevor nicht ALLES korrekt übertragen wurde.

Was kann da die Ursache sein ?
Die Daten werden vom AT90 aus korrekt gesendet, ich hab es schon 
getestet, hier ist mein Code der das senden der Descriptoren übernimmt:

1

void writeUSB(const void* buffer, uint16_t length, uint8_t epsize)

2

{

3

  uint8_t sentBytes = 0;

4

  while (length--)

5

  {

6

7

    UEDATX = pgm_read_byte(buffer++);

8

    sentBytes++;

9

10

    if (sentBytes == epsize || length == 0)

11

    {

12

      sentBytes = 0;

13

      clr(UEINTX, TXINI);                

14

      while (!(UEINTX & ((1 << TXINI) | (1 << RXOUTI))));  

15

      if (UEINTX & RXOUTI) return;

16

    }

17

  }

18

19

  wfb(UEINTX, RXOUTI);

20

  clr(UEINTX, RXOUTI);

21

}

set und clr setzen bzw. löschen nur Bits in Registern.
wfb ist lediglich eine Funktion die so lange eine schleife ausführt, bis 
ein Bit gesetzt wurde.

Die Abfolge ist:

USB Reset
- Get Descriptor (Device)
USB Reset
- Get Descriptor (Device)
USB Reset
- Get Descriptor (Device)
USB Reset
- Get Descriptor (Device)
Abbruch -> Gerät nicht erkannt

Immer 4 mal (gerade durch einen Zähler ca. 10 mal geprüft)

Ja, ich weis wie das OS da reagiert, meine Frage ist ja ob jemand 
erkennt warum das so ist, ich hab den Code ja eingefügt.
Ich habe zum Test mal Stadt in den UEDATX in PORTD geschrieben, und ein 
delay eingefügt, und mir 8 LEDs angeschaut die an PORTD hängen.
Sie stimmten überein mit dem Descriptor den ich geschrieben hab, und der 
wiederum stimmt mit den USB Normen überein, also, wo ist hier das 
Problem ?

Hab ich vergessen wärend des Sendens irgend ein Bit zu setzen oder so ?

Marvin K. schrieb:
> Diese Einstellung kenne ich nicht, wo finde ich das den, und was bewirkt
> es ?

Dass der Code in vernünftiger Geschwindigkeit abgearbeitet wird und 
nicht in Zeitlupe.

> Was kann da die Ursache sein ?

Eben beispielsweise Timing-Probleme.

> Die Daten werden vom AT90 aus korrekt gesendet, ich hab es schon
> getestet

Womit hast du das denn getestet?

Wenn du mir einen compilierbaren Code gibst (also nicht nur Schnipsel), 
kann ich das hier auf meinem Demoboard mal nachvollziehen.

Ich hab den Fehler gerade gefunden, er war sowas von dämlich -.-
Ich hab im "typedef struct" Bereich vom Descriptor an einer stelle stadt 
uint16_t uint8_t genutzt, weshalb der Descriptor 1 Byte zu kurz war, und 
abgelehnt wurde, ich hab es korrigiert jezt wurde er erkannt und wird in 
USB View angezeigt.

Ich hab mich wahrscheinlich vertippt als ich den Aufbau aus der USB 
Spezifikation abgetippt hab und so ein Fehler fällt halt kaum auf 
zwischen den ganzen uint8_t und uint16_t ...

Na, das ist doch mal was.

Den Knopf für die Compileroptimierung solltest du trotzdem noch finden. 
Auf der Kommandozeile wäre das die Option -O1 oder -Os, aber vermutlich 
wirst du wohl irgendeine IDE benutzen, die den Compiler für dich 
aufruft.

Ich nutze Atmel Studio 7 bzw. Microchop Studio 7

Endlich, es kommt keine "USB Gerät nicht erkannt Meldung", das ist das 
erste mal das einer meiner Codes funktioniert. xD
Jetzt muss ich nur noch die ganzen Descriptoren und Requests 
implementieren die noch Fehlen, vieles in USB View ist deshalb noch mit 
"ERROR" markiert.

Ich werde gleich noch nach dieser Compiler Option suchen, ich denke mein 
Problem mit den Interrupts und dem AT90 ist jetzt gelöst.

Aber weis eigentlich jemand was es mit dieser vendorId auf sich hat?
Ich habe gelesen das die von USB Org vergeben wird, was sollte man den 
da nehmen wenn man kein "offizieller Hersteller" ist ?

Hm, wenn ich das einschalte (option -O2) wird mein AT90 nicht mehr 
erkannt und es kommt wieder nur schrott an (Device Descriptor wird 
abgelehnt).

Betrifft diese Option in irgend einer Form daten die im Programmspeicher 
abgelegt sind ?
Ich habe den Descriptor  mit __attribute__((packed)) im PROGMEM 
abgelegt.

Interesant, mit "optimize most (-O3)" geht es wieder.
Was sollte ich den nehmen?
Ich meine, bisher hat es auch mit der Standartoption "Optimize debugging 
experience (-Og)" funktioniert.

Marvin K. schrieb:
> Aber weis eigentlich jemand was es mit dieser vendorId auf sich hat?
> Ich habe gelesen das die von USB Org vergeben wird, was sollte man den
> da nehmen wenn man kein "offizieller Hersteller" ist ?

Da musst du dir was aus den Fingern saugen. Vielleicht einen Hersteller 
wählen, der inzwischen zurückgezogen hat.

Für die Vendor ID lediglich 16 Bits vorzusehen, ist eins der größten 
Gurken, die sich USB geleistet hat – zumal zu der Zeit, als sie das 
verbrochen haben, das Problem zur Neige gehender IPv4-Adressen schon 
längst auf dem Tisch lag. Es hätten wohl drei Finger genügt um 
abzuzählen, dass 65000 Hersteller weltweit ganz schnell erreicht sein 
werden.

Anfangs konnte man eine Vendor-ID noch für ein überschaubares Sümmchen 
"Verwaltungsgebühr" einkaufen, sollen am Anfang wohl USD 500 gewesen 
sein, lange Zeit waren es USD 1000. Wurde dann immer teurer.

Um das Übel für Kleinanwender/-hersteller (die im USB-IF halt keine 
Fürsprecher groß haben) noch zu verschlimmern: zu Zeiten, da der Preis 
noch moderat war, gab es ein paar Leutchen, die sich eine Vendor-ID 
erkauft haben und dann ein Mini-Geschäft damit aufgebaut haben, von 
dieser Vendor-ID Product-ID-Bereiche für kleines Geld weiter zu 
verkaufen. Denen hat das USB-IF unter Androhung juristischer 
Konsequenzen ihr Tun untersagt. (Ob sie diese Konsequenzen bspw. in 
Europa juristisch überhaupt hätten durch bekommen, angesichts dessen, 
dass sie ja die ID offiziell nicht verkaufen sondern "nur" eine 
"Verwaltungsgebühr" erheben, ist fraglich. Aber eine derart kleine Firma 
lässt es da halt nicht drauf ankommen.)

Marvin K. schrieb:
> Interesant, mit "optimize most (-O3)" geht es wieder.

Muss eigentlich mit jeglicher Optimierung zum Laufen zu bekommen sein, 
nur -O0 (Optimierung ausgeschaltet) ist fragwürdig.

Ich denke, du hast da noch irgendeine andere Sache drin.

Marvin K. schrieb:
> Ich habe den Descriptor  mit attribute((packed)) im PROGMEM abgelegt.

Das Attribut kannst du dir bei einem AVR klemmen. Das ist ein 
8-Bit-Prozessor, der hat keine Anforderungen an das Alignment, sodass 
alle structs immer "packed" sind.

c-hater schrieb:
> Auch wieder: Asm rules.

Ja klar.

Dann wäre er allerdings wahrscheinlich jetzt noch bei der Vorrede statt 
schon irgendwas zu haben, was am USB mitredet. ;-)

> Irgendwelchen Kram, der nach der Reinen Lehre verzichtbar ist und
> deswegen rausoptimiert wird.

Sowas simples wie ein vergessenes "volatile" wird es nicht sein. Er 
hatte ja zuvor -Og, nicht -O0.

Mutmaßen kann man viel. Wenn ich compilierbaren Code bekomme, schau ich 
mir das mal an (wenn's sein muss, finde ich auch einen Zugang zu einem 
USB-Analyzer). Atmel-Studio-Dateien brauch' ich nicht, benutze ich 
sowieso nicht. Ein Makefile wäre schön, wenngleich das vom Studio 
generierte erfahrungsgemäß grauenvoll ist.

Ich mache den Code erstmal soweit fertig das meine ganzen USB Sachen 
funktionieren, mit -Og funktioniert es ja, wenn das klapt, lade ich den 
Code mal hoch, es kann gut sein das gerade noch unnötiger Kram drin ist, 
weil ich an diversen Stellen Debug-Warteschleifen oder ähnliches drin 
hab.

z.B. wenn die Adresse gesetzt wurde, zeigt es das mit einer LED an und 
wartet eine halbe Sekunde.

Solche Sachen entferne ich jetzt halt nach und nach wenn ich weis das 
alles funktioniert.

Hä, ich habe gerade mal alle Descriptornafragen abgefangen die nicht 
behandelt wurden, weil kein entsprechender Descriptor implementiert ist, 
Windows fragt nach dem Descriptor mit der ID 0x06, es gibt aber keinen 
Descriptor mit 0x06 als ID oder ?

Ich hab jetzt
DEVICE 0x01
CONFIG 0x02
STRING 0x03
INTERFACE 0x04
ENDPOINT 0x05
(Hab die Zahlen gerade aus dem Gedächtnis aufgeschrieben, kann sein das 
was vertauscht ist)

Marvin K. schrieb:
> z.B. wenn die Adresse gesetzt wurde, zeigt es das mit einer LED an und
> wartet eine halbe Sekunde.

Wenn du in der Zeit wirklich wartest, kann das für USB schnell tödlich 
sein.

Der Host bekommt ganz schnell mal "kalte Füße", wenn da am anderen Ende 
keiner mehr reagiert. Zwar deckt der USB-Makro im Controller schon 
manches der zeitkritischen Dinge ab (indem er bspw. ein NAK sendet, wenn 
er noch keine neuen Infos von der Software hat), aber ganz allgemein 
gilt, dass man bei einer USB-Firmware "zeitnah" reagieren können sollte.

Aus dem Grunde ist es auch unpraktikabel, bei so einer Firmware groß mit 
dem Debugger ranzugehen: sowie du einen Breakpoint erreicht hast, 
schreibt der USB-Host das Device dann ab, weil es nicht mehr reagiert.

Wie eben gesagt: Ich entferne die sachen jetzt nach und nach wenn ich 
weis das alles funktioniert.
Das mit dem warten wenn die Adresse gesetzt wurde, war ja z.B. nur weil 
ich bisher nichts weiter implementiert hatte, jetzt wo ich weitere 
Sachen danach einbaue, kommt das natürlich weg.

Was ich aber festgestellt hab, was mich sehr verwundert hat:
Als ich eine Warte zeit beim senden der Daten hatte, um sie mir am PORTD 
ausgeben zu lassen, hat es Windows nicht gestört als ich zwischen den 
Bytes teilweise bis zu 500ms Wartezeit hatte, ich hätte da mit einem 
Abbruch gerechnet.
Scheinbar verkraftet Windows so große Wartezeiten manchmal sogar.

Marvin K. schrieb:
> Hä, ich habe gerade mal alle Descriptornafragen abgefangen die nicht
> behandelt wurden, weil kein entsprechender Descriptor implementiert ist,
> Windows fragt nach dem Descriptor mit der ID 0x06, es gibt aber keinen
> Descriptor mit 0x06 als ID oder ?

Auszug aus dem USB-2.0-Standard.

Wichtig ist, wenn du Dinge nicht implementierst (wie diesen device 
qualifier), dass du sie dann sauber ablehnst. Einfach nur "nichts tun" 
ist tödlich.

Passage aus meinem µracoli-Code dafür:

1

            if (!process_setup_message())

2

            {

3

                /*

4

                 * SETUP request not understood: STALL the current

5

                 * setup message, either during the data or status

6

                 * phase.  Automatically gets cleared when receiving

7

                 * the next SETUP packet.

8

                 */

9

                UECONX |= _BV(STALLRQ);

10

                UEINTX &= ~_BV(RXSTPI);

11

            }

process_setup_message() gibt false zurück, wenn sie keine Idee hatte, 
was die SETUP-Nachricht denn wollte. Eine Anfrage nach dem device 
qualifier descriptor würde bspw. dahin führen.

Das hab ich eingebaut, wenn ein Request nicht zugeordnet werden konnte, 
wird ein STALL zurückgegeben.

Ich habe alle Infos zu Descriptoren von einer anderen Webseite, wo es 
nur etwas vereinfachter erklärt wird, ich denke die haben das da einfach 
weggelassen, weil man es nicht unbedingt braucht.

Mein Code funktioniert jetzt zumindest soweit das ich alle wichtigen 
Deskriptoren übertragen kann, morgen mache ich noch die 
Endpunk-Deskriptoren und generell nicht-controll Endpunkte für 
spezifische Funktionen.

Da fehlt noch das Handling für SetConfiguration bzw GetConfiguration. 
USBView zeigt als ConfigValue 0 obwohl im Descriptor 1 steht. Ansonsten 
passt das, da du ja noch keine Pipes hast. Das Device kann dann halt nur 
auf Control Requests reagieren.
Wegen der IDs würde ich mir keinen Kopf machen. Falls das ein CDC wird, 
spielen die sowieso keine wesentliche Rolle. Ich nehme da immer 0xDEAD 
0xBEEF. :-)

Jörg W. schrieb:
> sollen am Anfang wohl USD 500 gewesen sein
200 USD Gebühr um etwa 1998. Danach zuerst 600 USD und eine ganze Zeit 
1000 USD.

Ich habe jetzt den ganzen Code in eine eigene .cpp datei verschoben, 
eine Include Datei erstellt und alles aufgeräumt, soweit funktioniert 
jetzt auch alles, nur 2 Probleme sind eben noch aufgetreten, die mir 
beide nicht viel sagen:

Das erste kommt nur sehr selten vor, wenn ich das Gerät z.B. 50 mal 
einstecke und wieder raus ziehe aus dem USB Anschluss de PCs, kommt in 
ca 1 der 50 Fälle wieder "Gerät nicht erkannt".
Ich habe wieder ein par Debug-LEDs eingebaut, und es scheint in einem 
von 50 Fällen nach dem senden des Device Deskriptors keine Antwort mehr 
zu bekommen, es hängt in der Warteschleife für das RXOUTI Bit nach dem 
senden fest, und bekommt keine Antwort vom Host.
Ich habe ein Timeout eingebaut, das es nur ca 2 Sekunden wartet, und 
wenn dann nichts kommt es den Vorgang abbricht, aber das ist denke ich 
nur eine vorübergehende Lösung.
Ich habe jetzt auch Compiler Optimierung an, nachdem ich alle Debug 
Sachen von vorher entfernt hab läuft das einwandfrei.
Kann es sein das das wirklich am host liegt, oder ist es warscheinlicher 
das in meinem Code ein Fehler vorliegt?
Ich mein, in ~ 90% der fälle funktioniert es ja, ich kann mir irgendwie 
nicht vorstellen das da ein "Fehler mit Zufallschance" drin ist.

Das 2. Problem tritt immer auf, USBView zeigt nämlich meine String 
Deskriptoren nicht am, es sagt immer "String Descriptor for index 1 not 
available while device is in low power state.".
Was genau bedeutet das?
Ich habe rausgefunden das das kommt wenn das Gerät länger nicht aktiv 
war, und daher in den Suppend-Mode gegangen ist, aber wärend der 
Konfiguration und Enumeration ist doch eigentlich dauerhaft Aktivität 
auf dem Bus oder ?

Ich sollte noch dazu sagen, jetzt wo das Timeout in der Warteschleife 
ist, wird es immer erkannt, aber es dauert halt in einem von 50 Fällen 
ungefähr 4 Sekunden bis es erkannt wurde, weil halt ein 2. versuch vom 
Host gestartet wird.

Set bez GetConfiguration nicht oder nicht richtig implementiert wie 
schon geschrieben.

UsbSpec: ein nicht configuriertes Gerät geht in den Powerdown mode.

Ich habe Set und Get Configuration eigentlich implementiert, ich hab 
garnicht bemerkt das da immer noch 0 steht, ich habe es eben mal wieder 
abgefangen und es wird gar kein SET_CONFIGURATION Request gesendet.

Ich empfange:
- USB Reset
- SET ADRESS
- GET DESCRIPTOR (mehrfach, für Device und Configuration denke ich mal)

Und dann nichts mehr
USB View zeigt was in dem Screenshot zu sehen ist.

Marvin K. schrieb:
> Ich empfange:
> - USB Reset
> - SET ADRESS
> - GET DESCRIPTOR (mehrfach, für Device und Configuration denke ich mal)

für Win ist das so nicht richtig, der Reset kommt mehrfach. Wenn du 
keinen SetConfiguration bekommst ist die Enum nicht abgeschlossen. 
Windows schickt dein device in den Suspend weil es nicht mit deinen 
Antworten zufrieden ist.

Wirf die Delays raus und merke dir den usbstatus in einer Variable.
So etwa StatePowered, StateReset,StateAddressed, StateConfigured, 
StateSuspended, (0..4)
Dann kannst du in deiner Mainschleife die LEDs über den usbstatus 
anzeigen.

Ich habe keine delays, und ich empfange mehrere Resets, ich habe nur den 
letzten hingeschrieben, da der erste ja ebenfalls nur ein GET_DESCRIPTOR 
ausführt.
Ich habe zuerst eine Abfrage an den Begin jedes Requests gemacht.

1

if (request.bRequest == xy) PORTD = 0xFF;

Wodurch ich verifizieren konnte das ich folgende Requests erhalte:
- GET_DESCRIPTOR
- SET_ADDRESS
Bei allen anderen blieben die LEDs Dunkel
Dann hab ich jedem Request nacheinander eine LED zugewiesen, und die LED 
gesetzt wenn ein solcher Request empfangen wurde, daher weis ich die 
Reihenfolge NACH DEM LETZTEN USB Reset:
- GET_DESCRIPTOR
- SET_ADDRESS
Aber wieder, kein SET_CONFIGURATION

Da alle Descriptoren ankommen und korrekt in USBView angezeigt werden, 
und auch die Adresse korrekt gesetzt wurde, kann es ja schonmal nicht an 
den von mir gesendeten Daten liegen (die sind ja angekommen).
Und andere Requests empfange ich nicht, aber irgendwo muss ja ein Fehler 
sein.

Setzt du beim UsbReset deine Device Addresse auf 0 zurück?

Oh, das mache ich tatsächlich nicht, hab ich vergessen, aber wie können 
dann alle Anderen Roquesits korrekt funktionieren, und dieser eine nicht 
?

Hab es eingefügt, aber es bleibt immer noch bei den beiden Requests, der 
SET_CONFIG Request steht weiter aus ...

nun dann kommt nur GetDescriptor(config) in Frage. Dir ist klar dass der 
bei dir 2 mal kommen muss?
1. Mit wLength = 0x0009
2. Mit wLength = 0x0012

Im ersten Fall darfst du nur die ersten 9 Bytes senden.

Anders gesagt:
Du darfst niemals mehr als wLength Bytes zurück geben aber weniger falls 
ein Descriptor kürzer ist

Das hab ich schon bedacht, ich prüfe es nochmal, aber eigentlich sende 
ich nur soviel wie gefordert.

Ich Empfange einmal ein GET_DESCRIPTOR mit einer wLength von 64 und 
einmal mit einer wLength von 18.
Das mit der 64 kommt daher das ich einen EPSIZE von 64 hab oder ?
Sollte ich das eventuell ändern ?

Der erste GetDescriptor(Device) kommt immer mit wLength = 0x0040. Das 
ist eine Eigenheit von Windows. Unter Linux und MacOs wäre das 0x0008.
Strings werden übrigens immer mit 0x0100 abgefragt.

Es könnte noch sein das deine Status Stage nicht ok ist.

Das müsste dann ja aber die nach dem letzten GET_DESCRIPTOR sein, das 
macht ja aber kein sinn, da die vorherigen auch alle akzeptiert werden, 
und auch korrekt in USBView angezeigt werden.
Alle GET_DESCRIPTOR anfragen nutzen den selben Code.
Gibt es eventuell ein Tool mit dem man noch mehr Infos als mit USB View 
bekommt ?
Beispielsweise weshalb die Verbindung unterbrochen wurde ?

Marvin K. schrieb:
> Gibt es eventuell ein Tool mit dem man noch mehr Infos als mit USB View
> bekommt ?

Erstens kannst du natürlich ein anderes OS nehmen und schauen, was die 
machen. Eventuell auch eins, bei dem man USB-Debugging einschalten kann 
… Ansonsten gibt's (teure) Hardware-USB-Analyzer. Dem Nutzernamen nach 
:) würde ich vermuten, dass Thomas sowas hat, ich könnte auch einen 
Zugang dazu auftreiben, denke ich. Wie schon mal beschrieben, brauche 
ich dann aber einen compilierbaren Sourcecode. Diese Geräte liefern 
ziemlich detaillierte Berichte, an welchen Stellen das Gerät sich nicht 
korrekt verhält.

Ok, also aktuell habe ich keinen PC zur Verfügung um sowas zu testen 
aber ich hatte schon länger mal vor eine VM für sowas einzurichten.

Ich lade den Code gleich mal hoch.

Hier ist der Sourcecode und der Makefile, ich weis nicht genau ob noch 
mehr Dateien von Atmel Studio 7 benötigt werden, aber genaugenommen 
würde ja sogar der Code alleine reichen, außer der Compiler Optimierung 
hab ich nichts verändert.

Ich sollte noch dazu sagen, das ich relativ neu in C++ bin, bisher hab 
ich hauptsächlich mit Java und Visual Basic programmiert, aber da Java 
und C sich relativ ähnlich sind, konnte ich recht schnell größere 
Programme schreiben (nicht nur für AVR).

Marvin K. schrieb:
> ich hatte schon länger mal vor eine VM für sowas einzurichten.

Wird in dieem Falle vermutlich nicht so viel helfen, denn der Host muss 
ja das USB-Gerät erstmal erkennen, bevor er in der Lage ist, es an den 
Gast weiter zu reichen.

Marvin K. schrieb:
> Hier ist der Sourcecode und der Makefile

(rant)
Oh ja, ich liebe diese Studio-generierten Makefiles. Mit ihren "Device 
packs" jetzt werden die immer schlimmer, da sie nun auch noch die 
-B-Option des Compilers verbiegen müssen. Außerdem überall die Programme 
mit vollständigem Pfad und .exe am Ende, damit es auch garantiert 
unportabel wird … Außerdem ist "all" nicht das erste Target, sodass ein 
simples "make" halt dann nicht alles baut wie sonst üblich.
(end-of-rant)

Ich bekomme folgende Warnungen und Fehler, wenn ich das compiliere:

1

avr-g++ -funsigned-char -funsigned-bitfields -DDEBUG  -Og -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=at90usb162 -c -MD -MP -MF "usbl.d" -MT"usbl.d" -MT"usbl.o"   -o "usbl.o" ".././usbl.cpp" 

2

In file included from .././usbl.cpp:13:

3

/usr/local/avr/include/util/delay.h:92:3: warning: #warning "F_CPU not defined for <util/delay.h>" [-Wcpp]

4

   92 | # warning "F_CPU not defined for <util/delay.h>"

5

      |   ^~~~~~~

6

.././usbl.cpp: In function ‘void readUSB(void*, uint16_t)’:

7

.././usbl.cpp:123:14: warning: ISO C++ forbids incrementing a pointer of type ‘void*’ [-Wpointer-arith]

8

  123 |   *(uint8_t*)buffer++ = UEDATX; // Read data in buffer

9

      |              ^~~~~~

10

In file included from .././config.h:12,

11

                 from .././usbl.cpp:12:

12

.././usbl.cpp: In function ‘void writeUSB(const void*, uint16_t, uint8_t, bool)’:

13

.././usbl.cpp:151:27: warning: ISO C++ forbids incrementing a pointer of type ‘const void*’ [-Wpointer-arith]

14

  151 |    UEDATX = pgm_read_byte(buffer++);

15

      |                           ^~~~~~

16

.././usbl.cpp:155:24: warning: ISO C++ forbids incrementing a pointer of type ‘const void*’ [-Wpointer-arith]

17

  155 |    UEDATX = *(uint8_t*)buffer++;

18

      |                        ^~~~~~

19

In file included from .././usbl.cpp:12:

20

.././config.h: In function ‘void __static_initialization_and_destruction_0(int, int)’:

21

.././config.h:64:29: error: variable ‘manufacturerString’ with dynamic initialization put into program memory area

22

   64 | const USB_String_Descriptor manufacturerString PROGMEM =

23

      |                             ^~~~~~~~~~~~~~~~~~

24

gmake: *** [Makefile:89: usbl.o] Error 1

Kann ich hier natürlich reparieren, aber ich frage mich, warum 
insbesondere letzterer Fehler bei dir nicht auftaucht. Du versuchst, in 
der Initialisierung ein strdup() einzubauen. Das geht so nicht. Das muss 
man als separaten String anlegen, auf den verwiesen wird. Denk auch 
dran, dass USB-Strings alle UTF-16 sein müssen.

Ich habe das jetzt erstmal so zusammen gehackt:

1

char manu[] = "T\0E\0S\0T\0";

2

const USB_String_Descriptor manufacturerString PROGMEM =

3

{

4

        .bLength = 2 + 4,

5

        .bDescriptorType = DESCRIPTOR_TYPE_STRING,

6

        .bString = manu,

7

};

Ultimativ wirst du die Strings aus den Descriptoren natürlich auch im 
PROGMEM haben wollen. Mir ist sowieso nicht klar, warum dein .bString 
nicht bereits const char * ist, aber das allein würde ja auch noch 
nicht helfen; die Routine, die den Descriptor liest, muss ja dann auch 
aus dem Flash lesen statt aus dem RAM.

(OK, wenn man den Descriptor dynamisch zur Laufzeit zusammen bauen 
können will, dann geht es mit const natürlich nicht.)

Außerdem erinnere ich mich, dass man noch einen String descriptor für 
die language #0 braucht, in dem dann drin steht, welche Sprachen alle 
unterstützt werden.

Auch das mit dem fehlenden F_CPU hätte dich stutzig machen sollen: du 
hast in main.cpp (aber nur dort) ein F_CPU definiert, allerdings auf 1 
MHz – fährst du die CPU denn mit 1 MHz? Fürs USB brauchst du ja einen 
8-MHz-Takt.

Warum dein buffer-Zeiger nicht gleich einer auf uint8_t ist, ist mir 
auch nicht klar.

Ach, das hab ich vergessen zu entfernen, bei den String-Descriptoren hab 
ich nur rumprobiert, ich Wuste ich hab was vergessen, bevor ich es 
hochlade -.-
Ich hatte die komplet entfernt als ich die Tests gemacht hab, aber am 
ende wieder eingefügt, als ich das Projekt geschlossen hab (um halt den 
Forschritt nicht zu verlieren).
Vergiss die einfach und lösch sie raus.
Den F_CPU hatte ich für die aller ersten Tests am Anfang mal gesetzt, um 
wenigstens irgend ein Delay zu haben (hab den Code aus der main eines 
anderen Projektes kopiert), hab auch das vergessen zu löschen.

Sowas passiert halt leider wenn man alles mögliche versucht um einen 
Fehler zu finden, und dann nicht alles rauslöscht ...

Also ja: die CPU läuft mit 8 MHz.

Und der Grund weshalb die String-Sachen so schlimm sind ist, das ich 
absolut keinen Plan hatte wie die funktionieren, das war das erste mal 
das ich einen String in C gebraucht hab, und in jeder anderen 
Programmiersprache hat man ja diverse Typen wie String oder 
StringBuilder, aber in C auf einem AVR hab ich sowas noch nie benutzt.

Naja, wie geschrieben, bei USB kommt noch dazu, dass du 16-Bit-Strings 
brauchst. Die normalen C-Strings sind halt erstmal 8 Bit pro Zeichen.

Ach, das wird einer der Gründe sein warum ich so viele Probleme damit 
hatte.
Hab ich wohl vergessen, aber wie gesagt, die String Descriptoren sind 
mir erstmal egal, ich will das die Konfiguration funktioniert.

Bei mir geht im Moment leider noch gar nichts, aber auch mit der anderen 
("known good") Firmware. Scheint irgendwie an FLIP zu liegen hier, muss 
ich später mal analysieren.

@Marvin

Zum AVR Code kann ich wenig beitragen. Das ist nicht meine Welt.

Aber:
Beim case stringdesc fehlt das Error flag und ein break.

OK. Der Punkt war, dass auf meinem Demoboard ein 16-MHz-Quarz verbaut 
ist, sodass ich die PLL anpassen musste.

Was mir übrigens nicht ganz klar ist, warum du sowas schreibst:

1

  set(PLLCSR, PLLP0);

2

  clr(PLLCSR, PLLP1);

3

  clr(PLLCSR, PLLP2);

4

  set(PLLCSR, PLLE);

statt einfach das Register in einem Rutsch zu schreiben:

1

        PLLCSR = _BV(PLLP0) /* | _BV(PLLP1) | _BV(PLLP2) */ | _BV(PLLE);

(_BV macht weiter nichts als die Bitmaske zu einer Bitnummer zu 
ermitteln. Der Name ist eher historisch, war in der avr-libc halt schon 
immer so.)

Manchmal hat es sicher Sinn sicherzustellen, dass eine bestimmte 
Reihenfolge bei den Bits gewährleistet ist, aber gerade hier sieht das 
m.E. in einer Zeile übersichtlicher aus. Die auskommentierten Bits 
sollen zeigen, dass genau diese Bits halt 0 bleiben.

Nun, an meinem FreeBSD benimmt sich das Teil jetzt völlig normal. Die 
Folge der Requests ist:

1

SETUP   0       1,894

2

  00 05 03 00 00 00 00 00

3

4

IN      0       1,894

5

6

7

SETUP   0       1,908

8

  80 06 00 01 00 00 08 00

9

10

IN      0       2,159

11

  12 01 00 02 FF 00 00 40

12

13

OUT     0       2,159

14

15

16

SETUP   0       2,162

17

  80 06 00 01 00 00 12 00

18

19

IN      0       2,413

20

  12 01 00 02 FF 00 00 40 FF 00 FF 00 00 01 00 00 00 01

21

22

OUT     0       2,413

23

24

25

SETUP   0       2,413

26

  80 06 00 02 00 00 09 00

27

28

IN      0       2,413

29

  09 02 12 00 01 01 00 C0 32

30

31

OUT     0       2,413

32

33

34

SETUP   0       2,413

35

  80 06 00 02 00 00 12 00

36

37

IN      0       2,414

38

  09 02 12 00 01 01 00 C0 32 09 04 00 00 00 FF 00 00 00

39

40

OUT     0       2,414

41

42

43

SETUP   0       2,414

44

  80 00 00 00 00 00 02 00

45

46

IN      0       2,414

47

  01 00

48

49

OUT     0       2,414

50

51

52

SETUP   0       2,415

53

  00 09 01 00 00 00 00 00

54

55

IN      0       2,415

An einem Windows sieht das nicht so grundlegend anders aus, außer dass 
halt zwei Windows-spezifische Anfragen jeweils mit einem STALL 
beantwortet werden. Den einen bezeichnet mein Analyzer als "String 
Microsoft OS", das andere ist dieser device qualifier.

1

SETUP   0       0,293

2

  80 06 00 01 00 00 40 00

3

4

IN      0       0,544

5

  12 01 00 02 FF 00 00 40 FF 00 FF 00 00 01 00 00 00 01

6

7

OUT     0       0,544

8

9

10

SETUP   0       0,635

11

  00 05 05 00 00 00 00 00

12

13

IN      0       0,635

14

15

16

SETUP   0       0,647

17

  80 06 00 01 00 00 12 00

18

19

IN      0       0,897

20

  12 01 00 02 FF 00 00 40 FF 00 FF 00 00 01 00 00 00 01

21

22

OUT     0       0,898

23

24

25

SETUP   0       0,905

26

  80 06 00 02 00 00 FF 00

27

28

IN      0       0,905

29

  09 02 12 00 01 01 00 C0 32 09 04 00 00 00 FF 00 00 00

30

31

OUT     0       0,905

32

33

34

SETUP   0       0,906

35

  80 06 EE 03 00 00 12 00

36

37

IN      0       0,906

38

39

40

SETUP   0       0,907

41

  80 06 00 06 00 00 0A 00

42

43

IN      0       0,907

44

45

46

SETUP   0       1,133

47

  80 06 00 01 00 00 12 00

48

49

IN      0       1,383

50

  12 01 00 02 FF 00 00 40 FF 00 FF 00 00 01 00 00 00 01

51

52

OUT     0       1,383

53

54

55

SETUP   0       1,384

56

  80 06 00 02 00 00 09 00

57

58

IN      0       1,384

59

  09 02 12 00 01 01 00 C0 32

60

61

OUT     0       1,384

62

63

64

SETUP   0       1,385

65

  80 06 00 02 00 00 12 00

66

67

IN      0       1,385

68

  09 02 12 00 01 01 00 C0 32 09 04 00 00 00 FF 00 00 00

69

70

OUT     0       1,385

71

[pre]

72

73

Zu guter Letzt noch Linux. Das fragt auch nach dem device qualifier, gleich dreimal :), bevor es dann doch ohne einen solchen weiter macht.

74

75

[pre]

76

SETUP   0       0,380

77

  80 06 00 01 00 00 40 00

78

79

IN      0       0,631

80

  12 01 00 02 FF 00 00 40 FF 00 FF 00 00 01 00 00 00 01

81

82

OUT     0       0,633

83

84

85

SETUP   0       0,744

86

  00 05 01 00 00 00 00 00

87

88

IN      0       0,745

89

90

91

SETUP   0       0,760

92

  80 06 00 01 00 00 12 00

93

94

IN      0       1,011

95

  12 01 00 02 FF 00 00 40 FF 00 FF 00 00 01 00 00 00 01

96

97

OUT     0       1,013

98

99

100

SETUP   0       1,014

101

  80 06 00 06 00 00 0A 00

102

103

IN      0       1,015

104

105

106

SETUP   0       1,016

107

  80 06 00 06 00 00 0A 00

108

109

IN      0       1,017

110

111

112

SETUP   0       1,018

113

  80 06 00 06 00 00 0A 00

114

115

IN      0       1,019

116

117

118

SETUP   0       1,020

119

  80 06 00 02 00 00 09 00

120

121

IN      0       1,021

122

  09 02 12 00 01 01 00 C0 32

123

124

OUT     0       1,023

125

126

127

SETUP   0       1,024

128

  80 06 00 02 00 00 12 00

129

130

IN      0       1,025

131

  09 02 12 00 01 01 00 C0 32 09 04 00 00 00 FF 00 00 00

132

133

OUT     0       1,027

134

135

136

SETUP   0       1,028

137

  00 09 01 00 00 00 00 00

138

139

IN      0       1,029

Summa summarum würde ich mal sagen, dass bis hier alles im grünen 
Bereich ist.

Das erklärt dann leider weder dieses Problem das ich durch einen Timeout 
lösen musste, noch dass ich keine String Descriptoren nutzen kann (oder 
anders gesagt, das die Konfiguration nicht gesetzt wird).

Wird sie denn bei deinen Tests korrekt gesetzt ?
Bei mir steht da halt 0x00 und das Gerät geht in diesen Susppend/Power 
Down mode.

Und zu diesen umständlichen Konfigurationen, ich weis das das 
umständlich ist, macht es aber einfacher mal kurz was zu ändern (einfach 
set durch clr z.B. ersetzen).
Wenn ich weis das alles Funktioniert wollte ich noch sowas wie btm (kurz 
für "bit mask") machen, wo ich dann z.B: schreiben kann

1

btm(PLLCSR, PLL0, 0, 1, 0);

Also quasi erst der Register, dann das Erste Bit und dann die Bits die 
von da aus gesetzt werden sollen.
Oder irgend was in der Art, das ist nur eine vorübergehende Lösung damit 
ich schnell Sachen ändern kann, wie gesagt in C besonders in AVR hab ich 
noch nicht so viel gemacht, meist nur Simple Sachen mit I/O Ports, und 
wenig mit größerer Register manipulation.

Der DeviceQualifier sollte verschwinden sobald usbBCD auf 0x0110 
gestellt wird.

Der 0xEE String ist unter Windows Teil der WinUSB Erkennung. MS stellt 
damit fest ob WinUSB als Treiber benutzt werden soll.

Marvin K. schrieb:
> Das erklärt dann leider weder dieses Problem das ich durch einen Timeout
> lösen musste, noch dass ich keine String Descriptoren nutzen kann (oder
> anders gesagt, das die Konfiguration nicht gesetzt wird).

Die String indices stehen derzeit ja alle auf 0, insofern werden keine 
string descriptors abgefragt.

Dass du für selbige noch bissel was tun musst, hatten wir ja schon 
diskutiert. Du brauchst einen String descriptor mit Index 0, bei mir 
sieht der so aus:

1

static struct string_descriptor_langs const PROGMEM string_descriptor_langs =

2

{

3

    .bLength = sizeof(struct string_descriptor_langs),

4

    .bDescriptorType = STRING_DESC,

5

    .wLANGID =

6

    {

7

        [0] = 0x0409            /* US English */

8

    }

9

};

und du musst die anderen ordentlich UTF-16 codieren.

1

{

2

    .bLength = sizeof(struct string_descriptor) +

3

        sizeof(USB_VENDOR_NAME) - sizeof(wchar_t),

4

    .bDescriptorType = STRING_DESC,

5

    .bString = USB_VENDOR_NAME

6

};

mit USB_VENDOR_NAME

1

#define URACOLI_USB_VENDOR_NAME  L"URACOLI"

Beim AVR-GCC sind wide strings standardmäßig 16 bit breit, daher geht 
das hier so.

> Bei mir steht da halt 0x00 und das Gerät geht in diesen Susppend/Power
> Down mode.

Power down erfolgt hier nicht, und die Konfiguration sah unter allen 
drei Ziel-Betriebssystemen erstmal soweit erfolgreich aus.

Thomas Z. schrieb:
> Der DeviceQualifier sollte verschwinden sobald usbBCD auf 0x0110
> gestellt wird.

Was ohnehin zweckmäßig ist, denn mehr als Fullspeed machen diese 
Controller eh nicht. Da muss man dann die USB-Version auch nicht auf 2.0 
festlegen wollen.

Hier noch die Ausgaben unter FreeBSD:

1

# usbconfig -d 5.3 dump_device_desc

2

ugen5.3: <vendor 0x00ff product 0x00ff> at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)

3

4

  bLength = 0x0012

5

  bDescriptorType = 0x0001

6

  bcdUSB = 0x0200

7

  bDeviceClass = 0x00ff  <Vendor specific>

8

  bDeviceSubClass = 0x0000

9

  bDeviceProtocol = 0x0000

10

  bMaxPacketSize0 = 0x0040

11

  idVendor = 0x00ff

12

  idProduct = 0x00ff

13

  bcdDevice = 0x0100

14

  iManufacturer = 0x0000  <no string>

15

  iProduct = 0x0000  <no string>

16

  iSerialNumber = 0x0000  <no string>

17

  bNumConfigurations = 0x0001

18

19

# usbconfig -d 5.3 dump_curr_config_desc

20

ugen5.3: <vendor 0x00ff product 0x00ff> at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)

21

22

23

 Configuration index 0

24

25

    bLength = 0x0009

26

    bDescriptorType = 0x0002

27

    wTotalLength = 0x0012

28

    bNumInterfaces = 0x0001

29

    bConfigurationValue = 0x0001

30

    iConfiguration = 0x0000  <no string>

31

    bmAttributes = 0x00c0

32

    bMaxPower = 0x0032

33

34

    Interface 0

35

      bLength = 0x0009

36

      bDescriptorType = 0x0004

37

      bInterfaceNumber = 0x0000

38

      bAlternateSetting = 0x0000

39

      bNumEndpoints = 0x0000

40

      bInterfaceClass = 0x00ff  <Vendor specific>

41

      bInterfaceSubClass = 0x0000

42

      bInterfaceProtocol = 0x0000

43

      iInterface = 0x0000  <no string>

Jörg W. schrieb:
> SETUP   0       1,028
>   00 09 01 00 00 00 00 00
> IN      0       1,029

Dieser Request fehlt in der Windows Variante (SetConfiguration) weshalb 
das Ding unter Win nicht enumeriert.
Ich würde deshalb testweise einfach mal einen Bulk EP hinzufügen bei den 
Descriptoren hinzufügen. Nur um sicherzugehen dass Win da nichts falsch 
versteht.

Thomas Z. schrieb:
> Dieser Request fehlt in der Windows Variante (SetConfiguration)

Stimmt.

Du meinst, sie schicken das nicht los, weil es keine Endpoints gibt 
außer dem control endpoint?

Jörg W. schrieb:
> Du meinst, sie schicken das nicht los, weil es keine Endpoints gibt
> außer dem control endpoint?

wäre eine Möglichkeit. Ich bin mir nicht sicher ob ich sowas schon mal 
gemacht habe. Bei Windows weis mans nie. Manchmal sind die bei MS total 
pingelig manchmal lassen Sie auch grobe Fehler durchgehen.

Zumindest behauptet Windows, das Teil sei konfiguriert. Hat natürlich 
keinen Treiber installiert – an der Stelle ist Windows anders als alle 
anderen OSe. Die haben nämlich immer einen low-level driver, über den 
man (bspw. per libusb) grundsätzlich erst einmal auf das Gerät zugreifen 
kann.

Könnte natürlich sein, dass Windows keine Konfiguration auswählen will, 
solange kein Treiber da ist. Das Einfachste wäre es vermutlich, du 
würdest erstmal ein HID bauen. Das ist relativ simpel, und es hat selbst 
in Windows immer einen Treiber.

Ich bin mir nicht zu 100% sicher wer im Treiberstack das SetConfigure() 
macht.
Ich teste gerne und oft mit dem Thesicon USBIO Demo Treiber(*), dort 
macht SetConfigure() die DemoApp. Es ist also möglich dass das gar nicht 
mehr zum Enum Code gehört.
Vielleicht hat Win auch einfach ein Problem wenn es keine Pipe gibt. Was 
ich aber sicher sagen kann ist dass ein SetConigure() auch kommt wenn 
kein Treiber zugeordnet ist.

(*)
Da es das USBIO demo für W10 nicht mehr frei zum runterladen gibt mache 
diese Tests in einer VM mit Win XP.

Ich habe jetzt mal die String Descriptoren korrekt implementiert, und 
zum Test einen Language und einen Manufacturer Descriptor erstellt, ich 
erhalte aber weiterhin diese Meldung.

1

iManufacturer:                     0x01

2

String Descriptor for index 1 not available while device is in low power state.

Ich habe jetzt auch mal einen weiteren Endpoint implementiert, dennoch 
sagt USBView "No open pipes":

1

[Port4] 

2

3

4

Is Port User Connectable:         yes

5

Is Port Debug Capable:            no

6

Companion Port Number:            10

7

Companion Hub Symbolic Link Name: USB#ROOT_HUB30#7&124f193f&0&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}

8

Protocols Supported:

9

 USB 1.1:                         yes

10

 USB 2.0:                         yes

11

 USB 3.0:                         no

12

13

       ---===>Device Information<===---

14

String Descriptor for index 2 not available while device is in low power state.

15

16

ConnectionStatus:                  

17

Current Config Value:              0x00  -> Device Bus Speed: Full (is not SuperSpeed or higher capable)

18

Device Address:                    0x05

19

Open Pipes:                           0

20

*!*ERROR:  No open pipes!

21

22

          ===>Device Descriptor<===

23

bLength:                           0x12

24

bDescriptorType:                   0x01

25

bcdUSB:                          0x0110

26

bDeviceClass:                      0xFF  -> This is a Vendor Specific Device

27

bDeviceSubClass:                   0x00

28

bDeviceProtocol:                   0x00

29

bMaxPacketSize0:                   0x40 = (64) Bytes

30

idVendor:                        0x00FF = Vendor ID not listed with USB.org

31

idProduct:                       0x00FF

32

bcdDevice:                       0x0100

33

iManufacturer:                     0x01

34

String Descriptor for index 1 not available while device is in low power state.