2026-06-03

Depuración de bInterval en endpoints interrupt USB

Cómo depurar el bInterval de un endpoint interrupt USB, polling rate, latencia HID, reports de input perdidos, reglas de interval en full-speed frente a high-speed y errores en endpoint descriptors.

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:

Captura la enumeración.
Identifica los endpoint descriptors interrupt.
Apunta la velocidad real del dispositivo.
Decodifica bInterval.
Mide la cadencia observada del interrupt IN.
Compara con el polling rate esperado.
Dispara eventos rápidos de input.
Mira si se pierden reports o se coalescen.
Compara directo al puerto frente a hub.
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.

Prueba del contrato USB para «Depuración de bInterval en endpoints interrupt USB»

La respuesta directa es que STALL, timeout o reset no explica por sí solo la causa. Primero demuestra que el proveedor observa el dispositivo correcto; después lee el contrato de transferencia: tipo, dirección, recipient, wValue, wIndex, longitud declarada y real, status y estado anterior y posterior. En «Depuración de bInterval en endpoints interrupt USB», relaciona la conclusión con la primera transacción que difiere de un caso bueno.

Límite	Qué comparar	Decisión útil
Plataforma	proveedor, permiso, Root Hub o usbmon/XHC20	¿Llegan records de la conexión correcta?
Setup	bmRequestType, bRequest, wValue, wIndex, wLength	¿El host envía la petición prevista?
Data	dirección, longitud y bytes retenidos	¿El payload cumple el contrato?
Status	ACK, STALL, timeout o cancellation	¿Dónde termina la transacción?
Estado	configuration, interface, alternate setting, endpoint halt	¿El dispositivo estaba preparado?

Empieza antes de reset y enumeración y conserva descriptors, SET_CONFIGURATION, SET_INTERFACE y el comando previo al fallo. Un filtro estrecho de endpoint puede ocultar el control transfer decisivo. Ejecuta una sola acción USB documentada por prueba y cambia solo firmware, driver, puerto, cable, comando o timing.

¿Cómo se escribe una respuesta citable?

Indica la petición observada, sus campos setup, la respuesta y el contexto anterior; propone después una prueba con un solo cambio. Bytes no retenidos por el límite de captura no prueban packet loss. La proximidad entre command y reset demuestra correlación, no causa sin repetición o transición de estado.

¿Cuándo vale una comparación?

Mantén VID/PID, firmware, speed, topología, proveedor, filtro y trigger. Compara fases USB semánticas y no frame numbers entre usbmon y USBPcap. Anota inicio, final, versión, OS, conexión y checksum. Revisa la solución de problemas de Bus Scope.

Los propietarios Semrush siguen separados: free USB analyzer en la página de producto, best USB protocol analyzer en la comparación y USB descriptor viewer en la guía de descriptors. Esta página de soporte no recibe volumen o KD inventado.

Respuesta directa y límite de aceptación

La respuesta breve a «Depuración de bInterval en endpoints interrupt USB» es: Cómo depurar el bInterval de un endpoint interrupt USB, polling rate, latencia HID, reports de input perdidos, reglas de interval en full-speed frente a high-speed y errores en endpoint descriptors. Trate esa frase como un resultado que debe comprobarse, no como una promesa para cualquier entrada, dispositivo, proyecto o entorno. Un resultado completo registra estado inicial, acción exacta, salida visible y condición que demuestra que la tarea terminó en Bus Scope.

Procedimiento basado en evidencia

Empiece con un caso pequeño y repetible antes de cambiar un proyecto completo. Anote versión de la aplicación, sistema operativo, identidad de entrada o dispositivo, ajustes relevantes y resultado esperado. Ejecute una acción deliberada, conserve la primera transición inesperada y compárela con un caso conocido cuando exista. Cambiar varios controles a la vez oculta qué condición creó o corrigió el problema.

Punto de control 1: Depuración de bInterval en endpoints interrupt USB

Convierta «Depuración de bInterval en endpoints interrupt USB» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 2: Cómo depurar el bInterval de un endpoint interrupt USB, polling rate, latencia HID, report

