Отладка bInterval interrupt-конечной точки USB: поллинг, latency HID, Full-Speed vs High-Speed и пропущенный ввод

USB interrupt-конечные точки используются клавиатурами, мышами, игровыми контроллерами, датчиками, тач-панелями, сканерами штрихкодов, UPS и многими кастомными HID-инструментами. Пользователи ищут «USB bInterval», «HID polling rate», «USB interrupt endpoint latency», «missed input reports», «USB device 125Hz 250Hz 1000Hz», «bInterval full speed high speed», когда ввод ощущается задержанным или репорты приходят с неправильной частотой.

Bus Scope полезен тем, что поведение поллинга задаётся endpoint descriptors и реальным таймингом шины. UI ОС может показать только «device connected»; захват покажет, какой интервал хост реально использует.

Что значит bInterval

Дескриптор interrupt-конечной точки содержит bInterval. Это значение описывает интервал поллинга, но интерпретация зависит от скорости и типа конечной точки.

Важные отличия:

• Low-speed и full-speed interrupt-конечные точки используют миллисекундные фреймовые интервалы.
• High-speed interrupt-конечные точки используют другую кодировку на основе микрофреймов.
• Расписание хост-контроллера и топология концентратора могут влиять на наблюдаемый тайминг.
• Read-тайминг приложения — это не то же, что USB-поллинг.

Если инженер смотрит только на колбэки приложения, он может пропустить реальное расписание конечной точки.

Типичные симптомы

Проблемы с интервалом поллинга проявляются как:

• Мышь или контроллер кажется лаговой.
• HID input-репорты приходят каждые 8 мс вместо 1 мс.
• Устройство заявляет 1000 Гц, но ведёт себя как 125 Гц.
• Данные датчика рваные.
• Сканер штрихкодов теряет быстрые сканирования.
• Тач-панель задерживается после resume.
• Прошивка шлёт репорты чаще, чем хост поллит.
• High-speed-режим неожиданно меняет тайминги репорта.

Эти проблемы часто выглядят как latency или отзывчивость, но корневые доказательства в USB-дескрипторе и таймингах пакетов.

Интерпретация Full-Speed vs High-Speed

Одно и то же числовое значение bInterval может означать разное эффективное время в зависимости от скорости. Full-speed HID-конечная точка с bInterval=8 — это не та же модель расписания, что high-speed-конечная точка с тем же байтом.

Отладка должна захватить:

• Реальная согласованная скорость.
• Endpoint descriptor.
• Адрес конечной точки.
• Transfer type.
• bInterval.
• Наблюдаемая каденция IN-токенов или передач.
• Тайминг payload репорта.

Bus Scope должен показать значения дескрипторов и наблюдаемые тайминги вместе.

Перепроизводство прошивки

Некоторые прошивки генерируют input-репорты чаще, чем хост поллит. Эти репорты могут быть перезаписаны, слиты или отброшены до того, как хост их увидит.

Симптомы:

• Внутренние логи устройства показывают события.
• Хост получает меньше репортов.
• Быстрые нажатия кнопок пропускаются.
• Движение выглядит сглаженным или задержанным.
• После бёрста в репортах только последнее состояние.

Это не потеря пакетов на USB. Это баг контракта буферизации прошивки и поллинга.

Поллинг хоста ≠ частота чтения приложения

Приложение может читать каждую 1 мс, но хост USB может поллить только каждые 8 мс. Или хост поллит вовремя, а event loop приложения обрабатывает данные позже.

Пакетный захват разделяет:

• Интервал поллинга шины.
• Тайминг ответа устройства.
• Буферизацию хост-драйвера.
• Задержку колбэка приложения.

Это разделение критично для кейсов поддержки по latency HID.

Ошибки bInterval в дескрипторе

Типичные ошибки дескриптора:

• Случайно заявлен bInterval=10 вместо 1.
• Неверное копирование full-speed-интервала в high-speed-дескриптор.
• Использование одного интервала в ожиданиях HID-дескриптора и другого в endpoint descriptor.
• Комментарии в прошивке утверждают 1000 Гц, а дескриптор — медленнее.
• Alternate setting меняет интервал, а прошивка этого не обрабатывает.

Байт в дескрипторе — это контракт, относительно которого хост строит расписание.

Чек-лист отладки

Используйте такой воркфлоу:

1. Захватите перечисление.
2. Определите endpoint descriptors interrupt-конечных точек.
3. Зафиксируйте реальную скорость устройства.
4. Декодируйте bInterval.
5. Измерьте наблюдаемую каденцию interrupt IN.
6. Сравните с ожидаемой частотой поллинга.
7. Триггерьте быстрые события ввода.
8. Проверьте, не пропущены ли или не слились репорты.
9. Сравните прямой порт и через концентратор.
10. Сохраните дескриптор и данные тайминга вместе.

Итоговый диагног

USB interrupt-latency — это не только проблема производительности приложения. Она зависит от endpoint bInterval, режима скорости, расписания хоста, генерации репортов и буферизации прошивки.

Bus Scope помогает доказать, реально ли HID или interrupt-устройство опрашивается с целевой частотой и вызван ли пропущенный ввод дескрипторными настройками, буферизацией прошивки или таймингами хоста/приложения.