Depuração de bInterval em endpoint de interrupção USB: polling rate, latência HID e entrada perdida

Endpoints de interrupção USB são usados por teclados, mouses, controles, sensores, painéis touch, scanners de código de barras, nobreaks e muitas ferramentas HID customizadas. Quem busca por "USB bInterval", "HID polling rate", "USB interrupt endpoint latency", "missed input reports", "USB device 125Hz 250Hz 1000Hz" e "bInterval full speed high speed" geralmente sente a entrada atrasada ou recebendo relatórios na frequência errada.

O Bus Scope ajuda porque o comportamento de polling é definido pelos descritores de endpoint e pelo timing real do barramento. A interface do sistema operacional pode mostrar apenas "dispositivo conectado"; a captura mostra qual intervalo o host realmente usa.

O que significa bInterval

Um descritor de endpoint de interrupção inclui bInterval. Esse valor descreve o polling interval, mas a interpretação depende da velocidade e do tipo de endpoint.

Distinções importantes:

• Endpoints de interrupção low-speed e full-speed usam intervalos baseados em frames em milissegundos.
• Endpoints de interrupção high-speed usam uma codificação diferente baseada em microframes.
• O agendamento do host controller e a topologia de hub podem afetar o timing observado.
• O timing de leitura da aplicação não é a mesma coisa que o polling do barramento USB.

Se o engenheiro só olha os callbacks da aplicação, pode perder o schedule real do endpoint.

Sintomas comuns

Problemas de polling interval aparecem como:

• Mouse ou controle parecem lentos.
• Relatórios de entrada HID chegam a cada 8 ms em vez de 1 ms.
• Dispositivo anuncia 1000 Hz, mas se comporta como 125 Hz.
• Dados de sensor vêm em rajadas.
• Scanner de código de barras perde leituras rápidas.
• Painel touch fica lento depois do resume.
• Firmware envia relatórios mais rápido do que o host faz polling.
• Modo high-speed muda o timing do relatório sem aviso.

Esses problemas costumam parecer latência ou responsividade, mas a evidência raiz está no descritor USB e no timing dos pacotes.

Interpretação em full-speed versus high-speed

O mesmo valor numérico de bInterval pode significar timings efetivos diferentes dependendo da velocidade. Um endpoint HID full-speed com bInterval=8 não é o mesmo modelo de agendamento que um endpoint high-speed com o mesmo byte.

A depuração deve capturar:

• Velocidade negociada real.
• Descritor de endpoint.
• Endereço do endpoint.
• Tipo de transferência.
• bInterval.
• Cadência observada do IN token ou da transferência.
• Timing do payload do relatório.

O Bus Scope deve mostrar valores do descritor e timing observado lado a lado.

Sobreprodução no firmware

Alguns firmwares geram relatórios de entrada mais rápido do que o host faz polling. Esses relatórios podem ser sobrescritos, coalescidos ou descartados antes mesmo de o host ver.

Sintomas:

• Logs internos do dispositivo mostram eventos.
• O host recebe menos relatórios.
• Toques rápidos em botão são perdidos.
• Movimento parece suavizado ou atrasado.
• Relatórios depois de uma rajada trazem apenas o estado mais recente.

Isso não é perda de pacote USB. É problema de contrato entre firmware e polling.

Polling do host não é taxa de leitura da aplicação

Uma aplicação pode ler a cada 1 ms, mas o host USB pode estar fazendo polling a cada 8 ms. Ou o host faz polling no tempo certo, mas o loop de eventos da aplicação processa os dados depois.

A captura de pacotes separa:

• Intervalo de polling do barramento.
• Timing de resposta do dispositivo.
• Buffer do driver de host.
• Latência do callback da aplicação.

Essa separação é crítica para casos de suporte de latência HID.

Erros comuns no descritor bInterval

Bugs frequentes de descritor incluem:

• Anunciar bInterval=10 em vez de 1 por engano.
• Copiar intervalo de full-speed para descritor high-speed sem ajustar.
• Usar um intervalo no descritor e outro na expectativa do HID.
• Comentário no firmware diz 1000 Hz, mas o descritor diz menos.
• Mudança de alternate setting altera o intervalo, mas o firmware não trata.

O byte no descritor é o contrato que o host usa para agendar.

Checklist de depuração

Use este fluxo:

1. Capture a enumeração.
2. Identifique os descritores de endpoint de interrupção.
3. Registre a velocidade real do dispositivo.
4. Decodifique o bInterval.
5. Meça a cadência observada de interrupt IN.
6. Compare com a polling rate esperada.
7. Dispare eventos rápidos de entrada.
8. Confira se relatórios são perdidos ou coalescidos.
9. Compare porta direta versus hub.
10. Preserve descritor e evidência de timing juntos.

Diagnóstico final

Latência em interrupção USB não é só um problema de performance da aplicação. Ela depende do bInterval do endpoint, do modo de velocidade, do agendamento do host, da geração de relatórios e do buffering do firmware.

O Bus Scope ajuda a provar se um dispositivo HID ou de interrupção está realmente sendo polled na taxa pretendida, e se a entrada perdida vem do descritor, do buffering do firmware ou do timing de host e aplicação.