|
Violet
Гость
|
 |
« : 16-01-2004 16:06 » |
|
Может кто досконально разбирался, помогите, плз...
USB-девайс (v.1.1) собственной разработки, можем рулить им как хотим. Пишу драйвер верхнего уровня для Windows (в основе пример их XP DDK). Проблема в запросе на чтение из устройства.
User Mode: ReadFile(... ...);
Kernel Mode: DispatchReadWrite(... ...)
{
...
IoCallDriver(pdx->LowerDeviceObject, Irp);
...
}
При этом хост-контроллер генерит в шину USB запросы "IN", а девайс, если не имеет данных, выдает "NAK", мол нету у меня данных. Но если вдруг у девайса данных не будет вообще то в драйвере обработчик окончания транзакции OnReadWriteComplete(...) никогда не вызовется и в приложении ReadFile(...) не вернет управление, а в шине так и будет молотиться "IN" - "NAK", "IN" - "NAK"... Сейчас мы выходим из положения так: девайс отправляет на запрос чтения zero-packet и все довольны OnReadWriteComplete(...) вызывается с 0-размером буфера в irp'е, и ReadFile(...) говорит ОК, длина данных 0 байт.
Однако драйвера на крутые USB девайсы (3Com) вытворяют следующее, если данных в девайсе нет, т.е. приходит "NAK", запрос завершается до следующего вызова DispatchReadWrite(...). Наверное, они как-то манипулируют полями в структуре _URB при запросе, в общем как-то заставляют хост-контроллер вернуть управление при первом же полученном NAK'е. Но как...?
Если есть какие-либо соображения, поделитесь, плз.
|
|
|
|
|
Записан
|
|
|
|
|
Lex
|
|
« Ответ #1 : 16-01-2004 17:27 » |
|
Violet, Девайс должен отдавать пакет нулевой длины, а не NAK, если у него нет данных. NAK это значит что пакет принят нетравильно, несовпала контрольная сумма.
Общий алгоритм работы firmware девайса таков. Положил данные в буфер, пришел IN положил новые данные, если нечего класть положил 0 байт.
|
|
|
|
|
Записан
|
Megabyte be with you!
|
|
|
|
Violet
Гость
|
|
« Ответ #2 : 17-01-2004 08:53 » |
|
Не совсем понятно, почему девайс ДОЛЖЕН отдавать пакет нулевой длины; разве это требуется стандартом, по-моему нет. NAK - это штатный ответ девайса на запрос IN, если нет данных в буфере.
Вариант с нулевым пакетом прокатил бы, если бы у девайса был только один буфер на отправку в USB, а если из три (как у нас, например), тогда придется их забивать нулевыми пакетами, а как только появятся данные, то они сразу не уйдут, а подождут пока освободятся первые два буфера с нулями - очень неэффективно.
Еще раз повторюсь, мы сканили USB-шину при работе классных фирменных девайсов, там никаких пакетов с нулевой длиной небыло, на первый же IN - NAK драйвер отваливал и в следующую мс начинал новый фрейм.
|
|
|
|
|
Записан
|
|
|
|
|
Lex
|
|
« Ответ #3 : 20-01-2004 15:06 » |
|
почему девайс ДОЛЖЕН отдавать пакет нулевой длины; разве это требуется стандартом, по-моему нет
Почитай стандарт внимательнее. Имено так и должен проходить обмен. NAK означает неправильно принятые данные. О ответ пакет с нулевой длинной имено стандартный ответ девайса на запрос IN? если ему нечего отдавать. RTFM стандарт USB 1.1 глава 8  |
|
|
|
|
Записан
|
Megabyte be with you!
|
|
|
|
HSA
Гость
|
|
« Ответ #4 : 20-01-2004 15:44 » |
|
Используй точку IN Interrupt. Крутые ее и используют. При правильном подходе твой драйвер будет слать постоянно запрос на чтение (по Interrupt) через определенные, короткие (мс) промежутки времени. Если у тебя будут данные для приема, можешь к примеру в ответе на этот запрос отправить длину пакета данных. Таким образом тебе не придется постоянно гонять по Bulk запросы с соответствующим пакетом.
|
|
|
|
|
Записан
|
|
|
|
|
Lex
|
|
« Ответ #5 : 20-01-2004 16:13 » |
|
Недавно выяснил, что в USB 2.0 при использовании Interrupt можно молучить скорость 2048 * 1000 байт/сек. при Изохронном 3072 * 1000 байт/сек. А вот основная производительность порядка 8М/сек достигается на Bulk протоколе.  Хотя там максимальная длина пакета всего 512 байт. |
|
|
|
|
Записан
|
Megabyte be with you!
|
|
|
|
HSA
Гость
|
|
« Ответ #6 : 20-01-2004 16:53 » |
|
Interrupt используется и для сканирования на предмет наличия данных, а так же и для управлением протоколом работы девайса (не путать с Control - там идет настройка протокола работы USB, дескрипторы, инициализация и прочее). Скорость у него меньше, чем у BULK, но это и не важно. Главное, он имеет высокий приоритет и, как и из названия видно, "пробивает" с заданной скоростью запрос. Тебе не нужно там пересылать большие объемы. Только определил, что данные есть и вперед - читай BULK сколько нужно.
У меня проблема как раз такая же. Нужно для диплома создать драйвер для моего девайса (1 Interrupt и 2 Bulk), проблема в зацикливании запроса на девайс. Все уже просто горит. Если есть мысли или появятся - скажи, как или пиши на мыло.
|
|
|
|
|
Записан
|
|
|
|
|
