Понимание обработки USB и задержки опроса в хост-контроллере USB

Я делаю измерения, связанные с задержкой USB, с помощью микросхемы преобразователя USB-UART (чип CP2102 Silicon Laboratories). Я отправляю массив данных, когда 0xeeон получен, микроконтроллер будет повторять байт. Я беру временные метки между моментом, когда я начинаю отправлять данные, до тех пор, пока я не получу файл 0xee. Чтобы узнать время обработки на чипе CP2102, я измерил задержку подтверждения чипа (это время между точечным пакетом и мгновенным пакетом подтверждения, полученным от чипа). Чип USB-UART представляет собой объемное устройство с двумя конечными точками (IN и OUT), максимальный размер пакета 64 байта, используется полноскоростной USB 2.0 (12 Мбит/с). Я беру 500 выборок для каждого размера данных (1 байт отправляется 500 раз и выполняются измерения, аналогично 2 байта до 127 байт).

Я построил три графика: один для total_delay, chip_ack_delayи total_delay_without_uart_delay_chip_ack_delay = total_delay - chip_ack_delay - 86.6*data_sizeэта задержка должна представлять задержку обработки и задержку опроса USB на главном компьютере. Я использую ПК с Linux с Ubuntu 16.04, скорость передачи UART составляет 115200 (отсюда 86,6 микросекунд на байт). Понятно, что задержка подтверждения чипа увеличивается по мере того, как размер пакета становится больше 64 байт, поскольку приходится ждать две транзакции. Я не могу интерпретировать второй график. Он показывает, что опрос на стороне хоста и задержка обработки уменьшаются, когда размер пакета превышает 64 байта. Может ли кто-нибудь объяснить, как это интерпретировать? Или я что-то пропустил здесь?

Кстати, я измерил задержку ответа чипа с помощью лога USBmon. На графике по оси X отложен размер данных, по оси Y отложена диаграмма MATLAB, на которой показан диапазон значений задержки, измеренной для определенного размера данных.

введите описание изображения здесь

Чтобы понять синхронизацию, вам нужно понимать, что вы имеете дело со следующей цепочкой: хост-приложение -> хост-драйвер -> протокол USB -> преобразование UART -> передача UART > драйвер MCU UART > приложение MCU, ищущее маркер EE -> MCU UART. передача -> преобразование UART-to-USB -> протокол USB -> хост-драйвер USB -> хост-приложение. Может быть много странностей во взаимодействии/синхронизации между всеми этими границами вдоль этого конвейера.
Кроме того, вам нужно немного больше узнать о протоколе USB, также известном как SIE — механизм последовательного интерфейса. Что вы подразумеваете под «точечным пакетом» и «мгновенным пакетом подтверждения, полученным от чипа»? Мгновенный пакет ACK приходит менее чем через 1,7 мкс от чипа, иначе хост обнаружит «ошибку транзакции».
@Al У меня точная настройка, как вы объяснили. Я вычитаю задержку, связанную с транзакцией UART, которая составляет 86,6 микросекунд на байт, и задержку подтверждения чипа. Приложение MCU очень простое, я написал логику внутри обработчика прерываний uart. Как только байт получен, я сравниваю 0xeeего с совпадением и повторяю байт. Что касается момента времени, я беру метку времени перед записью данных в последовательный порт, снова я беру метку времени после получения эха. Я вычитаю старую метку времени из новой. Что касается задержки стека USB, я понимаю, что стек и драйвер добавляют некоторую задержку, но она должна быть постоянной.
Должен ли ack приходить в пределах 1.7us? Я не уверен, что USBmon показывает большую задержку перед получением подтверждения. Я могу прикрепить USBmon, если вы хотите посмотреть.
Я говорю об ACK протокола USB на уровне пакетов USB. Я не знаю, какой «ack» вы имеете в виду, поэтому я предложил быть более точным в терминологии, когда в заголовке вашего вопроса говорится «задержки USB», а вы добавляете какие-то неизвестные термины, такие как «точечные пакеты».
Я говорю об подтверждениях в журнале USBmon в Linux. Они отправляются после передачи полных данных. Я не вижу подтверждения для каждого переданного USB-пакета. Не для каждых 64 байт. Он отправляется ведомым устройством после получения полных данных, хотя их размер превышает 64 байта.

Ответы (1)

В техническом описании CP210x упоминаются большие буферы FIFO как на стороне передачи, так и на стороне приема.

Я сильно подозреваю, что они также оптимизируют использование USB (и хост-процессора), «собирая» данные uart в более крупные пакеты USB.

Это будет означать, что данные удерживаются до тех пор, пока в FIFO не будет 64 байта или приемник не будет активен в течение нескольких битов.

Обратите внимание, что объемные 64-байтовые пакеты являются особыми: они не завершают транзакцию на хосте (если буфер не слишком мал).

На самом деле вы можете увидеть «высокий провал» для 64-байтовых транзакций, поскольку они могут выполняться как один 64-байтовый пакет, за которым следует пакет с нулевым байтом.

Примечание: возможно, стоит перепроверить тайминги с помощью высокоскоростного концентратора USB 2.0 между хостом ПК и CP210x. Эта конфигурация может использовать0,25 мсСинхронизация mircoframe 0,125 мс доступна на высокой скорости.

Аппаратного сниффера у меня нет, все тайминги меряю программно. Вы имеете в виду, что хост-контроллер некоторое время ждет следующих байтов, прежде чем отправлять USB-пакет, если он меньше 64 байт?
Синхронизация микрокадра в режиме HS составляет 0,125 мс, а не 0,25.
Я не думаю, что какой-либо из чипов CP210x поддерживает высокоскоростной режим, в техническом описании указана только полная скорость. Ширина кадра USB на полной скорости составляет 1 мс, я не уверен, играет ли ширина кадра роль в случае массовых конечных точек.
Понимание обработки USB и задержки опроса в хост-контроллере USB
СпросиСетьПолитика конфиденциальности1y, 0v