Может кто встречался с проблемой:
Есть 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 длиной чего по идее достаточно чтобы стек определил что данных больше не будет. У меня просто пустой фрейм получается перед каждым фреймом с булк пакетом.

Драйвер для Win на чистом DDK?

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

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

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

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

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

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

Стандартно для FS секунда разбивается на 1000 фреймов.
Драйвер windows подстраивается под такое деление.
Раз в 1 миллисекунду, драйвер хоста (точнее планировщик задач для хоста) делит полосу пропускания USB между устройствами.
Таким образом в 1 фрейм планируется одна передача для устройства.
После передачи, планировщик получает задание на прием 30 байт и в следующий фрейм ставит задачу хосту получить 30 байт.
Таким образом, меньше чем в 2 фрейма ping-pong не получится.

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

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

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