WinUSB *.inf unter x64

Achromat schrieb:

Hallo Mox,

naja die dynamische Deskriptoren liste im Baustein ist eine aus vielen AVR Examples like V-Usb abgekupfert, dort stehen ja bereits Endpunkte, bezeichnet mit idx 83 und 81 drin.

Das ist schon mal ein Problem. Das sind nämlich beides IN Endpunkte, schreiben kannst Du damit schon mal nichts. Sollte das nicht eher 81 und 1, beziehungsweise 3 und 81 sein?

Hast Du keinen OUT-EP, sollten die geschriebenen Reports wieder auf EP0 landen. Damit bist Du wieder in der Pflicht, SET_REPORT Requests zu verarbeiten (Firmware prüfen und ggf anpassen).

Achromat schrieb:

Das ich für Write und Read zwei Open's brauche habe ich auch schon gesehen, obschon mit "RW-Flag" geöffnet wird. Da nun unklar war wie Write/Read auf den Endpunkt wirken solle, habe ich HID_SetFuture HID_GetFuture verwendet.

Feature, nicht Future!
Für HID brauchst Du keine zwei Opens, für WinUSB auch nicht.

Achromat schrieb:

Auf dem Baustein hätte die LED geblinkt wenn auch nur einer der beiden Operationen den Interrupt der als WinUsb auch so vorkommt, ausgelöst worden wäre.

Den Speicher für read/write Operationen wurde im Baustein als auch im win mit 8 Bytes angegeben.

Siehste, schon falsch. Auf Seiten des Windows-Hosts gibst Du die Anzahl schon mal nicht fest an. Du parst erst einmal die Reports (HidD_GetPreparsedData), um dann im nächsten Schritt die tatsächliche Länge anzufragen (HidP_GetCaps). Und als Write-Buffer allokierst Du nun HIDP_CAPS.OutputReportByteLength Bytes. Und siehe da: Das sind 9 Bytes. Das allererste Byte des Reports ist von Dir selbst mit dem Report-Identifier zu initalisieren, egal ob Du schreibst oder liest! Arbeitest Du nicht mit Report-Identifiern, nimmst Du eben die 0.

Achromat schrieb:

Genau ich sollte mich darauf konzentrieren das das InputDevice von alleine sich in den HardwareManager einklingt (DescLen=22 sonnst 0 für WinUsb) und den Deskriptor noch mal genau studieren, was mir sehr schwer fällt, ich habe den Descriptor aus dem Flash in den 512 Byte großen Arbeitsspeicher übertragen denn ich kann zur Laufzeit zb Pid und Vid dynamisch verändern was auch gut funktioniert.

Die gezeigten Deskriptoren sehen doch einigermaßen aus, auch wenn ich bcdHID auf 1.11 und nicht auf 1.01 gesetzt hätte. Und dann sollte noch ein beschreibbarer Endpunkt ausgerufen werden.

Achromat schrieb:

Ja wenig Ahnung von USB, ich habe die Dokumentationen gesichtet, aber mangels Lebenenszeit nicht gänzlich erfasst.

Mal gurz gebettelt, hast Du vielleicht einen Descriptor der da passen würde ?

Zeig her Deinen Report-Deskriptor, den kriegen wir schon korrigiert.

Ungeprüft:

const uint8_t g_ReportDescriptor[] =
{
    0x06, 0x00, 0xFF,              // USAGE_PAGE (Generic Desktop)
    0x09, 0x01,                    // USAGE (Vendor Usage 1)
    0xA1, 0x01,                    // COLLECTION (Application)

    0x09, 0x02,                    //   USAGE (Vendor Usage 0x02)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x26, 0xFF, 0x00,              //   LOGICAL_MAXIMUM (255)
    0x75, 0x08,                    //   REPORT_SIZE (8)
    0x95, 0x08,                    //   REPORT_COUNT (8)
    0x81, 0x02,                    //   INPUT (Data,Var,Abs)

    0x09, 0x03,                    //   USAGE (Vendor Usage 0x03)
    0x75, 0x08,                    //   REPORT_SIZE (8)
    0x95, 0x08,                    //   REPORT_COUNT (8)
    0x91, 0x02,                    //   OUTPUT (Data,Var,Abs)

    0x09, 0x04,                    //   USAGE (Vendor Usage 0x04)
    0x75, 0x08,                    //   REPORT_SIZE (8)
    0x95, 0x08,                    //   REPORT_COUNT (8)
    0xB1, 0x02,                    //   FEATURE (Data,Var,Abs)

    0xC0                           // END_COLLECTION
};

Übrigens: Feature-Reports werden grundsätzlich über den EP0 transportiert. Du musst dafür zwingend SET_REPORT und GET_REPORT bearbeiten.

Hallo Mox,

schau an Size abfragen für hid, für WinUsb sende ich einen geformten request mit Endpunkte angaben.

