Да, кстати, у меня точно такой же размер видеокартинки, тоже 512 на 512 8-бит. Передача исходных 8-битных данных по USB, конвертация в 32-бит и отображение картинки на экране легко укладывается в ~20-25 msec, т.е. 40-50 FPS. А частота 25 FPS при размере картинки четверть мегабайта дают не 12, а чуть больше 6-ти мегабайт/сек ;-) Это, на самом деле, как-то маловато... Подозреваю, что передача данных производится посредством XferData...

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

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

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

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

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

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

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

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

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

Дело в том, что если использовать оочень большой буфер(5 мегабайт), ничего не меняет. Тоесть скорость падает пропорционально. 3 запроса драйверу в секунду при таком раскладе боюсь большой роли тут не играют. Тут или материнка виновата или я чтото наделал неправильного с прошивкой Сайпреса.

Вот код отправлющий пакеты(выше стоит while(1) handle_fifo_gpif_requests() Посмотрите, может я чего не так делаю. Спасибо.

Насчет скорости данного контроллера... У меня при шине 16 бит и частоте 48 МГц получилось прокачивать ~24МБ/сек (12МБ туда и 12МБ обратно), причем запись в буферы FIFO велась единичными словами, а не пакетами, при пакетной записи скорость естественно возрастет. Дескрипторы - по умолчанию. Драйвера стандартные (CyAPI), размер блока передачи 512кБайт.

PS тут забыл сказать, что передача идет через Bulk Endpoints

Все больше и больше мне становиться интересно какой-же все-таки метод передачи является самым быстрым. И как лучше всего передавать данные по самому USB. Выиграю я в скорости если буду использовать Isochronous endpoints?

Аналогично, интересуюсь тем же вопросом!. Тут еще упоминался метод отдельных тредов. Если можно в 2х словах о нем.

СПС!

С изохронным режимом передачи кроме геморроя ничего больше не обретете, приличную скорость можно выжать и из Bulk. Метод отдельных тредов состоит лишь в том, что прием/передача осуществляется в отдельном потоке по отношению к основной программе, посмотрите пример CyAPI/Examples/Streamer в USB DevStudio.

3 доки с сайта сайпресс о измерении скорости и о результатах этих измерений.

Так нет ничего проще, как взять и посчитать :-) Возьмем тактовую частоту USB 480 MHz и поделим ее на 8 бит. Получается 60 МБайт/сек. Это теоретический предел. Далее заглядываем в "Universal Serial Bus Specification Revision 2.0" стр. 46 и 55 и видим, что теоретический предел и там указан в 60 МБайт/сек. Из этого числа нужно вычесть накладные расходы на протокол (они небольшие) и трудноучитываемые расходы на остальное (хаб, корневой драйвер, драйвер устройства, операционную систему и т.п.). Инженерная прикидка позволяет надеяться в среднем на потолок в 30-40 МБайт/сек. Однако, достичь максимальной скорости, IMHO, не так легко...

Что касается Isochronous endpoints, то, как верно отметил коллега -Al-, кроме геморроя других выигрышей не наблюдается. Потом, не забывайте, Isochronous endpoints не обеспечивают безошибочную передачу данных. Исказился блок при передаче - хрен с ним, играем дальше! В спокойных условиях передачи это, наверное, крайне редкий случай, но условия всякими могут быть...

Ну, это очень просто. Как написать программу для Винды, чтобы она быстро реагировала на приём данных? Ведь виндовая программа просто ждет событий в основном цикле сообщений. Механизм сообщений Винды - штука достаточно небыстрая. Если работать через него, то ничего не успеть. Поэтому вполне логично выделить кусок кода, работающий с быстрым каналом USB, в отдельный поток. В этом случае получается что-то похожее на ОСРВ: поток "засыпает" до получения очередной порции данных из USB, а когда эти данные приходят, то поток получает управление намного скорее, чем обычным образом посредством механизма сообщений. Такая технология позволяет максимально быстро принимать/передавать данные, т.к. системные накладные расходы минимизируются. Кроме того, программировать отдельный тред намного проще :-) Не нужно заморачиваться другими вопросами, можно целиком сосредоточиться на задаче быстрой передачи данных.

Спасибо за интересную информацию! В этих примерах достигается примерная скорость в ~20-24 МБайт/сек. Похоже, что на это примерное значение и следует ориентироваться в своих инженерных прикидках. Т.е. это, по видимому, те значения, которые могут быть сравнительно несложно повторены, достигнуты обычным путем, без очень сложных подходов к решению задачи.

В том и дело, что у меня как раз и получается 20 мб/сек в лучшем случае. Это при том, что чипсет как раз ICH5. Если не затруднит, помогите ускорить мое творение. Выкладываю все исходники включая GPIF проект(используются FIFOrd и FIFOwr, одиночные давно не использовал). Я не могу понять, что у меня неправильно написано.

http://rinat.acm.jhu.edu/all_source.zip

Спасибо.