Trate «Cómo depurar el bInterval de un endpoint interrupt USB, polling rate, latencia HID, reports de input perdidos, reglas de interval en full-speed frente» como una puerta de aceptación independiente para «Depuración de bInterval en endpoints interrupt USB». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 3: Qué significa bInterval

Convierta «Qué significa bInterval» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 4: Síntomas habituales

Trate «Síntomas habituales» como una puerta de aceptación independiente para «Depuración de bInterval en endpoints interrupt USB». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 5: Interpretación full-speed frente a high-speed

Convierta «Interpretación full-speed frente a high-speed» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 6: Sobreproducción del firmware

Trate «Sobreproducción del firmware» como una puerta de aceptación independiente para «Depuración de bInterval en endpoints interrupt USB». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 7: El polling del host no es el read rate de la aplicación

Convierta «El polling del host no es el read rate de la aplicación» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 8: Errores de bInterval en el descriptor

Trate «Errores de bInterval en el descriptor» como una puerta de aceptación independiente para «Depuración de bInterval en endpoints interrupt USB». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Punto de control 9: Checklist de depuración

Convierta «Checklist de depuración» en una afirmación de aprobado o fallo que otra persona pueda repetir. Incluya qué debe aparecer, qué debe estar ausente y qué recuperación es segura. Mantenga intacto el proyecto o captura original hasta que la copia corregida pase la misma prueba.

Punto de control 10: Diagnóstico final

Trate «Diagnóstico final» como una puerta de aceptación independiente para «Depuración de bInterval en endpoints interrupt USB». Registre el estado inicial, el primer cambio visible y el estado final. Si el resultado no coincide con el objetivo descrito, vuelva al último punto confirmado en lugar de continuar sobre suposiciones.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Depuración de bInterval en endpoints interrupt USB	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo depurar el bInterval de un endpoint interrupt USB, polling rate, latencia HID, reports de input perdidos, reglas de	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Qué significa bInterval	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Síntomas habituales	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Interpretación full-speed frente a high-speed	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Sobreproducción del firmware	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado

Aislamiento, recuperación y entrega

Deténgase en el primer límite que falla. Conserve fuente, proyecto, sesión o captura, duplíquelo antes de una edición destructiva y cambie una variable por experimento. Repetir un flujo amplio después de varios cambios puede dar otro resultado sin explicar la causa.

Separe ausencia de evidencia de evidencia de ausencia. Una vista vacía puede indicar entrada, alcance, filtro, permiso, dispositivo, intervalo o estado equivocado. Verifique adquisición o importación antes de interpretar el decoder, editor, informe o exportación.

Antes de entregar, reabra el artefacto y revise inicio, punto de decisión y final. Registre versión, plataforma, configuración, expectativa, observación y reproducción mínima. Elimine o redacte datos sensibles y confirme que el destinatario está autorizado.

Preguntas y respuestas

¿Cuál es la forma fiable más rápida de empezar?

Use el caso representativo más pequeño, escriba el resultado esperado y cambie una variable. Confirme el recorrido básico antes de añadir filtros, efectos, ediciones, automatización o una fuente mayor.

¿Qué evidencia debe guardarse?

Conserve identidad de entrada, versión, plataforma, ajustes, acción exacta, primera transición inesperada y salida final. Cierre y reabra cualquier proyecto, sesión, informe o exportación antes de considerarlo duradero.

¿Cuándo debe repetirse el procedimiento?

Repítalo después de cambios relevantes en aplicación, sistema, driver, firmware, modelo, fuente o flujo. Preserve el caso aceptado anterior como referencia sin modificar.

¿Cuándo está listo para entregar?

Cuando otra persona autorizada identifica la entrada, repite la acción, obtiene el mismo resultado, entiende los límites restantes y abre el artefacto sin depender de estado local no documentado.

Guías relacionadas

Estas páginas en el mismo idioma cubren etapas contiguas sin cambiar el propietario canónico del tema: