USB Driver - помогите начинающему.

[SergeXP]

Пишу драйвер при помощи numega.
Устройство - конвертер CAN-USB.
Задача драйвера: обмен короткими пакетами, установка настроек устройства и мониторинг ошибок.

Вопрос такой, можно ли по приходу данных из устройства установить в драйвере какой нибудь флаг чтобы из приложения читать данные по событию (по прерыванию), а не по запросу. Можно ли использовать для этого объект KInterrupt?
А то у меня сложилось такое мнение что инициатива на чтение/запись для USB всегда идет от приложения.

[SlavaI]

по событию (по прерыванию)

Я не очень понял- читать из юзер мод приложения- тогда по событию конечно можно, по прерыванию- нет.
А вобще-то контроллером USB управляет система своим драйвером, а ты имеешь только интерфейс от этого драйвера. В винде для этого URB запросы придумали всякого рода(как на чтение так и на запись)- bulk, interrupt и т.д.

А то у меня сложилось такое мнение что инициатива на чтение/запись для USB всегда идет от приложения.

Можно сказать и так. Вобще то так всегда для любого приложения- если оно читать не хочет в него трудно что-то записать   . USB девайсы не устраивают прерываний- если они что то хотят передать, то сообщают об этом контроллеру, который постоянно опрашивает их. А уже сам контроллер регистрирует прерывание в системе(если ему это надо).

[SergeXP]

SlavaI,
Большое спасибо за ответ!

Ну то есть мне надо в приложении всё время делать ReadFile, и если что-то удалось прочитать то данные пришли.
Понятно что принудительно в приложение  не запишешь,
я бы хотел как для последовательного порта:
SetCommMask(hCom,EV_RXCHAR);//маска на прием
WaitCommEvent(hCom,&dwEvtMask,&TMOver);
if (GetLastError()==ERROR_IO_PENDING)
  switch (WaitForSingleObject(TMOver.hEvent,INFINITE)) {
 case WAIT_OBJECT_0: если что-то пришло только тогда читаем

Подобным способом для USB нельзя? (Я понимаю что SetCommMask и WaitCommEvent не для USB, просто принцип показал)

[SlavaI]

Почитай протокол работы своего девайса. Может оно когда ему есть что передать, держит это в буфере, сообщает каким нибудь образом об этом устройству(каким образом- читай в документации) то есть например читая како-то канал ты узнаешь что надо по другому каналу читать данные. Способов можно придумать массу. А у USB ещи три способа доставки данных.
А вобще на USB надо инициировать чтение с устройства, например устроить полинг, то есть постоянный опрос.

[SergeXP]

SlavaI,
Спасибо. Всё ясно, буду делать поллинг. А протокол будет таким как мы договоримся с разработчиком девайса, он рядом сидит

[SlavaI]

А протокол будет таким как мы договоримся с разработчиком девайса, он рядом сидит

Так он тебе все может рассказать. Там сразу станет ясно как надо сделать. Кстати Read запрос можно заблокировать в драйвере, пока не будет данных, а можно отпустить, если он асинхронный.

[SlavaI]

Например. Можно по Interrupt transfer узнавать о наличии и количестве данных, а читать по Bulk transfer.

[SergeXP]

SlavaI,
Для него это тоже первый опыт с USB, поэтому надо понять как оптимально сделать протокол.

Вот ещё вопрос появился, для Interrupt и Isochronous, Completion routine не нужна?

[Lex]

SlavaI, Interrupt от Bulk  в USb отличается только тем, что при Interrupt  передача идет со строго заданной в дескрипторе цикличностью, например пакет 8 байт каждые 2 милисикунды. В bulk виксируется только длина пакета, а сколько ты их успеешь прочитать за время фрейма.

Идеология USB такая, что информация выдается только по запросу с хоста.
Разные протоколы только определяют как используется пропускная способность канала.

[SergeXP]

Lex,
А в драйвере хост контроллера есть буфер по приёму или мне в своем драйвере надо делать собственный буфер чтобы не потерять кадр?

[SlavaI]

Вот ещё вопрос появился, для Interrupt и Isochronous, Completion routine не нужна?

Что-то я не понял. Это ты про Windows? А почему такой вопрос возник? Это скорей относится к способу обработки IRP пакета. Почему ты решил что они или обязательно нужны или совсем не нужны? Драйверу контроллера ты передаешь указатели на буфера и их длинну, а он(как уже указал Lex вернет тебе количество записанных байт), то есть самому переносить данные в Completion не обязательно.
 Хотя во всех драйверах что я видел CompletionRoutine была, но это обычная практика для большинства драйверов, надо же как-то синхронизовать себя с завершением запроса.

[Lex]

SergeXP, драйвер хоста тебе отдаст пакет, который получил в ответ на твой запрос. А дальше уж сам его сохраняй.

Кстати чего вы хотите от протокола, т.е. какие данные вы будите по нему гонять?

[SergeXP]

SlavaI,
Да это я про способ обработки.
С Completion ясно, спасибо.

[SlavaI]

Да это я про способ обработки.

Ну в общем ты понял- через URB запрос на контроллер, в буффера тебе запишут и скажут сколько. Дальше уже сам решай что делать.

[SergeXP]

Lex,
Пакеты по 16 байт, скорость до 1 Мбит, потери недопустимы.

Но ведь хост контроллер всё равно принимает данные из USB,
даже если приложение их не читает? Значит какой-то аппаратный или программный буфер у него имеется?

[Lex]

Пакеты по 16 байт, скорость до 1 Мбит, потери недопустимы.

Interrupt - максимальная частота посылки пакетов 1мс, размер 64 байта.
Bulk - максимальный размер пакета 64 байта, скорость сколько успеешь передать. реальнаа скорость сильно зависит от компьютера и висят ли на этом контролере еще девайсы. на PII-233(кажется так) скорость была порякда 120 кБайт/сек. На PIII-800 порядка 150 кБайт/сек.
Isohronous - максимальная скорость передачи пакет 1023 байта раз в миллисекунду. Но у него есть одно но. Правильность доставки не проверяется. Изначально предназначался для передаци потокового видео или аудио, где важно постоянный поток, и допускаются выпадения данных. Т.е. если его использовать, то нужно придумывать как защищать пакеты.
Все это для USB 1.1

В USB 2.0 HighSpeed размер пакета на Bulk и Interrupt увеличины до 2048 байт.
Ну и фреймы там почаще идут кажется Более точно сказать не могу, т.к. 2.0 еще не изучал внимательно.

Конечно в контроллере есть буфер на прем данных. Обычно он на 1-2 пакета. В драйвере скорее всего тоже есть буфер, но он тоже небольшой.

[SergeXP]

Lex,
Спасибо!