USB: ¿cuáles son las ventajas (o desventajas) de usar HID sobre serial-over-USB?

Descargo de responsabilidad: soy un novato en electrónica y aún más en trabajar con USB, tengan paciencia conmigo si entiendo mal algunos de los elementos esenciales detrás de cómo funciona USB. Cualquier corrección bienvenida!

El escenario: con un grupo de amigos estamos construyendo un velero robótico. Estamos gestionando todos los sensores a bordo a través de un µC (AVR), pero la IA de navegación se realiza en un sistema Linux integrado. La electrónica está conectada al hardware AI a través de USB, y estoy buscando consejos sobre qué protocolo usar para la transmisión.

Ya probamos tanto el puerto serie a través de USB como el uso de HID, y ambos funcionaron lo suficientemente bien™ en nuestras breves pruebas cercanas a la costa, pero antes de conformarme con uno u otro, me gustaría saber si hay algo que no sea trivial . pero sin embargo diferencias importantes entre los dos que me faltó considerar . Para nuestro proyecto las características más importantes son:

  • Fiabilidad : nuestro robot debe navegar de forma autónoma durante unos días. ¿Alguno de los dos protocolos es inherentemente "más seguro"/con una mejor funcionalidad de manejo de errores/autorrecuperación?
  • Rendimiento : aunque en situaciones normales de funcionamiento nuestro rendimiento podría estar por debajo de 1 Kb/s, en determinadas condiciones necesitaremos recopilar datos casi en tiempo real. La serie está limitada a 115 Kb/s, ¿tiene HID un límite de velocidad diferente a los 1500 Kb/s del protocolo USB 1.0?

...pero como dije: soy bastante nuevo en electrónica/USB, así que si sientes que me falta un parámetro clave, estaré encantado de saberlo.

¡Gracias de antemano por su tiempo y experiencia!

Respuestas (4)

Para determinar qué solución será mejor para el rendimiento, debe encontrar el cuello de botella y mejorarlo hasta que ya no sea el cuello de botella hasta que ya no pueda eliminar nada.

  1. Su AVR tiene una frecuencia máxima fija, trate de hacer que sus rutinas de procesamiento (optimizadas) sean el factor limitante. Si su protocolo de comunicaciones puede manejar esta velocidad, entonces no hay nada más que pueda hacer.
  2. USB a 1,5 Mbps representa mover 1 byte cada 160 relojes. Eso es bastante tiempo. para realizar el procesamiento, y si está almacenando sus datos en triple búfer o enviando bloques completos, querrá que esto sea aún más rápido. A 12 Mbps, obtiene 13 ciclos de reloj por byte, lo que es mucho más difícil de lograr y sería un objetivo razonable.
  3. La interfaz entre USB (e incluso el propio USB) tendrá algunos gastos generales. El envío de datos ASCII a través de una interfaz serial asíncrona es una gran sobrecarga. Un chip de interfaz USB FIFO paralelo será mucho más rápido. Un micro con periférico USB incorporado será aún mejor.

Para obtener más confiabilidad, debe ceñirse a lo que funciona y a lo que mejor conoce. Relaje las especificaciones. Aquí, una interfaz serial probada y verdadera es una buena elección.


¿Cómo funciona "serial over USB" en su aplicación?

Si se trata de un controlador de software en el dispositivo Linux incorporado y un IC USB <-> paralelo (o puerto serie de software en un AVR habilitado para USB, lo que parece probable ya que probó el modo HID), entonces no tendrá problemas con tasas de bits más altas.

Sin embargo, los verdaderos circuitos integrados USB <-> serie existen y son populares (me viene a la mente el FTDI232R en Arduinos más antiguos...) que convierten el USB en una comunicación serie RS232 de nivel lógico. No necesita ni desea esta capa para su aplicación. Reducirá su rendimiento y agregará una sección de retraso asíncrono adicional a su aplicación.

Hice un proyecto que requería una interfaz USB (usando PIC micro) hace un par de años, miré ambos pero creo que HID es superior:

HID tiene detección automática y almacenamiento en búfer de paquetes por windoze en lugar de seguir teniendo que 'reconectar' el puerto serie en cada complemento (y a un número de puerto que depende del puerto usb utilizado cada vez (LAME)) --programación ¡VB para HID es simple!

