Время отклика USB-устройства.... Опции

[qqqqqq]

Померял время между отправкой одного bulk-пакета и приёмом другого. Получил в среднем 40мс.
Что-то не этого я ожидал от HS USB.
Длина пакетов была 10 байт. Драйвер CYUSB, микросхема CY7C68001, на выходе которой стоит CPLD, разворачивающая приходящий пакет, инвертируя его, в синхронном режиме на скорости 48МГц 8бит.

Как бы сократить это время раз этак в 40тысяч?...
Похоже, где-то я действую неправильно...
В интернете ничего на данную тему найти не смог, кроме упоминаний, что "USB response time is unacceptably slow". Неужели этого и добивались разработчики данной шины?
Даже не верится...

[AndreyS]

Добрый день.


После прочтения топика, хочется вставить свою лепту в истории

Юзаем исключительно EzUSB. Все реализованно на потоках и с использованем внутренних семафоров.
Про запуск сначала вычитки до записи - сущая правда (иначе виснит, про ABORT PIPE помнится на третьй аборт в синий вылетает винда из-за драйвера. Так что лучший аборт для оного устройства - это все же вернуть данные в запрошенный пайп).

Юзать рекомендую только по потокам (иначе подвесите всю систему как два пальца).

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

По поводу EzUSB, натолкнулись на то что дебаговая версия жрет кучу процессорного времени (а оно на вес золота). По сему работаем исключительно с free.

Вообще драйвером я доволен, а чего им быть не довольным - он ПРОСТОЙ. Все в ваших руках. У нас достаточно глубокая обратная связь в системе, по этому о латентности ничего сказать немогу. Единственное что интересно кто как решает проблему передачи?? Мне пришлось завести в железке таймер по которому в тото же пайп кидается спец пакет. Дабы не завесить поток на вычитку. Ну нехотел я заводить второй канал для проверки наличия данных да еще на интеррапт. Да и буфер у нас для сих вещей маловат. А входной поток большой (ну не дикий, но большой для такого буфера и всяких там паралельных задачь).

А какой буфер используют господа?? Ну так чтобы данные не потерялись и при условии то данные на вход Cypress остановить нельзя.

Вот пожалуй и все.

Удачи.

[Седой]

По поводу EzUSB, натолкнулись на то что дебаговая версия жрет кучу процессорного времени (а оно на вес золота). По сему работаем исключительно с free.

Это для всех драйверов так.
EzUsb - отличный пример драйвера c исходниками , тем более есть исходники для DriverStudio.
Использовали при разработке своих.

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

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

Единственное что интересно кто как решает проблему передачи?? Мне пришлось завести в железке таймер по которому в тото же пайп кидается спец пакет. Дабы не завесить поток на вычитку. Ну нехотел я заводить второй канал для проверки наличия данных да еще на интеррапт. Да и буфер у нас для сих вещей маловат. А входной поток большой (ну не дикий, но большой для такого буфера и всяких там паралельных задачь).

Посмотрите в исходнике того же EzUsb (лучше из DriverStudio, в нем нагляднее) на реализацию поллинга Interrupt Ep. Сделайте похожее для считываения во внутренний буфер драйвера для Bulk. Буфер сделайте побольше. А из приложения через DeviceIoControl считывание данных из него (см. исходник serial.sys в том же DDK или DriverStudio). И не будете связываться с потоками. У вас получится постоянно готовый для приема из устройства канал передачи данных. Если есть данные - устройство пишет их в него, нет - пишет пакет нулевой длины.

Сообщение отредактировал Седой - Oct 30 2007, 10:11