А если из двух ендпойнтов одновременно принимать?, Одна - High Speed, вторая - можно Full Speed Опции

[jur]

Привет!

Соорудил я устройство на CY7C68001. В составе имеется микросхема USB CY7C68001, простенький управляющий микроконтроллер и ПЛИС. Это устройство по одной односторонней ендпойнте гонит поток данных в компьютер на High Speed, на скорости (в пике) 12.5 MHz. По другой вдухсторонней ендпойнте я хотел изредка передавать управляющие команды (изменить режим, изменить интенсивность и т.п.). Получилось, что вторая ендпойнта всегда получает нормальную команду от PC, но когда она отвечает, что мол "Все прекрасно, интенсивность изменена!", ее ответ теряется на очень продолжительное время. Для иллюстрации приведу ситуацию "в лицах":

1. Компьютер передает команду изменить интенсивность и ждет подтверждения.
2. Подтверждения нет в течении нескольких сотен миллисекунд.
3. Компьютер не понимает молчания и передает команду повторно.
4. Подтверждения нет в течении нескольких сотен миллисекунд.
...

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

Система: Win XP, драйвер CyUSB.sys из их Девелопер Студии.

В чем могут быть грабли?

[lehho]

Скажите, а есть ли такая необходимость подтверждать приём команды? Режим BULK гарантирует доставку пакета по назначению. Не очень понятно зачем нужно подтверждение от контроллера. Или Вам нужно обязательно убедиться, что контроллер выгреб данные из FIFO? Он, что может по каким-то причинам это не сделать?

[jur]

Скажите, а есть ли такая необходимость подтверждать приём команды? Режим BULK гарантирует доставку пакета по назначению. Не очень понятно зачем нужно подтверждение от контроллера.

Мысль очень верная! Я тоже начал склоняться к варианту без получения подтверждения. Просто у меня уже очень давно используется простой протокол для такого взаимодействия приборов с компьютером по RS-232C (он сделан с подтверждением). Вот я его с небольшими упрощениями и применил :-)

Однако, такое решение = сдаться без боя :-) Хотелось бы еще повоевать... Но если все-таки не получится - откажусь от подтверждения и, надеюсь, все будет нормально работать.

Похоже CY7C68001 или CyUSB.sys пресует твои данные в один фрейм,

Вообще-то очень на это похоже... Причем, не CY7C68001, а именно CyUSB.sys, т.к. я проверил, в CY7C68001 помещается только два ответа (в ендпойнте двойной FIFO). Но как это дело побороть - ума не приложу, т.к. CyUSB.sys - черный ящик...

попробуй 8 раз передать одно и тоже или уменьши скорость приема данных по High Speed или засинхронизируй программы в ХР. Но у BULK нет точной задержки по времени.

Еще попробую, как ты говоришь, засинхронизировать программы, точнее, обработку обеих каналов передачи скомбинирую в одной функции. Черт его знает, может этот класс API к CyUSB.sys на самом деле нереентрантный?...

[al333]

Причем, не CY7C68001, а именно CyUSB.sys, т.к. я проверил, в CY7C68001 помещается только два ответа (в ендпойнте двойной FIFO). Но как это дело побороть - ума не приложу, т.к. CyUSB.sys - черный ящик...

Можно еще попробовать в Endpoint Descriptor bInterval(7-й байт) установить в 0 для bulk

[jur]

Можно еще попробовать в Endpoint Descriptor bInterval(7-й байт) установить в 0 для bulk

Вот что написано в Universal Serial Bus Specification Revision 1.1:

This field is ignored for bulk and control endpoints. For isochronous endpoints this field must be set to 1. For interrupt endpoints, this field may range from 1 to 255.

Вот у меня там 0 и прописан.

А может быть стоит обозвать эту Endpoint как Interrupt и задать это поле равным каким-нибудь 5-10 msec? Для Interrupt Endpoint время обслуживания более/менее гарантируется. Даже минимальный размер передаваемого блока (8, 64 и 1024 для low-speed, full-speed и high-speed соответственно) меня вполне устраивает. Только я с такими ендпойнтами еще не работал, нет ли у них каких-нибудь подводных камней? Если я правильно понимаю, то Interrupt Endpoint - примерно то же самое, что и Bulk Endpoint, только время опроса гарантировано, верно?

[al333]

Вот что написано в Universal Serial Bus Specification Revision 1.1:

This field is ignored for bulk and control endpoints. For isochronous endpoints this field must be set to 1. For interrupt endpoints, this field may range from 1 to 255.

Вот у меня там 0 и прописан.

А может быть стоит обозвать эту Endpoint как Interrupt и задать это поле равным каким-нибудь 5-10 msec? Для Interrupt Endpoint время обслуживания более/менее гарантируется. Даже минимальный размер передаваемого блока (8, 64 и 1024 для low-speed, full-speed и high-speed соответственно) меня вполне устраивает. Только я с такими ендпойнтами еще не работал, нет ли у них каких-нибудь подводных камней? Если я правильно понимаю, то Interrupt Endpoint - примерно то же самое, что и Bulk Endpoint, только время опроса гарантировано, верно?

В "Universal Serial Bus Specification Revision 2.0 bInterval = 0 используется для high-speed bulk.

А для Interrupt, думаю, будет тоже самое.