Привет!

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

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

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

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

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

попробуй добить буфер, думаю CY7C68001 ждет окончания. Или сформируй сигнал "буфер заполнен" в CY7C68001.

Да, я так и делаю, подаю CY7C68001 команду "отправить буфер" (заношу в регистр 0x20 номер FIFO).

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

К моему большому сожалению я еще не научился писать драйвера под это дело. Поэтому разобраться с примерным драйвером от Cypress пока не выходит (тёмно там все...). Вот я и подумал, может быть мои проблемы проистекают от того, что к одному драйверу (CyUSB.sys) обращаются два потока? На стороне персональника у меня все организовано довольно просто. Есть основная программа, она взаимодействует с пользователем и время от времени командует моим устройством при помощи ендпойнты управления. А прием данных происходит в отдельном треде, который работает параллельно и асинхронно с основной программой.

Так может быть драйвер CyUSB.sys не является реентрантным? Точнее, API, через которое я к драйверу обращаюсь. Возможно, меня выручит создание еще одного экземпляра класса API, с помощью которого я смогу работать с каналом управления отдельно?

P.S. Прошу прощения за сумбурность, замучал меня уже этот проблем :-) Пока выкрутился очень просто: для канала управления применил простой последовательный порт :-) Но это, конечно, не дело...

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

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

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

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


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

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

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

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

Вот у меня там 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, думаю, будет тоже самое.

Всем привет!

Прошу меня простить, я на радостях забыл об этой моей теме. Исправляю свою досадную ошибку.

Микросхема CY7C68001 - рулез фарева! :-) Все в ней прекрасно работает, данные превосходно передаются по параллельным ендпойнтам и никаких проблем на самом деле нет. После длительных и трудных ковыряний в интерфейсе с этой микросхемой со стороны ПЛИС, выяснилась банальнейшая фигня! В автомате одновременного доступа к микросхеме (когда по одной ендпойнте валит поток данных, а по второй микроконтроллер изредка передает байтик/другой) содержалась ошибка, из-за которой иногда возникало небольшое сужение импульса записи (SLWR). Вместо положеных 80 ns, выдавалось 40 ns (при минимуме для асинхронного режима 70 ns). После исправления автомата все заработало как часы :-) И на компьютерной стороне все превосходно, никаких пауз не возникает, многократные передачи управляющих блоков туда/сюда идут быстро, без ожидания очередного кванта Винды.

Спасибо вам всем за ответы!

P.S. Теперь считаю себя готовым к освоению CY7C68013A :-) Она дороже на 60% (та, что на 128 ног), но зато содержит внутри микроконтроллер.