Седой

Все правильно, так и будет при таком использовании.

Не знаю. Но судя по требованию Microsoft - минимальной длительности обработчика прерывания (конкретное значение не указывается, но судя по требованию на spinlock не более 25-30 мкс) - то вряд ли.

Если вести речь о задержке между запрос-ответ и вторым запрос-ответ - то точно не меньше 1 мс.

Я уже писал: Если вы переводите IN в stall - то так и будет.

Давайте конкретизируем задачу. Насколько я понял, автору ветки необходимо получить минимальное время реакции в процессе ЗАПРОС-ОТВЕТ. Сейчас у него следующая ситуация - USB устройство может отвечать быстро, а хост не готов принимать. Разрешить эту проблему можно (ИМХО)только в драйвере устройства совместно с firmware устройства следующим образом: 1. Устройство реализует два endpoint - одно OUT (запрос) и одно IN (ответ). 2. Драйвер реализует обработчик определенного DeviceControl - запрос/ответ, запрашиваемый приложением. 3. В этом обработчике драйвер делает следующее: 3.1. Создает URB для IN и направляет его нижележащему драйверу (шины), обязательно указывая функцию завершения, назовем ее CompleteIN . 3.2. Создает URB для ОUТ с данными, полученными от приложения, и также направляет его драйверу шины с функцией завершения CompleteOUT. 3.3. Устанавливает флаг PENDING. 4. Функции завершения делают следующее: CompleteIN: завершает DeviceControl с данными полученными от устройства (ответ). CompleteOUT: если произошла ошибка, то прерывает запрос IN и завершает DeviceControl c ошибкой, если нет - не делает ничего. Реализация такого механизма позволит устройству не только максимально быстро ответить на запрос (даже в пределах одного фрейма), но и передавать данные хосту во время приема пакетов транзакции запроса. PS0. Насколько я знаю, ни один из фирменных драйверов (Cypress, Silabs, NXP, Atmel, FTDI) не имеет такого механизма, так что придется делать свой драйвер. PS1. Для транзакций, больших длины пакета, возможно можно поменять местами 3.1. и 3.2. PS2. Возможно, такой механизм можно использовать и с фирменным драйвером, запуская функцию чтения в отдельном потоке раньше функции записи в другом потоке. Но это потребует работы с синхронизацией потоков. ИМХО, возни больше чем с драйвером. PS3. Можно также попробовать с фирменными драйверами, если они позволяют, поиграть с overlapped. PS4. Вышеизложенный механизм работает - используем в своих драйверах.

a также организация обмена драйвера с устройством - ведь можно запустить чтение IN пакета до записи OUT.

WinUSB? http://www.microsoft.com/whdc/device/conne...nUsb_HowTo.mspx

Как их затрясло, когда парень показал "крутость" силабовских разработчиков софта.

1. Открыть драйвер хаба. 2. Вызвать DeviceIoControl с кодом IOCTL_USB_HCD_DISABLE_PORT 3. Вызвать DeviceIoControl с кодом IOCTL_USB_HCD_ENABLE_PORT 4. Закрыть драйвер хаба. В Windows XP можно и через прямой вызов CLEAR_FEATURE и SET_FEATURE Более детально см. usbioctl.h и usbuser.h в DDK. PS. Более простой способ http://www.usb.org/phpbb/viewtopic.php?t=1...highlight=reset PS1. Еще можно использовать утилиту devcon (в DDK ее исходник), скачать http://support.microsoft.com/?kbid=311272

Можно попробовать выключить и включить питание порта хаба, к которому подключено устройство. Делается это программным способом, если хаб это поддерживает . Попробуйте также отключить и потом включить использование хаба в диспетчере устройств.

Сходите на http://club.shelek.com/ там форум( раздел Drivers) и книги ( автор Walter Oney). Так же полезно просмотреть исходники драйверов от Cypress (EZ-USB).

C8051F326

На 10м точно будет работать.

Так на ПЛИС и проверте, полчаса работы.

Пример простейшего HUBа http://oschmid.home.solnet.ch/mt/can-hub/can-hub.php И пример подключения звездой без HUBa http://caraca.sourceforge.net/caraca_star.pdf

Речь не идет о High Speed кабелях. Хотя этот тоже брали. Претензий нет. PS. Ну, а по поводу цены ... анекдот про галстуки и "новых русских" помните?

Вы сами решили проблему, взяв нормальный кабель. Мы тоже это проходили. Сейчас кабеля берем в ЭФО.

Вот и выложи в проектах на сахаре. А "по-взрослому" написано в спецификации USB, в документации и аппнотах на контроллер от Microchip, в Windows DDK, "взрослее" не получится, не трать время.

Репитер, созданный по схеме, работать не будет.

Мне понравилось. Коротко, ясно и работает (как уверяет автор, сам не проверял). Стиль изложения - авторский - и это есть хорошо.

TJA1020 от NXP (Philips)

Информации для отладчика в драйвере нет. Есть вызовы некоторых dbg функций с сообщениями для монитора. Драйвер специально создан для данного продукта. Сами используем другой, универсальный, поддерживающий наш класс USB устройств( соответственно и firmware другое - реализующее наш протокол). DMA иcпользовали,потом отказались из-за ненужности. Никаких программных задержек не использовали. В данном устройстве используется аппаратная шина микроконтроллера. Ядро USB у Philips (NXP) довольно простое - PDIUSBD11-12, ISPXXXX, LPCXXXX. PDIUSBD12 - устаревшее решение, в новых разработках, кроме бюджетных, не используем.

http://www.slavna.ru/stran/ucc06.htm

В процессе разработок ни разу не понадобился. PS. Хотя для реинжиниринга может быть и нужен. Но (ИМХО) даже для этой задачи удобнее подсунуть собственный драйвер-фильтр.

Что это за конкуренты такие. PDIUSBD12 выпускается уже давно - в инете куча примеров и исходников.