El rendimiento máximo es menor para HID, creo que es de 64 bytes (tamaño máximo de búfer oculto) en ambos sentidos cada 10 ms para USB 1.1 o 1 ms para USB 2.0.

¿Conoce algún buen ejemplo instructivo para vb.net y/o programación de hardware de un HID usando un ST Micro STM32L151? Si pudiera hacer funcionar una versión del lado de la PC, podría encontrar más fácil averiguar qué está pasando con la demostración del ST.
FYI: Si no desea la 'ruleta de puerto COM virtual', asegúrese de que su dispositivo CDC tenga un descriptor de número de serie. Si el dispositivo tiene un descriptor S/N, Windows asigna un puerto com único a ese VID-PID-S/N, y puede moverlo al puerto USB que desee; el VCP permanecerá igual. Si no tiene una descripción de S/N, Windows lo sustituye en un campo que representa el puerto USB físico; esta es la razón por la cual el puerto COM virtual cambia cuando mueve el dispositivo.

1) En cuanto a la confiabilidad, preferiría protocolos de nivel inferior como serie de hardware con manejo manual de errores. El dispositivo USB podría simplemente desaparecer si al controlador no le gusta algo, y si no lo reinicializa, no lo volverá a ver. Por lo tanto, debe aprender a reiniciar el USB.

2) En cuanto a la velocidad, la conexión serial a través de USB no está limitada a 115 Kb/s en general, pero en realidad verá una limitación en una de nuestras implementaciones. En general, esperaría que 'serial-over-USB' fuera más eficiente que HID, ya que HID debería tener más carga de 'decoración'. Aún más rápido es 'parralel-over-USB' que se usa para bombear a velocidades cercanas al rendimiento USB.

No es el perfil serie el que está limitado a 115200 bps; de hecho, rara vez es el puerto serie hoy en día. Si usa algo como un FT245, puede alcanzar velocidades mucho más altas que eso. El problema con la transferencia asíncrona estándar (estilo RS-232) es que necesita tener espacios ocasionalmente para tener la oportunidad de sincronizar en bytes (o alternativamente, enviar 0xff de vez en cuando).

En cuanto a la diferencia entre HID y serie USB, la serie es a granel, mientras que HID es control e interrupción. Eso es fundamental para USB y significa que HID tiene (potencialmente) una latencia más baja, pero la serie tiene mayor capacidad. No hay mucho más que eso, ninguno es más confiable, y querrá una forma de restablecer su circuito cuando las cosas salgan mal.

... por cierto, esto suena familiar. ¡Hola Mac! Perdón por mi ausencia de Abbenay ayer.

Hola, hola Yann! ¡Entonces parece que el mundo ES un lugar pequeño! :) Volvamos a la pregunta: entonces, el hecho de que con la serie, si desconecto y vuelvo a conectar el dispositivo, necesito reiniciar manualmente la conexión, mientras que con HID no lo hago es puramente una diferencia de software en las bibliotecas que estoy usando ( es decir, en el caso de HID, ¿la biblioteca hace eso sin que yo lo sepa)? ¿ Puede articular sobre los 0xFFproblemas de "sincronización en bytes" de bytes? ¡Gracias!
FF es un truco. Básicamente, un marco en RS232 se ve como 0ddddddddp1, donde 0 es el bit de inicio y 1 es el bit de parada. El envío de todos los bits de datos y de paridad altos garantiza que el siguiente bit de inicio sea el primer 0 durante un tiempo, por lo que se puede usar para sincronizar. En cuanto a desconectar el dispositivo USB; para el puerto serie, desaparece, por lo que debe abrir uno nuevo en su lugar. Para el caso de HID, ¿puede estar escuchando el flujo de entrada combinado? No sé. De cualquier manera, puede usar udev para iniciar cosas cuando conecta un dispositivo.
Como observa, cualquier byte que siga a un FF se recibirá correctamente, independientemente de los errores de trama anteriores; dependiendo del diseño del UART, lo mismo puede ocurrir con FE, FC, F8, F0, E0, C0, 80 y 00. Esto puede hacer que ese conjunto de caracteres sea útil para la sincronización si el UART receptor esperará un flanco descendente. en la línea de datos después de un error de trama (algunos lo harán, otros no).