Hallo miparo,
war mit dem Update auf 1.2.6 etwas tricky, Windows hat immer wieder den 1.2.2 aus seinem System gezogen (obwohl ich den Treiber im Gerätemanager gelöscht habe
). Erst als ich per Hand den Suchpfad für den Treiber auf das richtige Verzeichnis gesetzt habe hat er die Version 1.2.6 gezogen :aerger:
Hast Du was am USB-Smart geändert?`
Ich verstehe hier etwas nicht mehr ganz:
1. Wenn ich richtig verstanden habe, hast Du die RequestTypes im LibUSB festgelegt und überträgst
die eigentlichen Befehle an das Device mit dem value.
Code
USBdevWrite(ADevice, USB_RECIP_DEVICE, $60, 1, 0)
Das ist für mich einleuchtend, ist das ein ZWANG von USB-Standard, dies so zu machen?
Mein Device erhält dann:
Code
000001: Vendor-Specific Request (DOWN), 21.09.2014 10:51:58.046 +4.643 (1. Device: PVS2014-CPU)
Destination: Device
Reserved Bits: 0
Request: 0x0
Value: 0x60
Send 0x0 bytes to the device
Das ist soweit klar.
Dann antwortet das Device (wahrscheinlich als ACKN gemeint:
Code
000002: Control Transfer (UP), 21.09.2014 10:51:58.082 +0.036. (1. Device: PVS2014-CPU) Status: 0x00000000
Pipe Handle: Control Pipe
Setup Packet
40 00 60 00 01 00 00 00 @.`.....
Recipient: Device
Request Type: Vendor
Direction: Host->Device
Request: 0x0 (Unknown)
Value: 0x60
Index: 0x1
Length: 0x0
Aber warum taucht die Antwort in meinem Empfangsspeicher EP0 ControlRequestvom USBsmart dann auf?
Code
USBreq1:$40
USBreq2:$40 unbekannt
Der ControlRequestTask erhält nun 1 EP0 Request, die kommen aber nicht vom Device (lt. USB Analyser), sondern vom USBsmart selbst, diese werden nicht über das USB-Interface empfangen sondern nur gesendet.
Die $40 könnte vom Ackn kommen, aber warum landen diese in dem Empfang EP0 beim XMEGA, oder habe ich einen Denkfehler?
Hier meine Routine vom ControlRequest
Code
Function myUSB_ControlRequest(bRequest : Byte; wValue : word) : boolean;
// need always answer from device
Var
b : byte;
begin
Header:= USB_ReadHeader;
DebugOut('USBreq1:$'+ ByteToHex( Header.bmRequestType ));
Case Header.bmRequestType Of
$0:
Case wValue Of // Host to Dev
$00 : // do a real RESET
USB_ControlSend(nil, 0);
DebugOut('USBcmd:$'+ ByteToHex( bRequest ));
mDelay(100);
USB_Detach;
mDelay(500);
HardWareReset;
USB_ControlSend(NIL, 0); // send back ACK
Return(True);
|
$20 : // write to a Port
// PortF:= Lo(wValue);
USB_ControlSend(nil, 0); // ACK the request
DebugOut('USBcmd:$'+ ByteToHex( bRequest ));
Return(True);
|
$30 : // Read a Port
b:= $F;
// b:= PinF;
USB_ControlSend(@b, 1); // send back ACK and PortF status
DebugOut('USBcmd:$'+ ByteToHex( bRequest ));
Return(True);
|
$40 : // do Beep
USB_ControlSend(NIL, 0); // send back ACK
DebugOut('USBcmd:$'+ ByteToHex( bRequest ));
Return(True);
|
$60 : // empfange Config
USB_ControlSend(NIL, 0); // send back ACK
DebugOut('USBcmd:$'+ ByteToHex( bRequest ));
usbAct:= $60;
Return(True);
|
Else
USB_ControlSend(Nil, 0); // unknown vendor request, do an ACK
DebugOut('USBcmd:$'+ ByteToHex( bRequest )+' unbekannt');
return(true);
Endcase;
|
Else
USB_ControlSend(Nil, 0); // unknown vendor request, do an ACK
DebugOut('USBreq1:$'+ ByteToHex( Header.bmRequestType )+' unbekannt');
return(true);
Endcase;
end;
Jedenfalls sind die Timeouts weg, ohne das ich noch was an meinen Tasks oder XMEGA Abläufen ändern musste
Und auch wenn ihr das lustig gefunden habt, ich konnte es nachvollziehen, immer wenn der Rechner größere Dateien geladen hatte, z.B. aus Netzwerk oder auch EXCEL. Kam sofort der Timeout auf dem XMEGA. Und es ist KEIN 8086 sondern auf 2 Rechnern das gleiche QuadCore 3,3GHz 16Gbyte RAM und 64Bit Windows.
Aber egal Hauptsache es läuft jetzt, Danke.
Gruß
Thorsten
