Depuración de bInterval en endpoints interrupt USB

Los endpoints interrupt USB se usan en teclados, ratones, game controllers, sensores, paneles táctiles, escáneres de códigos, dispositivos SAI y muchas herramientas HID a medida. Los usuarios buscan "USB bInterval", "HID polling rate", "USB interrupt endpoint latency", "missed input reports", "USB device 125Hz 250Hz 1000Hz" y "bInterval full speed high speed" cuando el input se siente retrasado o los reports llegan al ritmo equivocado.

Bus Scope ayuda porque el comportamiento de polling se define por los endpoint descriptors y por el timing real del bus. La UI del sistema operativo puede mostrar solo "device connected"; la captura puede enseñar qué interval usa de verdad el host.

Qué significa bInterval

Un endpoint descriptor interrupt incluye bInterval. Este valor describe el polling interval, pero su interpretación depende de la velocidad y del tipo de endpoint.

Distinciones importantes:

• Los endpoints interrupt low-speed y full-speed usan intervals basados en frames de milisegundos.
• Los endpoints interrupt high-speed usan una codificación distinta basada en microframes.
• El scheduling del host controller y la topología del hub pueden afectar al timing observado.
• El timing de lectura de la aplicación no es lo mismo que el polling del bus USB.

Si un ingeniero solo mira los callbacks de la aplicación, se puede perder el schedule real del endpoint.

Síntomas habituales

Los problemas de polling interval aparecen como:

• El ratón o el controller se siente lento.
• Los HID input reports llegan cada 8 ms en lugar de cada 1 ms.
• El dispositivo anuncia 1000 Hz pero se comporta como 125 Hz.
• Los datos del sensor van a ráfagas.
• El escáner de códigos pierde escaneos rápidos.
• El panel táctil se siente retrasado tras un resume.
• El firmware manda reports más rápido de lo que el host sondea.
• El modo high-speed cambia el timing de los reports sin avisar.

Esos problemas suelen parecer de latencia o responsividad, pero la evidencia de raíz está en el descriptor USB y en el timing de los paquetes.

Interpretación full-speed frente a high-speed

El mismo bInterval numérico puede significar un timing efectivo distinto según la velocidad. Un endpoint HID full-speed con bInterval=8 no es el mismo modelo de scheduling que un endpoint high-speed con el mismo valor en bytes.

La depuración debería capturar:

• Velocidad negociada real.
• Endpoint descriptor.
• Endpoint address.
• Transfer type.
• bInterval.
• Cadencia observada del IN token o de la transferencia.
• Timing del payload del report.

Bus Scope debería enseñar juntos los valores del descriptor y el timing observado.

Sobreproducción del firmware

Algunos firmware generan input reports más rápido de lo que el host sondea. Esos reports pueden sobrescribirse, coalescerse o perderse antes de que el host los vea.

Síntomas:

• Los logs internos del dispositivo muestran eventos.
• El host recibe menos reports.
• Pulsaciones rápidas se pierden.
• El movimiento parece suavizado o retrasado.
• Los reports tras un burst contienen solo el último estado.

No es un problema de pérdida de paquetes USB. Es un problema de contrato entre firmware, buffering y polling.

El polling del host no es el read rate de la aplicación

Una aplicación puede leer cada 1 ms, pero el host USB puede sondear solo cada 8 ms. O el host puede sondear a tiempo, pero el event loop de la aplicación puede procesar los datos después.

La captura de paquetes separa:

• Polling interval del bus.
• Timing de respuesta del dispositivo.
• Buffering del driver del host.
• Latencia del callback de la aplicación.

Esa separación es crítica en casos de soporte sobre latencia HID.

Errores de bInterval en el descriptor

Bugs típicos de descriptor:

• Anunciar bInterval=10 por error en lugar de 1.
• Copiar el interval full-speed al descriptor high-speed de forma incorrecta.
• Usar un interval en las expectativas del HID descriptor y otro en el endpoint descriptor.
• Los comentarios del firmware dicen 1000 Hz pero el descriptor va más lento.
• El alternate setting cambia el interval pero el firmware no lo gestiona.

El byte en el descriptor es el contrato contra el que el host planifica.

Checklist de depuración

Usa este flujo:

1. Captura la enumeración.
2. Identifica los endpoint descriptors interrupt.
3. Apunta la velocidad real del dispositivo.
4. Decodifica bInterval.
5. Mide la cadencia observada del interrupt IN.
6. Compara con el polling rate esperado.
7. Dispara eventos rápidos de input.
8. Mira si se pierden reports o se coalescen.
9. Compara directo al puerto frente a hub.
10. Conserva juntos el descriptor y la evidencia de timing.

Diagnóstico final

La latencia de USB interrupt no es solo un problema de rendimiento de la aplicación. Depende del bInterval del endpoint, del modo de velocidad, del scheduling del host, de la generación de reports y del buffering del firmware.

Bus Scope ayuda a demostrar si un dispositivo HID o interrupt se está sondeando de verdad al ritmo previsto y si el input perdido viene del descriptor, del buffering del firmware o del timing del host y la aplicación.