CY7C680013A Киньте ссылкой на софт и лит-ру Опции

[-=Vitaly=-]

С Новым Годом!!!
Здравствуйте премногоуважаемые жители форума!!!

Имею сей контроллер не знаю как к нему подступиться чтобы USB начаеть делать. Какой софт юзать??
Смотрел кейл, там вроде этот проц есть. Может есть что специфическое от cypressa??
А для разработки драйвера и софта под виндой че юзать???

СПС!!!

[-=Vitaly=-]

Мне надо 50-60 мб/cек. GPIF работает в режиме SLAVE на 48 мГц 16 бит, смогу ли достичть заданной скорости???

И какую предельную скорость выжимали из этого проца????

[jur]

Мне надо 50-60 мб/cек. GPIF работает в режиме SLAVE на 48 мГц 16 бит, смогу ли достичть заданной скорости???
И какую предельную скорость выжимали из этого проца????

Из этой микросхемы реально выжимается скорость в 96 МБ/сек (см. GPIF Primer). А возможно ли ее достичь? Хм... Смотря в каком приложении, на каком компьютере, под какой операционной системой и насколько длительно. Небольшими порциями (пачками по несколько пакетов), наверное, вполне возможно.

[-=Vitaly=-]

Ладно сделаем посмотрим.
Еще вопрос, в режиме SLAVE пакет готов к передачи по USB, когда я полностью заполнил буфер или дернул PKTEND для короткого пакета???

[jur]

Еще вопрос, в режиме SLAVE пакет готов к передачи по USB, когда я полностью заполнил буфер или дернул PKTEND для короткого пакета???

Пакет уходит в USB, когда он полностью заполнен, т.е. записал 512 байт в ФИФО - пакет ушел (не важно, что ФИФО еще не полностью заполнено). PKTEND нужно дергать только для коротких пакетов, т.е. таких, которые меньше заданного максимального размера пакета (в данном случае 512 байт). По моему так.

Да. Получается 6 мегабаит/сек, но только в одну сторону, а я пишу 6 мегабаит и тут-же считиваю теже 6 мегабаит обратно. Так и получаю 12.

А, теперь понял.

Использую асинхронную передачу, тоесть OutEndpoint->BeginXTransfer; InEndpoint->BeginXTransfer; Wait; Finish. Отдельный тред использовать не пробовал. Сегодня попробую, но боюсь это даст мало ускорения.

Хм... Тогда непонятно... Получается, что необходимо применить точный таймер QueryPerformanceCounter, чтобы выявить узкие места в тракте передачи. Может для начала стоит попробовать просто подсчитывать полученные пакеты, никуда дальше их не передавая? Так можно будет оценить скорость чистой передачи по USB без учета вклада прикладной программы.

P.S. Да, совсем забыл сказать. Насколько я помню, речь идет о передаче всего кадра целиком, всех 256 КБ одним махом? Возможно, проблема кроется именно в этом. Т.е. для Винды, которая никоим образом не ОС РВ, подобные процедуры следует выполнять в виде очереди запросов. Например, у меня запускается четыре запроса по 8 блоков в каждом (можно и побольше блоков взять). Тут ведь нужно помнить, что вызов драйвера - серьезная процедура. Если вызвать считывание 256 КБ, дождаться их прихода и начать что-то делать с полученными данными, то это будет катастрофически расточительное расходование системных ресурсов (времени). Следует нагружать драйвер постоянно. Кстати, именно поэтому совершенно необходимо применять технологию передачи данных в отдельном потоке (треде).

[jur]

(К моему предыдущему посту. Почему-то не получилось в него вставить.)

P.P.S. Еще. Я как-то сразу не обратил внимание. Ведь передача идет "туда" и считывается "обратно", так? В таком случае высокой скорости добиться невозможно (ну, или очень сложными, нестандартными методами). И все это потому, что, опять же, Винда никаким боком не ОС РВ. В случае такой передачи однозначно нужно применять треды. Т.е. нужно выдавать поток исходных кадров и параллельно считывать обратно поток обработанных кадров. Альтернативный вариант - переписывание драйвера с целью придания ему свойств реалтаймовости. Не думаю, что это просто... Да и совсем не нужно при вдумчивом построении своего приложения на основе тредов.