Estos bytes son los datos del descriptor devueltos por su dispositivo en respuesta a la solicitud GET_DESCRIPTOR. Estos datos no pueden aparecer antes del inicio de la transferencia de control, falta algo en su observación.
El host debe comenzar con la transacción de CONFIGURACIÓN [2D]. A continuación, los datos de configuración deben seguir:
[C3] es el token DATA0, [80 06 00 01 00 00 40 00] es "obtener descriptor", [DD 94] es CRC16.
Este token de CONFIGURACIÓN debe tener ACK de su dispositivo.
El host debe continuar con el token IN.
El dispositivo, en respuesta al token de IN [69], siempre debe devolver el resultado, que es [12 01 00 02 ........]
"12" significa que el descriptor contiene 18 bytes de datos. El resto lo necesitarías para decodificar, preferiblemente usando una mejor herramienta, como el decodificador Teledyne-LeCroy / CATC.
En particular, los bytes [8..9] [E6 04] significan que el ID de proveedor es 0x04E6 (
SCM Microsystems), los siguientes 2 bytes [16..51] significa PID = 0x5116 - producto iD (SCR3310 SmartCard Reader), el resto son otros campos estándar de su descriptor de dispositivo.
[D2] es ACK, lo cual es bueno.
Aquí hay un ejemplo de transferencia GET_DESCRIPTOR desde un mouse LS:
Los datos del descriptor (18 bytes) están divididos por el host en 3 transacciones, ya que max_packet_size es de 8 bytes solo para este dispositivo en particular (mouse Logitech). Toda la transferencia también tiene varias transacciones NAKed, que están ocultas.
