¿Cuáles son las limitaciones del dispositivo compuesto USB?

Estoy viendo la codificación de un dispositivo USB que es capaz de encapsular dos dispositivos USB. Me gustaría crear un teclado HID con un solo puerto USB adicional. Un dispositivo de almacenamiento masivo estaría conectado al puerto.

Me preguntaba, ¿sería capaz de programar el teclado para registrarlo como un dispositivo compuesto que encapsula el almacenamiento masivo y el teclado?

Mi proceso de pensamiento actual es declarar que el teclado tiene 2 interfaces. Estaba pensando en simplemente copiar los comandos USB del disco de masa en una de las interfaces del teclado. es posible?

Si este es un pensamiento incorrecto, hágame saber cuál se supone que es el formato de datos de las interfaces.

Gracias.

Además, esto es con fines educativos para ampliar mi conocimiento de USB.

Sería más fácil usar un concentrador USB de hardware que tratar de hacer un concentrador USB en compuesto. Entonces, estos circuitos integrados solo necesitan una tapa y un cristal.

Respuestas (2)

No puede tener un "teclado HID" con un "único puerto extra"; el dispositivo de este tipo debe ser un dispositivo compuesto , hecho de un concentrador de dos puertos, con un puerto conectado a un dispositivo HID no extraíble. El otro puerto se puede conectar permanentemente a un dispositivo de almacenamiento masivo. En este caso, es posible que no necesite envolver todo esto como un dispositivo compuesto (un dispositivo que admite dos clases alternativas).

Diseñar el conjunto correcto de descriptores para este tipo de dispositivos es terriblemente complicado (al menos desde la perspectiva de un técnico de hardware), pero puede usar guías listas para usar de, por ejemplo, compatibilidad con el compilador Keil, MDK Middleware para dispositivos USB y Host Communication . Este enlace es para un ejemplo de dispositivo USB compuesto basado en dos de sus tutoriales anteriores, "Dispositivo USB HID" y "Almacenamiento masivo de dispositivo USB". Espero que esto sea exactamente lo que necesitas.

Hola. Gracias por su respuesta. Gracias por el recurso. Le echaré un vistazo más tarde. Sin embargo, me pregunto, ¿por qué debe ser un dispositivo compuesto? Mi entendimiento hasta ahora es que un dispositivo compuesto puede permitir que la capacidad de 2 dispositivos USB aparezca como 1 a través de la interfaz. ¿Es este entendimiento incorrecto?
@philm, supongo que no tenía claro que tienes dos formas, compuesto y compuesto. Dado que dijo "puerto USB adicional", esta sería una ruta para el dispositivo compuesto, cuando ambas funciones están disponibles al mismo tiempo en el concentrador integrado. La ventaja sería utilizar todos los controladores de host estándar para este dispositivo. Si desea ocultar la función de almacenamiento masivo y tenerla cambiando las interfaces de un dispositivo compuesto, es probable que necesite un controlador propietario.
Oh bien, eso lo aclara. Entonces, ¿bajo qué condiciones debo usar el dispositivo compuesto frente al dispositivo compuesto y viceversa?
@philm, los dispositivos compuestos generalmente están hechos de circuitos integrados de controladores discretos, creo que generalmente es imposible sintetizar un concentrador USB dentro de una MCU. Si solo tiene una MCU, entonces el compuesto es el único camino a seguir.
Sí, de nuevo, esto es solo para educación. Estaba leyendo un artículo en el que podía implementar un TLC y hacer referencia a cada dispositivo USB a través de una identificación de informe. Para mí, esto parece una solución bastante simple en lugar de usar las interfaces que, por lo que parece, sería un dolor en el trasero.

He hecho muchos de estos dispositivos compuestos (HID + almacenamiento masivo) antes, pero ya no. Hay dos problemas. La primera es que a Windows ya no le gustan. Hay un montón de problemas hoy en día con la comunicación con puntos finales de almacenamiento masivo compuestos. Funcionaron bien en Windows 2000 y Windows XP, pero ya no tanto. No tengo idea de por qué, ¿quizás alguien pueda educarme?

El segundo problema es que si declara un dispositivo de almacenamiento masivo como parte de su descriptor de dispositivo compuesto, entonces su código de microcontrolador debe manejar las solicitudes de dispositivos de almacenamiento masivo. No puede simplemente retransmitirlos byte a byte a otro puerto USB, ya que los descriptores de la interfaz son (casi con certeza) diferentes. Puede hacer esto si tiene otro puerto de host USB en su MCU: escriba el código de host USB que se comunica con la memoria flash USB (o incluso con un dispositivo de memoria totalmente diferente, como una tarjeta SD) y transmita los comandos de lectura y escritura del bloque entre su compuesto interfaz y el otro dispositivo de memoria. Funcionará, al menos con Linux y kernels de Windows más antiguos.

Pero si solo desea tener un puerto USB simple en el costado de su teclado, y no tiene requisitos adicionales (como que el teclado pueda leer la memoria flash USB sin la PC), entonces solo tome un USD0 .3 USB hub IC, colóquelo en la misma PCB, conecte uno de los puertos a su microcontrolador y el otro(s) a conector(es) externo(s) en su producto. El beneficio es que su producto es estándar, por ejemplo, cualquier tipo de dispositivo USB se puede conectar a los puertos externos, incluidos más concentradores, y no tiene ningún problema con su software MCU.

[Editar] hmm... Me puse a pensar... Supongo que podría ser posible transmitir los comandos del protocolo MSC (los USBC - datos - paquetes USBS) al otro puerto USB, lo que facilitaría la implementación general del software. .. pero los otros problemas permanecen.

¿Cuáles son las limitaciones del dispositivo compuesto USB?
RespuestasAquíPolítica de privacidad1y, 0v