- Wie gross sind die Datenpakete, die du sendest, in Bytes (also die Endpunktpuffer)?
die Anzahl der Buffer, sowie die Puffergroesse habe ich flexibel gehalten.
Ich habe verschiedene Konfigurationen ausprobiert, momentan verwende ich
folgende Einstellungen (in usbcls.asm)
o 4 IN Buffer je 64 Bytes, Transferlaenge 64 Bytes
o 2 OUT Buffer je 64 Bytes, Transferlaenge jedoch nur 8 Bytes
Die Buffer koennen noch waehrend eines laufenden Transfers vorbereitet/abgearbeitet werden - das steigert vor allem auf der IN Seite die Performance. Die Pufferadresse wird von der Software gesteuert (kein Ping Pong Modus)
Die Transferlaenge (welche im Endpoint Descriptor definiert ist -> usbdsc.c) habe ich reduziert, da hiermit der besagte Effekt im Loopback seltener auftritt (ich habe es einfach mal ausprobiert)
- Wieviele Pakete gehen pro Frame in welchem Modus (iso, bulk … ) rüber?
Die Zahl habe ich nicht mehr im Kopf, doch ich kann sie bei gelegenheit ermitteln. USB MIDI unterstuetzt nur Bulk Transfers
- Wird dein Gerät als Teil der MIDI-Geräteklasse verwendet?
Denke schon, Windows ist nicht so mein Thema. 
Es klingt aber so, als ob das Problem tatsächlich auf der Controllerseite liegt. Hast du jemals unter Windows einen “Error 30” bekommen? Meines Wissens werden die Pipes unter Windows als Streams oder Filehandles gehandhabt. Bei mir brachten Versuche, 0 Bytes von der Hostapplikation aus der Pipe zu lesen (wenn eben keine Daten anlagen) einen Abriss der Verbindung oder erzeugten wahrscheinlich auf Kernelebene (da das System ausgelastet war) diese Timeouts. Auf dem Controller selbst hatte ich keine Probleme.
das klingt interessant! Gibt es unter Windows so etwas wie /var/log/messages unter Unix, also ein systemweites Logfile, in dem solche Ereignisse hinterlegt werden?
Abgesehen von der Control-Pipe (EP0) darf pro Endpunkt nur entweder IN oder OUT Ãœbertragung aktiv sein. IN/OUT an einem Endpunkt geht eigentlich nicht?!
Das wuerde mich wundern, denn mit dem EZ-USB funktioniert diese Konfiguration problemlos.
Steht das irgendwo in der USB Spec?
Vor ein paar Tagen hatte ich mal temporaer die Konfiguration “IN auf EP1, OUT auf EP2” ausprobiert, der IN Buffer wurde weiterhin sporadisch (ohne erkennbares Schema) blockiert.
Wie sieht denn dein Device Deskriptor dafür aus? (oder wo bekomme ich denn die aktuelle Firmware, an der du arbeitest?)
Ich habe mal einen aktuellen Snapshot nach http://www.ucapps.de/tmp/mbhp_usb_pic_snapshot.zip gelegt.
Der interessante Code steht unter usbcls.asm und usbdsc.c
Die UOWN Flags garantieren offenbar nicht, dass der Puffer nach Wechsel des Zugriffsrechts auch übertragen worden ist, das musste ich feststellen. Wie ich eine erfolgreiche Ãœbertragung von der SIE überprüfe, hab ich noch nicht herausgefunden. Was sich mir auch nicht erklärt ist, wie ich abfange, dass -während- des Pufferkopierens an den EP* eben die UOWN Bits nicht gesetzt werden. Microchip lässt sich da nur sehr dürftig drüber aus…
Ich sehe die UOWN Bits als Semaphore fuer den RAM Bereich: wenn beim OUT Buffer UOWN geloescht ist, weiss man, dass ein neues Packet angekommen ist. Man holt es sich ab, und setzt das Flag wieder (+ DTS Handshake).
Beim IN Buffer geht man davon aus, dass er beschrieben werden darf, solange UOWN geloescht ist. Die SIE wird solange nicht darauf zugreifen, bis man UOWN wieder setzt.
Solange man also die Regeln einhaelt, auf den Memory Bereich niemals zu schreiben, wenn UOWN gesetzt ist, und UOWN niemals via Software zu loeschen, kann nichts schieflaufen.
Ist während des Timeouts denn generell gar keine USB Kommunikation mit dem Controller mehr möglich (hängt die SIE?)?
Scheinbar, ansonsten wuerde die Uebertragung ueber einen anderen EP funktionieren.
Vielleicht kommen wir ja weiter
Es ist immer gut, wenn man mal darueber spricht 
Gruss,
Thorsten.