Ich habe deinen Vorschlag 1:1 durch meinen Descriptor ersetzt (1)
usbDescriptorConfiguration[] Original umgenannt nach : usbDescriptorConfiguration1[]

mit Avrdude rüber gezogen: (Ich muss das erst Untersuchen aber das ergab der 1:1 Vorgang. http://euve12011.vserver.de/p1.jpg
und andere Version mit meinem BastelmodDescriptor:
http://euve12011.vserver.de/p2.jpg

Erstmal vielen Dank für deine Hinweise!
Grüße Karsten

das define DESCRIPTORLENGHT

wieder auf 22 gesetzt, und ich sehe das Hid Input Gerät,
ich berichte dann später Details.

Thx !

Achromat schrieb:

Hallo Mox,

schau an Size abfragen für hid, für WinUsb sende ich einen geformten request mit Endpunkte angaben.

HIDs haben eben den Schick, als das sie sich selbst beschreiben. Geformate Requests kannst Du aber immer noch schicken.

Achromat schrieb:

Ich habe deinen Vorschlag 1:1 durch meinen Descriptor ersetzt (1)
usbDescriptorConfiguration[] Original umgenannt nach : usbDescriptorConfiguration1[]

Stopp! Mein Vorschlag war ein Report-Descriptor, nicht ein Configuration-Descriptor! Das ist was anderes. Schau Dir mal Deinen HID-Descriptor an:

#if (USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH)    /* HID descriptor */
    9,          /* sizeof(usbDescrHID): length of descriptor in bytes */
    USBDESCR_HID,   /* descriptor type: HID */
    0x01, /* BCD representation of HID version */
    0x01, /* BCD representation of HID version */
    0x00,       /* target country code */
    0x01,       /* number of HID Report (or other HID class) Descriptor infos to follow */
    0x22,       /* descriptor type: report */
    USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH,  /* total length of report descriptor */
    0, 
#endif

Also:
0x01, /* number of HID Report (or other HID class) Descriptor infos to follow */

Damit sagst Du, dass das Gerät einen zusätzlichen durch die Geräteklasse definierten Deskriptor zur Verfügung stellt, nämlich:
0x22, /* descriptor type: report */

Es handelt sich also um einen Report-Descriptor, z.B. mein Vorschlag. Ändere jetzt diese Zeile:
USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH, /* total length of report descriptor /
in:
sizeof(g_ReportDescriptor), / total length of report descriptor */

Du musst jetzt noch sicherstellen, dass der Report auch ausgegeben wird. Das machst Du da, wo der GET_DESCRIPTOR Request bearbeitet wird. Aber das scheint ja bereits zu funktionieren, wenn ich Deinen letzten Beitrag richtig interpretiere.

Ja richtig, ich hatte den Hid Descriptor als Descriptor-Config eingehangen das war natürlich falsch. Im Moment sehe ich zwar das Gerät als HidInput, und kann auch 9 Byte schreiben, ich muss mir erst den Atmel Debugger kaufen mit dem
USB- 1Euro Programmer sehe ich nicht was passiert.

Vielen Dank für deine Hinweise
Gruß
Karsten

Hi,

nachdem ich die Deskriptoren wie beschrieben ergänzt habe, integrierte ich
eine Ein Draht rs232 sende Leitung, und tickerte mir die Anlaufenden Daten
auf einen anderen Microcontroller der diese als 38200B auf 100500b an einem Comport übersetze.

Damit war es möglich das etwas andere "behandeln" unter HID, im Controller
zu ergänzen. Inzwischen erreicht man mit dem Atiny85 2.5[K/s].
Jedes packet hat 8Byte.

Hier die HotWire DebugLeitung am PB1

//Use Atiny85 PB1 as TX DebugTransmitter to emit Strings
#define BD300   3333 //300  Baud   3,33 ms
#define BD1200   833 //1200  Baud  833 µs
#define BD2400   417 //2400  Baud  417 µs
#define BD9600   104 //9600  Baud  104 µs
#define BD19200   52 //19200  Baud  104 µs
#define BD28800   34.6//28800 Baud 34.6 µs
#define BD38400   23.04//38400 Baud 26,04 µs
#define BD115200   7.68
#define ACTBAUD    BD38400
//9600 8 n 1  1Startbit 8Datenbit 1Stopbit (can use two stop bitslots)

void TxStr(unsigned char *p)
{
   TxDat(p,strlen(p));
}
void TxDat(unsigned char *p, int len)
{
	unsigned char n;
	while(len-- > 0)
	{ 
		cli();//DisableInterrupt
		_delay_ms(1);

		//Startbit 	
		PORTB &= ~(1 << PB1);
		_delay_us(ACTBAUD);

		for(n=0; n < 8; n++) //Databits
		 *p&(1<<n)?(PORTB |=  (1 << PB1)):(PORTB &= ~(1 << PB1)),_delay_us(ACTBAUD);//make this slot

		//Stopbit1	
		PORTB |=  (1 << PB1);
		_delay_us(ACTBAUD);

		sei();//EnableInterrupt
		_delay_ms(1);

		p++;
	}
}

Schade das mit HID_SetFuture() oder ::WriteFile kein geformter Header
mit index value und size gesendet werden kann, die requests sind unter
Hid anders definiert, das musste man wissen.

//0x21 (33)comes from Hid_SetFuture
//0xa1 (161)comes from Hid_GetFuture

Schade das ReadFile nicht funktioniert (hängt fest blocklen 8+1=9)
HidGetFuture funktioniert, alles ist wunderbar.

Danke der Hinweise !
Gruß
K.

Achromat schrieb:

Schade das mit HID_SetFuture() oder ::WriteFile kein geformter Header
mit index value und size gesendet werden kann, die requests sind unter
Hid anders definiert, das musste man wissen.

Du kannst durchaus auch verschieden geformte Reports senden. Unterschieden werden sie dann zwar über wValue und nicht per wIndex, aber das ist ja auch nicht so schlimm. Die size brauchst Du nicht mitzusenden, da sie sowieso schon klar ist: Steht schließlich im Report-Deskriptor.

Allerdings musst Du den Report-Deskriptor dafür anpassen. Meinen Vorschlag kannst Du nicht mehr 1:1 übernehmen.

Achromat schrieb:

Schade das ReadFile nicht funktioniert (hängt fest blocklen 8+1=9)
HidGetFuture funktioniert, alles ist wunderbar.

Und wie das funktioniert! Du darfst halt nicht vergessen, das erste Byte des Puffers vor dem Aufruf von ReadFile zu initialisieren. Allerdings schaut es eher danach aus, als das Deine Firmware noch einigermaßen fehlerhaft ist. Das Gegenstück zu ReadFile ist HidD_GetInputReport, nicht HidD_GetFeature. Es scheint, als bedienst Du den In-Endpunkt nicht oder nicht richtig. Hast Du denn wenigstens Deine Endpunkt-Deskriptoren in Ordnung gebracht (ein HID hat nur einen In-Endpunkt)?

Ansonsten schau Dir das im Protokoll-Analyser an.

Hi,

in der Doku steht das lediglich das erste Byte noch beachtet wird. Das trifft nun aber für SetFuture zu. Das es sich um ein Equalent zum HID_Input oder zum HID_SetFurute verhält ist ja doll.. Und genau dann wird auch wieder das geformtes WINUSB Request verwendbar (unter HId_Write statt HID_SetFuture(Vermutung). Natürlich wenn der dritte Endpunkt auch wirklich off sein sollte.

Ich prüf das noch nach, im Moment läuft es Treiberlos sogar etwas schneller.
(Linux dito 32/64 ab xp sp1 )

Danke der Hinweise
Lg.
Karsten

Achromat schrieb:

in der Doku steht das lediglich das erste Byte noch beachtet wird. Das trifft nun aber für SetFuture zu.

Das gilt selbstverständlich auch für HidD_SetOutputReport und HidD_GetInputReport und steht auch in der Doku, man muss sie nur lesen:

MSDN schrieb:

If the top-level collection includes report IDs, the caller must set the first byte of the ReportBuffer parameter to a nonzero report ID.

If the top-level collection does not include report IDs, the caller must set the first byte of the ReportBuffer parameter to zero.

Achromat schrieb:

Das es sich um ein Equalent zum HID_Input oder zum HID_SetFurute verhält ist ja doll..

Nochmal, nur für Dich: ReadFile/HidD_GetInputReport sind ebenso wie WriteFile/HidD_SetOutputReport das Gleiche. Und da sie das Gleiche machen, sind auch die Puffer identisch zu initialisieren. Allerdings suchen sich ReadFile/WriteFile den effizientesten Weg und nehmen die zugeordneten Endpunkte. Erst wenn es keine zugeordneten Endpunkte gibt, geht es über EP0. Die Funktionen HidD_GetInputReport und HidD_SetOutputReport nehmen immer den langsamen Weg über EP0.

Für Feature-Reports gibt es keine zugeordneten Endpunkte. Das muss es auch nicht. Es geht ja schließlich nur um die Geräte-Features, bzw. die Geräte-Konfiguration. Von daher kann hier immer der langsame Weg über EP0 genommen werden. Und genau deswegen gibt es hier auch kein "Equalent", wie Du so schön sagtest.

So, wie Du momentan kommunizierst, erzeugst Du unnötig Buslast. Wieso? Wieso machst Du es nicht einfach richtig?

Achromat schrieb:

Und genau dann wird auch wieder das geformtes WINUSB Request verwendbar (unter HId_Write statt HID_SetFuture(Vermutung).

Ich verstehe nicht ganz. Du hast Dich jetzt für HID entschieden. Da wirst Du keine WINUSB Requests los.

Achromat schrieb:

Natürlich wenn der dritte Endpunkt auch wirklich off sein sollte.

Ein HID hat neben dem EP0 maximal zwei Endpunkte, nicht drei.