Перейти к содержанию
    

Лишняя задержка перед каждой USB Bulk тразакцией

Может кто встречался с проблемой:

Есть USB full speed девайс с двумя bulk ендпоинтами (один на вход, другой на выход). Написана фирмвара, драйвера под линух и винду, все работает.

Для проверки работоспособности имеется простейшая апликуха, которая пишет 30 байт (это меньше wMaxPacketSize = 32) в девайс и сразу же вичитывает оттуда. Все это в цикле до бесконечности.

Но по хардварному анализатору видно, что виндовский драйвер перед каждой транзакцией делает задержки в 1 мс, т.е. булк пакет посылается (принимается) только в каждом 2-м микрофрейме, т.е. перед каждой транзакцией я в логе анализатора вижу 2 SOF.

При этом линуховый драйвер работает четко - задержек нет, перед каждой транзакцией по одному SOF, а в некоторых случаях умудряется даже в одном фрейме влепить по 2 транзакции (IN, потом OUT).

Девайс и к линуху и к винде подключается один и тот же. Компы с виндой и линухом - разные, но другой периферии кроме этого девайса не подключено. Испытывали на нескольких виндовых компах - все одно и тоже - видна шлет булк пакет только в каждом 2-м фрейме (не первом, не 3-м, не 4-м...).

Это какая-то особенность винды? Глюк моего драйвера виндовского? Писал его на базе примера из ДДК bulkusb. Может нужны какие-то хитрые настройки Дескрипторов usb девайса, которые для линуха подходят а для винды приводят к задержкам?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Давным давно мы боролись с подобным эффектом. Зависело только от железа на PC. Лучше всего себя вели родные интеловские чипсеты. Вообще, виндюки такой режим не любят совсем. Им бы в одну сторону кучу сразу - тогда получается более-менее быстро.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Скорее всего это опция в виндовом драйвере - отсылка пустого фрейма для индикации завершения данных. Встречал такую же опцию в функциях TMS320VC5509, работающих с USB. Там при инициализации транзакции нужно было передавать флаг USB_IOFLAG_NOSHORT и тогда фрейм с нулевой длиной не отсылался.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо за советы, буду что-то пробовать.

У меня сейчс фреймы с нулевой длиной не отправляются. Отправляются фреймы с меньшей чем wMaxPacketSize длиной чего по идее достаточно чтобы стек определил что данных больше не будет. У меня просто пустой фрейм получается перед каждым фреймом с булк пакетом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

От этого ничего не зависит. Нижним уровнем и фреймами все равно занимается микрософтовский драйвер и обойти его правильно практически невозможно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

От этого ничего не зависит. Нижним уровнем и фреймами все равно занимается микрософтовский драйвер и обойти его правильно практически невозможно.

А зачем его обходить? И как?

А от формы отправки запросов к нему зависит очень многое.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

да, драйвер на чистом DDK, за основу взят пример bulkusb (просто добавил свой код туда). Правда компилируется не make файлом от DDK а в vs2005 как проект (как описано тут)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

да, драйвер на чистом DDK, за основу взят пример bulkusb (просто добавил свой код туда). ...

 

Если вы полностью повторили код, то могли заметить, что вывод в endpoint буферизован, и если количество байт данных превышает MAX transfer size , то из функции завершения вызывается запрос для отправки оставшихся данных и т.д.. Если вы из приложения вызовете Write c количеством данных больше, чем Max transfer size, то сможете посмотреть, есть ли "дыра" в передаче и каков ее размер. После этого можно будет сделать некоторые выводы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я столкнулся с тем, что у HID обмен через контрольный канал может работать поразному. По описанию д.б. так: в случает посылки HID устройством NAK хосту, следующая попытка будет предпринята только в следующем кадре, т.е. через милисекунду. В реальности на некоторых мамках хабы работают не так. Они сразу же после получения NAK передачу(или приём) повторяют. Причём это явно не зависит от программы. Т.к. на ОДНОМ компьютере USB, установленные на матери, и в PCI (2 щт.) работают по разному. И возможны любые варианты. Причём замечено, что те, которые на чипсете VIA, как правило, стандарту не соответствуют.

Так я это к тому, что и у вас м.б. такая ситуация. Не в программе дело, а в аппаратуре.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Но по хардварному анализатору видно, что виндовский драйвер перед каждой транзакцией делает задержки в 1 мс, т.е. булк пакет посылается (принимается) только в каждом 2-м микрофрейме, т.е. перед каждой транзакцией я в логе анализатора вижу 2 SOF.

 

USB хост обслуживается драйвером Windows.

 

Стандартно для FS секунда разбивается на 1000 фреймов.

Драйвер windows подстраивается под такое деление.

Раз в 1 миллисекунду, драйвер хоста (точнее планировщик задач для хоста) делит полосу пропускания USB между устройствами.

Таким образом в 1 фрейм планируется одна передача для устройства.

После передачи, планировщик получает задание на прием 30 байт и в следующий фрейм ставит задачу хосту получить 30 байт.

Таким образом, меньше чем в 2 фрейма ping-pong не получится.

 

Так что, по моему никакой проблемы в драйвере и устройстве нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

....

Таким образом в 1 фрейм планируется одна передача для устройства.

После передачи, планировщик получает задание на прием 30 байт и в следующий фрейм ставит задачу хосту получить 30 байт.

Таким образом, меньше чем в 2 фрейма ping-pong не получится.

 

Так что, по моему никакой проблемы в драйвере и устройстве нет.

 

Вы немного ошиблись - правильнее будет так: Таким образом в 1 фрейм планируется одна транзакция для 1-го endpoint.

Таким образом, если запрошено несколько endpoints для одного устройства, то транзакции могут идти и в одном фрейме.

Я уже здесь в форуме писал, как получить запрос - ответ в одном фрейме.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если я правильно понял то одна транзакция (в интервале 1 мс) для одой конечной точки. Это соотвествует всем типам передач (bulk, изохорные, управление и прерывания) ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...