mikrocontroller.net

Forum: PC-Programmierung libUSB, bulk_write und endpoint size


Autor: Nobbie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich bin gerade dabei ein Programm, dass mit einem USB Device 
kommuniziert, zu programmieren. Als PC-seitige USB-Schnittstelle benutze 
ich libUSB. Funktioniert soweit einwandfrei.
Das USB Device ist im Bulk-Transfer mit einer Endpoint Size von 64 Byte 
konfiguriert.
Jetzt habe ich das Problem, dass wenn ich größere Datenpakete(z.B. 260 
Bytes) über bulk_write(...) zum Device schicke, bekomme ich immer einen 
Timeout Error.

Kann es sein, dass man beim bulk_write(...) nur mit der maximalen 
Endpoint Size arbeiten kann?
Beim bulk_read(...) funktioniert es übrigens problemlos. Hier kann ich 
Datenmengen > Endpoint Size lesen.

Wäre über eine Info sehr dankbar.
Gruss
Nobbie

: Gesperrt durch Moderator
Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Werden denn die Daten auch wirklich aus dem EP-Puffer abgeholt? Ich kann 
bei meinem Cypress FX2, der auch 512 Byte Bulk EP-Größe hat, auch 
beliebig viele Daten schicken, wenn sie von der Hardware abgeholt 
werden. Wenn die natürlich nicht innerhalb der TimeOut Zeit aus dem 
Puffer geholt werden und der wieder frei wird, dann kommt der TimeOut.

Autor: Nobbie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo supachris,

die Daten werden schon ordnungsgemäß von der libUSB gesendet. Das 
Problem liegt beim USB device und der Firmwareimplementierung.

Ich habe hier einen AT91SAM7 und habe die USB Implementierung anhand des 
USB Frameworks von Atmel vorgenommen. Beim BulkWrite(IN Pakete; Device 
--> Host) funktioniert das einwandfrei. Beim Lesen(OUT Pakete; Host --> 
Device) mit Datenmengen größer der definierten Endpoint Size treten aber 
Probleme auf. Ich glaube, dass dies an dem Interrupthandling + 
DualPortRam liegt. Ich erkenne an meinem USB Hardwaremonitor, dass die 
Pakete sauber vom Host gesendet werden aber vom Device mit NAK bestätigt 
werden. Die ersten 128 Bytes werden aber sauber mit ACK bestätigt. Ich 
denke, es liegt daran, dass die Flags RX_DATA_BKx nicht sauber 
zurückgesetzt werden.

Da muss ich noch einmal etwas tiefer reingehen.

Danke und Gruss
Nobbie

Autor: Markus Göbbels (markus_ac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
dieser Thread ist zwar schon alt, aber kommt meinem Problem wohl am 
nächsten.

Ich nutze einen PIC mit der libusb und auf meinem PC den entsprechenden 
Treiber (ich nutze grundsätzlich den Treiber, den Microchip auch für den 
ICD3-Debugger nutzt: MCHPWinUSBDevice.inf mit WdfCoInstaller01009.dll 
und winusbcoinstaller2.dll). Klappt alles wunderbar.

Nun möchte ich die Endpoint-Size vergrößern. Aktuell sind es 64 Byte. 
Das ist in meiner PIC-Firmware so eingestellt (default). Versuche ich 
nun diesen Wert zu ändern, zeigt Windows mit einen Treiber-Fehler an. 
Auch ein vorheriges Deinstallieren des Treibers und Neu-Installation bei 
Geräteerkennung bringt den selben Effekt.
Ich habe ab erin der Treiber inf-Datei oder in den Registry-Einträgen 
unter HKLM->System->ControlSetxyz->Enum->USB->Mein-Device keine Einträge 
zur Endpoint-Size gefunden.

Weiß jemand, ob 64 Byte da das Maximum sind und, wenn nicht, wie ich 
meinem PC mitteilen kann, dass sich da was geändeert hat?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Göbbels schrieb:
> aber kommt meinem Problem wohl am
> nächsten.

Nein, überhaupt nicht.  Die hier angesprochene libUSB meint diese:

http://www.libusb.org/

oder ggf. ihre Windows-Inkarnation:

http://sourceforge.net/apps/trac/libusb-win32/wiki

Mit dem, was Microchip dir mitliefert, hat das nichts zu tun, denn
das hier bezieht sich auf die Host-Seite.

Öffne also bitte einen eigenen Thread dafür.  Bitte lies' dir aber
vorher im Netz die Grundlagen von USB (1.1 vermutlich in deinem
Falle) an, denn mir scheint, dass dir ebendiese fehlen.  Schau dir
insbesondere die maximale Endpunktgröße an dabei.

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.