Доброго времени суток! Буду очень признателен, если кто-то из сведущих поможет разобраться в вопросе: в чём может быть причина очень долгой отправки пакета от девайса к хосту? Т.е. - имеется девайс, которому с ПК через USB шлётся 2 байта, и после некоторых преобразований (довольно быстрых - 5-10 мкс), девайс записывает 2 байта в буфер своей IN-точки. ПК непрерывно ждёт ответа. Так вот этот буфер опустошается через 4-12 мс(!). Причём очень периодично: пакеты уходят со следующими паузами: 4мс-4мс-12мс-4мс-4мс-12мс... (смотрю осцилом). Если немного подождать, то бывают моменты, когда пакеты идут непрерывно, но тоже только через 4мс (такие моменты быстро пропадают и снова 4-4-12)... На всякий случай проверил ( ) - опросы хоста идут как и положено - через 1 мс. Других USB-устройств не подключено.
Вот такая беда. Операционка - МСВС, юзается LibUSB, используются потоки - всё, что могу сказать про сторону ПК (моя часть - девайс ). Может ли ненагруженная ОС приводить к таким задержкам? Или дело в кривизне рук программиста? Или ещё в чём?

Да, забыл: протокол -1.1, передачи - interrupt, размер буфера - 64. На всякий случай

Еcли идет передача такими короткими пакетами, то так оно и будет. А для interrupt endpoint'a так будет всегда. Если перейти на bulk, накопить приличную порцию на передачу и скинуть за раз, то можно ее совсем с другой скоростью передать, но задержка в начале отправки составит все те же 1-хх ms.

Это-то понятно, что если отправлять больше байтов в одном пакете, то скорость будет больше. Но пакеты шлются с такими же задержками, и причина этих задержек так и не прояснилась. А мне как раз важна скорость реакции... Неужели ничего с этим не поделать?..

Еще раз, если непонятно. При bulk передаче задержка будет до первой посылки, а потом можете хоть мегабайты пересылать, там уже будет все нормально, на уровне драйверов ОС и вашей железки.

Не может так быть. В дескрипторе конечной точки указана периодичность опроса. Это и есть та самая скорость реакции. У вас там что указано ? Например, для мышей и клавиатур она равна 10 мС. И поэтому больше 100 пакетов в секунду в машину ни в жисть не уйдут. Надо корректировать дескриптор. Я уже молчу о том, что кабель должен быть качественным, чтобы пакеты при передаче не бились ...

Сообщение отредактировал kovigor - Apr 15 2011, 19:51

sergeeff, извините, я, видимо, ввёл вас в заблуждение неправильно (не до конца) сформулированным ТЗ
Моя железка - посередине между тестируемым устройством и ПК и обеспечивает их обмен. С устройством общаюсь по определённому протоколу с квитированием,т.е. после того, как оно мне что-то прислало, я должен быстро (~200мкс) отправить ему ответ. А ответ этот получаю от ПК. Поэтому накапливать запросы устройства я не могу.
И вообще, понял, что USB мне совсем не подходит,если времена ответа такие маленькие (о чём раньше думал?.. ).
kovigor: периодичность опроса конечно же 1мс, а то наверное вообще по полчаса ждал бы))
PS И всё-таки: время от помещения данных в буфер точки устройства до его(буфера) очищения при interrupt-передачах (а также любых других при свободной шине) в моём понимании от 1мс до 2мс. Я прав? Откуда же эти 4-12мс?.. Только если действительно пакеты "бьются"... Но это ж как надо биться))). Кабель и плата от Миландра, вроде бы качество должно присутствовать)
Ещё раз спасибо за ответы

Сообщение отредактировал MerQcio - Apr 16 2011, 07:18

Если в буфере конечной точки лежат данные, то с приходом запроса они уходят в машину тут же. Т.е., варианта три. Либо у вас данные не попадают в буфер, когда нужно, либо нарушена последовательность пакетов ((нулевой->первый->нулевой, и т.д.). Ну или пакеты бьются. Очень советую одолжить у кого-то аппаратный сниффер или собрать его самому и посмотреть, что же реально делается на шине.

Кто у вас хост? Если это винда - то у неё HOST-драйвер такой, что отправляет пакеты с задержкой. Циклограмма USB - 1 миллисекунда. => быстрее чем одна миллисекунда - не будет никогда. Interrupt - это то же что и bulk, только медленнее. => bulk по-любому будет лучше.
Любой отравляемый пакет должен быть смаршрутизирован в общую 1-ms-ную циклограмму, в которой кроме вашего устройства предполагается наличие ещё 255 USB-устройств. (даже если этих устройств нет - это ничего не меняет). Пока все данные соберутся в один стандартный длинный запрос - проходит несколько контекстных переключений, квант переключения - 15 миллисекунд. Короче, это особенность винды. Линукс будет сто пудов быстрее. А если возьметё в качестве хоста PIC-32, то тогда выйдете на желаемое быстродействие.

evg123, хост - МСВС, версию не помню...

Сообщение отредактировал MerQcio - May 2 2011, 08:23

Там у Red Hat есть шедьюлер реального времени. (Некто Инго Молнар разработал). http://ru.opensuse.org/Archive:RT_Kernel_Instructions
Можно, по идее, скачать real-time - патч (с официального сайта linux.org) , применить его к вашей системе, и возможно, вы получите ОС реального времени и заставите хост работать быстрее.
Потом есть такая вещь, как WinDriver (версия для LINUX). Я устанавливал, пробовал под Linux-ом. Вещь по-любому достойнее, чем LibUSB.

А где это можно посмотреть поподробнее?

У меня два источника - первый - Практика программирования USB (П. Агуров) http://www.ozon.ru/context/detail/id/2643471/
Второй: стандарт USB2.0 (Это лучше). Файл могу выложить, но он 5 метров. Лучше отсюда: http://www.4shared.com/document/cTGNx2jL/usb_20.html
Может я что-то напутал с цифрами, но в чём я совершенно уверен, так это в том, что запросы со стороны хост-контроллера не могут быть чаще 1 миллисекунды. Они могут быть короткие, но чаще быть не могут. По поводу 15 миллисекунд в винде - это мой личный опыт работы с DSP5509а и борландовским билдером + WinDriver8.11. Я оправлял каждую секунду по одному endpoint-у 100 коротких пакетов в в драйвер, очередь постепенно переполнялась. На осцилографе видел SOF в среднем 1 раз в 15 миллисекунд. Иногда чаще иногда - реже. Трафик мог увеличить только в одном случае - нарастить количество endpoint-ов. Когда задействовал в DSP 7 эндпоинтов - тогда смог отравлять в семь раз больше. Выход увеличить пропускную способность есть два - увеличивать число энд-поинтов или увеличивать объём передаваемых пакетов для одного эндпоинта (но здесь эти подходы не приемлемы).

А что мешает скачать стандарт с http://www.usb.org/developers/docs/ ?