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

[-=Vitaly=-]

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

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

СПС!!!

[aaarrr]

Для начала стоит посмотреть софт от developer kit'а, там как раз Keil и используется в качестве компилятора, есть примеры.
Простой поиск на сайте Cypress'а CY7C68013A (только с правильным количеством нулей) дает кучу ссылок.

[rvk]

Для того, чтобы полностью врубиться в USB стандарт, а также
написать программу под этот чип в Keil и спроектировать схему
нужен всего один документ : FX2 TechRefManual.pdf, он лежит
в разделе доков для данного чипа на сайте Cypress.
По поводу драйвера :
Можно воспользоваться уже готовым драйвером с исходниками EZUSB.sys, к нему же в ките, который лежит там же, в разделе SDK для чипа на сайте cypress, есть программа под винду, которая работает в паре с драйвером, тоже с исходниками.
Если не нравится EZUSB, он слегка тормознутый, можно использовать
драйвер CyUSB.sys, тоже есть с исходниками.
Правда верхняя программа под него, классная кстати идет уже без сорцов.
Можно воспользоваться уловкой виндов и использовать свое устройство как MASS STORAGE DEVICE, что значит, чип обзывает себя накопителем, как это делается смотреть на сайте usb.org,
ссылки в это форуме есть. Тогда драйвер не нужен в принципе,
используется готовый по умолчанию в виндах.
Ну а если очень хочется можно написать свой с нуля с помощью WIN XP DDK.
Ну и конечно понадобится собственно USB2.0 спецификация, там же на usb.org.

Сообщение отредактировал rvk - Jan 2 2007, 14:31

[-=Vitaly=-]

Спасибо, я где-то так и делал. Просто для подстраховки, чтобы не забыть чего-то!!!

[jur]

можно использовать драйвер CyUSB.sys, тоже есть с исходниками.

Я использую этот драйвер. Отлично работает! Хотел поинтересоваться, а где его исходники найти? А то в китах все больше EZUSB.sys приводится.

[rvk]

Да извините прогнал я по поводу CyUSB, исходников нет, есть
только API файл с заголовком и библиотекой для использования
в программе верхнего уровня.

Сообщение отредактировал rvk - Jan 2 2007, 19:20

[XShocK]

FX2_TechRefManual.pdf + GPIF_Primer.pdf рулят. Только в последнем они постоянно что-то недоговаривают. Во всяком случае мне все время так кажется.

А я вот просидел 3 дня, прикрутил его родимого к Spartan 3, пакеты летают по GPIF как ласточки. Но вот на комп(возможно и на сам спартан тоже) отдельные пакетики в 512 байт прилетают как попало. Было-бы очень интересно как правильно решать такую проблему.

[jur]

Да извините прогнал я по поводу CyUSB, исходников нет

Ну вот... А я уже губки раскатал... :-)

FX2_TechRefManual.pdf + GPIF_Primer.pdf рулят. Только в последнем они постоянно что-то недоговаривают. Во всяком случае мне все время так кажется.

Есть такая буква... Но вообще-то этот Primer - хороший материал. Он даже в основу хелпа GPIF Designer'а лёг. Правда, я не смог с их дурацкого сайта (ох, прошелся бы я серпом по избранным местам их web-дезайнера!) скачать исходники: нажимаю линк - ничего не скачивается (скачал только сам PDF с описанием). Пришлось обращаться в техподдержку, они мне приаттачили ZIP-архив с этими исходниками.

А я вот просидел 3 дня, прикрутил его родимого к Spartan 3, пакеты летают по GPIF как ласточки. Но вот на комп (возможно и на сам спартан тоже) отдельные пакетики в 512 байт прилетают как попало. Было-бы очень интересно как правильно решать такую проблему.

Не знаю, что используется на компьютерной стороне, но я пользуюсь CyAPI к их превосходному CyUSB.sys. У меня была похожая проблема, пакеты хаотически не приходили. Понятное дело, грешил на их драйвер. Но зря. Оказалось, что в моем железе была трудноуловимая ошибка, импульс SLWR изредка был короче, чем нужно (речь о CY7C68001). Поэтому мне думается, что если работа идет через CyAPI, то желательно очень внимательно проверить железо. В Спартане что-нибудь отладочное намутить, хотя бы пакеты подсчитывать. Т.к. их CyAPI работает очень хорошо, я на него грешил бы в последнюю очередь.

[XShocK]

Не знаю, что используется на компьютерной стороне, но я пользуюсь CyAPI к их превосходному CyUSB.sys. У меня была похожая проблема, пакеты хаотически не приходили. Понятное дело, грешил на их драйвер. Но зря. Оказалось, что в моем железе была трудноуловимая ошибка, импульс SLWR изредка был короче, чем нужно (речь о CY7C68001). Поэтому мне думается, что если работа идет через CyAPI, то желательно очень внимательно проверить железо. В Спартане что-нибудь отладочное намутить, хотя бы пакеты подсчитывать. Т.к. их CyAPI работает очень хорошо, я на него грешил бы в последнюю очередь.

Я наверно выразился немного смутно. Все пакеты приходят, и насколько я понял без ошибок. Проблема в том, что эти самые пакеты приходят не в правильном порядке. Если отправление делать медленно, то все путем. Стоит начать отправлять без задержки, так начинаются проблемы. На компе запущен CyBulk(та, что идет в пакете sdk) который и проверяет целостность. Насколько я понимаю USB в Bulk режиме не дает гарантии когда пакет придет, но я так и не понял, что насчет гарантии очередности пакетов. Если ее нет то посоветуйте, как правильно и быстро(что важно) это можно решить.

[XShocK]

Мой вопрос отпадает. Написал свою прогу на CyAPI и все начало работать. Видать этот CyBulk как-то странно считывает данные.
Теперь правда беда, скорость с CyAPI ник черту. Видео 512 на 512 8-бит идет всего 25 фпс, это примерно 12 мегабайт/сек. А хочется 35 мб/сек.

[grumbler]

Мой вопрос отпадает. Написал свою прогу на CyAPI и все начало работать. Видать этот CyBulk как-то странно считывает данные.
Теперь правда беда, скорость с CyAPI ник черту. Видео 512 на 512 8-бит идет всего 25 фпс, это примерно 12 мегабайт/сек. А хочется 35 мб/сек.

Забить на CyAPI - перейти на USBIO и всё получится. А как провереяте скорость ? Переполнение буферов ?

[XShocK]

Забить на CyAPI - перейти на USBIO и всё получится. А как провереяте скорость ? Переполнение буферов ?

Программа посылает Спартану картинку, тот ее по простому инвертирует и отсылает назад, на моем конце я гляжу частоту с которой я принимаю кадры. Судя по этому и расчитал, что примерно 12 метров.
Насчет переполнения буферов. Судя по мигающему на борде светодиоду ПЛИС справляется со своим делом очень быстро. Почти все время стоит в ожидании. Я поставил на вход и на выход по 2кб фифо, так что и ПЛИС микроконтроллер помоему не стоят.
Еще я попробовал убрать весь код какой можно было из главного цикла. Скорость поднялась с 25 до 27 кадров с сек.
Так что последую вашему совету и попробую USBIO.

[grumbler]

Программа посылает Спартану картинку, тот ее по простому инвертирует и отсылает назад, на моем конце я гляжу частоту с которой я принимаю кадры. Судя по этому и расчитал, что примерно 12 метров.
Насчет переполнения буферов. Судя по мигающему на борде светодиоду ПЛИС справляется со своим делом очень быстро. Почти все время стоит в ожидании. Я поставил на вход и на выход по 2кб фифо, так что и ПЛИС микроконтроллер помоему не стоят.

А какого размера буфер софтовый передается драйверу ? Размером на кадр или маленький ?
Еще я попробовал убрать весь код какой можно было из главного цикла. Скорость поднялась с 25 до 27 кадров с сек.
Какая машина используется ?
Так что последую вашему совету и попробую USBIO.
У нас когда то давно получилось на ввод получить примерно 27Мб, больше не было потребности.

[XShocK]

А какого размера буфер софтовый передается драйверу ? Размером на кадр или маленький ?

Размер буфера на весь кадр, тоесть примерно 260 кбайт.

Какая машина используется ?

Pentium 4 3.06ghz, 533 mhz bus. Мать с 865 чипсетом.

Только что попробовал USBIO Demo application и его
Read File to Pipe и второй с Write Pipe to File. Тоесть
пишу в EP2OUT и читаю из EP6IN.
При запуске оба показывают стабильно 8.9 мегабайт/с. Тоесть
примерно 18 мбайт/с так как трафик идет в обе стороны.
Уже не 12 как в CyAPI, но и не желаемые 30-35.

[jur]

Забить на CyAPI - перейти на USBIO и всё получится.

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

Что касается CyAPI, то нужно помнить, что для скоростного обмена данными следует использовать асинхронный ввод/вывод через связку BeginDataXfer->WaitForXfer->FinishDataXfer, а не простой XferData. Также следует учесть буферирование. Например, для своих скоростей передачи (до 8 МБ) я опытным путем выяснил, что достаточная скорость достигается при очереди из 4 запросов по 8 512-байтных блоков в каждом (увеличение до 16-ти или 32-х увеличивает общую скорость передачи, но уже не намного). Далее. Передача данных должна обязательно производиться в отдельном треде, для которого нужно выставить повышенный приоритет (я выставляю THREAD_PRIORITY_TIME_CRITICAL).

Ну и, наконец, достижение скоростей передачи в 30-35 МБ/сек - далеко не тривиальная задача! Достаточно взглянуть на скорость передачи данных с одного винчестера на другой. У меня скорость такой передачи на дисках EIDE даже 30 МБ не достигает! А ведь эта процедура выполняется системными средствами, хорошо вылизанными и отлаженными системными драйверами! Получить скорость более 35 МБ удается только с дисками SATA. Поэтому мне думается, что задача достижения скорости передачи в 30-35 МБ/сек должна решаться комплексно, с учетом не только драйверного хозяйства, но и приложения, использующего эти данные. Кстати, очень полезно провести хронометраж с помощью точного таймера (того, который QueryPerformanceCounter), это может помочь выявить узкие места.

[jur]

Теперь правда беда, скорость с CyAPI ни к черту. Видео 512 на 512 8-бит идет всего 25 фпс, это примерно 12 мегабайт/сек. А хочется 35 мб/сек.

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

[-=Vitaly=-]

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

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

[jur]

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

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

[-=Vitaly=-]

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

[XShocK]

Теперь правда беда, скорость с CyAPI ни к черту. Видео 512 на 512 8-бит идет всего 25 фпс, это примерно 12 мегабайт/сек. А хочется 35 мб/сек.

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

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

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

[XShocK]

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

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

Код

void handle_fifo_gpif_requests() {
  // Handle OUT EP2 host request
  if( GPIFTRIG & 0x80 )  // if GPIF interface IDLE
  {  
    // if there's a packet in the peripheral domain for EP2
    if ( ! ( EP24FIFOFLGS & 0x02 ) )
    {
      if( !is_external_fifo_full() ) {
        Setup_FLOWSTATE_Write(); // setup FLOWSTATE registers for FIFO Write operation
    SYNCDELAY;

REPEAT_WRITE:
    SYNCDELAY;
        GPIFTCB1 = 0x01; //(packet_size / 2) >> 8; // upper nibble of number of bytes / 2-byte wide bus
        SYNCDELAY;
        GPIFTCB0 = 0x00; //(packet_size / 2) & 0xFF; // lower nibble
        SYNCDELAY;
        GPIFTRIG = GPIF_EP2;            // launch GPIF FIFO WRITE Transaction from EP2 FIFO
    SYNCDELAY;

        while( !( GPIFTRIG & 0x80 ) ) // poll GPIFTRIG.7 GPIF Done bit
        {
        ;
        }

        if ( ! ( EP24FIFOFLGS & 0x02 ) && !is_external_fifo_full() )
        goto REPEAT_WRITE;
      }
    }
  }

  // Handle IN EP6 host request
  if ( GPIFTRIG & 0x80 )  // if GPIF interface IDLE
  {
    if ( !is_external_fifo_empty() )  // if external FIFO is not empty
    {
      if ( !( EP68FIFOFLGS & 0x01 ) ) // if EP6 FIFO is not full
      {      
        Setup_FLOWSTATE_Read(); // setup FLOWSTATE registers for FIFO Read operation    
        SYNCDELAY;

REPEAT_READ:
    SYNCDELAY;
        GPIFTCB1 = 0x01;  // setup transaction count (512 bytes/2 for word wide -> 0x0100)
        SYNCDELAY;
        GPIFTCB0 = 0x00;
        SYNCDELAY;

        //*transaction_count_in += 1;
        GPIFTRIG = GPIFTRIGRD | GPIF_EP6; // launch GPIF FIFO READ Transaction to EP6 FIFO
        SYNCDELAY;

        while( !( GPIFTRIG & 0x80 ) ) // poll GPIFTRIG.7 GPIF Done bit
        {
        ;
        }

    if ( !is_external_fifo_empty() && !( EP68FIFOFLGS & 0x01 ) )
        goto REPEAT_READ;
      }
    }
  }
}

[-Al-]

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

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

[XShocK]

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

[-=Vitaly=-]

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

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

СПС!

[-Al-]

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

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

СПС!

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

[Gate]

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

Прикрепленные файлы

 measuring_delivered_usb_2_0_bandwidth_with_an_ez_usb_fx2_development_board_9.pdf ( 192.25 килобайт ) Кол-во скачиваний: 1879
 streaming_data_through_isochronous_bulk_endpoints_on_ez_usb_fx2__9.pdf ( 125.12 килобайт ) Кол-во скачиваний: 240
 streaming_over_usb_with_isochronous_and_bulk_transfers_16.pdf ( 250.61 килобайт ) Кол-во скачиваний: 3780

 

[jur]

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

Аналогично, интересуюсь тем же вопросом!

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

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

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

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

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

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

[XShocK]

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

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

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

Спасибо.

[jur]

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

Хм... На первый взгляд, вроде, все верно. Только я обратил бы внимание на функцию

DWORD WINAPI thread_usb_loop (void *data)

Мне представляется, что в ней блок вызовов

usb_begin_out_transfer(s_tex_orig, TEXTURE_WIDTH * TEXTURE_HEIGHT);
usb_begin_in_transfer(s_tex_processed, TEXTURE_WIDTH * TEXTURE_HEIGHT);
usb_wait_out_transfer_finish();
usb_wait_in_transfer_finish();

не совсем рационально использует CPU. Например, после выполнения операции OUT получается непроизводительная трата времени на ожидание операции IN. Наверное, стоило бы взглянуть на пример Streamer из Cypress'овской USB DevStudio. В этом примере рассматривается очень рациональный метод потокового выполнения заданий. Т.е. запускается сразу несколько операций считывания (в этом примере производится считывание данных в компьютер). В твоем примере, видимо, стоит сделать точно так же, но усложнить алгоритм, добавив в него еще и вывод кадров. Может быть, стоило бы сделать отдельные треды для вывода кадров и для их последующего ввода. Тогда степень распараллеливания может быть максимальной. Глубина очереди, IMHO, может быть на уровне примерно 4-х операций (т.е. число элементов в очереди операций). Также следует помнить о синхронизации вывода кадров и их последующего ввода в компьютер. Думаю, что тут можно применить что-то простенькое, типа счетчика, изменяемого в закрытой секции каждым потоком (тредом).

Ну и, наконец, думаю, что стоило бы поиграться величиной порций видео-данных, передаваемых туда и обратно. Может быть можно получить выигрыш в скорости за счет более плавной загрузки канала передачи, если передавать не весь кадр целиком, а разбить его на кусочки по 8-16-32 КБайт. Объяснить не могу, но закрадывается чувство, что работа драйвера с большими порциями данных на одну операцию может вызвать дополнительные накладные расходы. Впрочем, в этом вопросе я не силен, возможно этот мой взгляд ошибочен.

Кроме того, думаю, стоило бы прикинуть время выполнения операций, т.е. в треде вывода считать период выдачи кадров, а в треде ввода, соответственно, их считывания. Для чистоты эксперимента и получения наиболее точных значений производительности, стоило бы временно выключить операции OpenGL, чтобы получить чистые цифры самой передачи по USB. Для подсчета времени следует использовать максимально точный в Винде таймер QueryPerformanceCounter. Например я делаю так: накапливаю в сумматоре показания QueryPerformanceCounter и запоминаю число полученных пакетов, а затем раз в секунду (в основной виндовой программе) делю одно на другое, перевожу в секунды и вывожу на индикацию. Причем, тут следовало бы накапливать целый ряд сумматоров: период вывода, время очередного вывода, период ввода, время очередного ввода, и, может быть, еще какие-нибудь ключевые моменты алгоритма передачи данных.

[Warlord]

Мне удалось достичь скорости 33МБайт\с на Bulk In на драйвере ezusb.sys, думаю можно поднять еще немного, переписав функцию драйвера приемопередачи. И поднять еще немного, увеличив скорость заполнения фифо (щас у меня примерно 36Мгц) до штатных 48Мгц. У меня другая проблема, хочу сказать драйверу (один раз), получи-ка асинхронно эти 33МБ вот в этот буфер, а когда получишь, дерни рабочий поток, чтоб обработал. Так вот беда в том, что пока драйвер будет получать эти 33МБ (примерно сек) ОС замрет на это время, а это не есть гуд...

[jur]

Мне удалось достичь скорости 33МБайт\с на Bulk In на драйвере ezusb.sys, думаю можно поднять еще немного, переписав функцию драйвера приемопередачи.

Здорово! А ты взял стандартный драйвер ezusb.sys, или "доработал его напильником"? Интересно, как он в сравнении с CyUsb.sys? А что нужно переписать в функции приемопередачи драйвера? (Я с драйверами еще не ковырялся, они мне представляются этакими страшными, таинственными и очень сложными монстрами :-) )

У меня другая проблема, хочу сказать драйверу (один раз), получи-ка асинхронно эти 33МБ вот в этот буфер, а когда получишь, дерни рабочий поток, чтоб обработал. Так вот беда в том, что пока драйвер будет получать эти 33МБ (примерно сек) ОС замрет на это время, а это не есть гуд...

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

[Warlord]

2jur
Я взял стандарнтый ezusb.sys. Про CyUsb.sys не знаю, не пробовал, но думаю что выигрыша уже не будет. Так как исходников его нету, а я его ставил как-то раз, то могу предположить, что код, ответственный за приемопередачу, врядли короче и чище чем у ezusb.sys. Поверхностно они отличаются способом создания устройства. ezusb.sys создает устройство "EZUSB-0" а CyUsb.sys действует через GUID.
Много доработать не получится, так как там все просто и "лишних" вызовов на чем можно съэкономить почти нет. Доработка заключается в увеличении входного буфера, в оригинале драйвер принимает не больше 2^16 байт за раз, но у меня максимальная скорость была при 2^15. Так вот, чтобы получить 33Мега надо 1024 раза вызвать драйвер с буфером 2^15. А это "лишние" накладные расходы. Да и прога будет заниматься только тем что вызывать драйвер и ждать пока придет очередная порция, а обрабатывать будет некогда. Вот тогда и родился вариант отдать драйверу весь буфер 33МБ, и когда он заполнится, взведется событие, по которому аппилуха обработает данные.

Сообщение отредактировал Warlord - Jan 16 2007, 10:02

[jur]

Доработка заключается в увеличении входного буфера, в оригинале драйвер принимает не больше 2^16 байт за раз, но у меня максимальная скорость была при 2^15.

Большое спасибо за разъяснение!

Так вот, чтобы получить 33Мега надо 1024 раза вызвать драйвер с буфером 2^15. А это "лишние" накладные расходы. Да и прога будет заниматься только тем что вызывать драйвер и ждать пока придет очередная порция, а обрабатывать будет некогда. Вот тогда и родился вариант отдать драйверу весь буфер 33МБ, и когда он заполнится, взведется событие, по которому аппилуха обработает данные.

Хм... Снова на ум приходит все тот же пример Streamer из Cypress'овской USB DevStudio. Взгляни, там очередь заданий запускается вот таким образом:

// Queue-up the first batch of transfer requests
for (i=0; i< QueueSize; i++) contexts[i] = dlg->InEndPt->BeginDataXfer(buffers[i], len, &inOvLap[i]);

Из этого примера видно, что происходит выполнение следующего приема данных параллельно с их обработкой в прикладной программе, т.е. получили данные из первого запроса (и снова перезапустили, чтобы очередь была постоянно заполненна) и можем их обрабатывать, а драйвер тем временем качает дальше. Я пробовал поиграться параметрами такого запуска на слабенькой embedded-материнке (VIA EPIA SP, PIII 1.3 GHz, 17 x 17 cm) и получил хорошие показатели сбалансированности нагрузки при 4-х запросах в очереди и 8 блоках в каждом запросе (т.е. порция данных 4 КБ). Может быть и в твоем случае можно применить похожий механизм? Тогда не нужно будет организовывать такой большой буфер в драйвере. Ведь в этом случае получится хорошее распараллеливание процесса: драйвер порции данных качает, а приложение их обрабатывает по мере поступления. Хотя я на таких больших скоростях не работал, возможно мои рассуждения ошибочны.

[Warlord]

Да, щас сам глянул CyUSB.sys и увидел, что этот драйверок намного навороченнее чем ezusb.sys. Там и потоки запускаются, и события сбрасываются\устанавливаются и еще много чего интересного делается. А потом я глянул Streamer и похоже что так оно и есть, порциями работа, щас гляну поподробнее как это функционирует. Очень даже может быть это и есть, то чего исчу

[nicom]

Мне удалось достичь скорости 33МБайт\с ...думаю можно поднять еще немного, переписав функцию драйвера приемопередачи.... И поднять еще немного, увеличив скорость заполнения фифо ...

...прошу прощения, что встрял в обсуждение...

А на какую максимальную скорость можно расчитывать для случая непрерывного потока данных в одну сторону (из устройства в компьютер)?
т.е. достиг ли кто нибудь скорости в 40МБайт в сек в случае передачи данных в течении, например, 1часа (144Гбайта) абсолютно без потерь данных?...
это про ХХ68013..., хотя, и не обязятельно...

[jur]

А на какую максимальную скорость можно расчитывать для случая непрерывного потока данных в одну сторону (из устройства в компьютер)?

IMHO, очень много от чего зависит. От железа, драйверов, прикладной программы, операционки, наконец. Судя по опыту коллеги Warlord, похоже, что скорость в 40 МБайт/сек достижима (хотя это и нелегко).

т.е. достиг ли кто нибудь скорости в 40МБайт в сек в случае передачи данных в течении, например, 1часа (144Гбайта) абсолютно без потерь данных?...

Без потерь данных - лёгко :-) Bulk endpoint обеспечивает безошибочную передачу. (Правда, в условиях сильных помех, при наличии ошибок передачи, упадет скорость, т.к. "булки" обеспечивают гарантированную доставку данных, но при этом идут перезапросы, т.е. не гарантируется траффик.)

Интересно, также, как работают Interrupt endpoints? Они ведь тоже гарантируют доставку, но еще и позволяют задавать время опроса. Т.е. и без ошибок и быстро. (?)

2 All. Просветите, пожалуйста, кто знает, чем хороши/плохи Interrupt endpoints? Может быть эти каналы позволяют сочетать скорость и надежность? (Согласно спецификации USB 2.0 скорость Interrupt endpoints такая же, как и Bulk endpoints, хотя это и напоминает бесплатный сыр...)

А количество данных... Если данные не нужно запоминать (вроде видеостриминга какого-нибудь), то передавай хоть терабайты :-) И ни один байт никуда не денется, если по Bulk или Interrupt...

[nicom]

... похоже, что скорость в 40 МБайт/сек достижима (хотя это и нелегко).

Теоретически... - это понятно...
Вопрос в практической реализации...

2 ALL... похвастайтесь...

[Warlord]

Вчера примерялся к драйверку CyUSB.sys а сегодня утром получил свежие данные касательно скорости. Драйверок-то действительно побыстрее ezusb.sys будет Мне удалось принять от железки 37МБ за 1000мс, т.е. за секунду. Это на 4МБ больше нежели с ezusb.sys. Причем прием асинхронный, что особенно радостно, огромное спасибо jur за инфу о Streamer. Об Interrupt Endpoints знаю немного, знаю что используются если устройство принадлежит к HID-классу, тогда родной драйверок виндофс САМ будет опрашивать и забирать данные с Endpoint-а, а аппликухе остается только забрать их у драйвера. Смущает только одно: параметр bInterval если он =1 то опрос проводится драйвером каждую 1мс даже при HI-speed. А это не есть гуд, поскольку очень редко, если размер Endpoint 1024 то терия дает всего 1МБ.. Возможно я заблуждаюсь и буду рад, если знающий поправит

[jur]

Вчера примерялся к драйверку CyUSB.sys а сегодня утром получил свежие данные касательно скорости. Драйверок-то действительно побыстрее ezusb.sys будет

Мне он тоже как-то сразу понравился :-) Правда, повлияло еще и то, что в ходе общения со службой техподдержки Cypress'а они мне объяснили, что ezusb.sys хорош для обучения и как основа для разработки своего драйвера. А CyUsb.sys - это коммерческое изделие, годящееся для серийной продукции. Т.к. у меня нет опыта разработки драйверов под Винду, а драйвер CyUsb.sys авторы разрешают использовать совершенно бесплатно, то я на него и "запал". А уж когда я убедился, что по сравнению с драйверами от FTDI этот драйвер отличается еще и превосходной стабильностью, то мой выбор сузился до единственного варианта :-)

... огромное спасибо jur за инфу о Streamer.

Всегда пожалуйста! Мы ведь тут именно для этого и обитаем, для общения и взаимопомощи :-)

Смущает только одно: параметр bInterval если он =1 то опрос проводится драйвером каждую 1мс даже при HI-speed. А это не есть гуд, поскольку очень редко, если размер Endpoint 1024 то терия дает всего 1МБ.

Нет, это не так. Вот что сказано в разделе "5.7.4 Interrupt Transfer Bus Access Constraints" спецификации шины USB 2.0 (стр. 51):

High-speed endpoints can specify a desired period (2^bInterval-1)x125 µs, where bInterval is in the range 1 to (including) 16. The USB System Software will use this information during configuration to determine a period that can be sustained. The period provided by the system may be shorter than that desired by the device up to the shortest period defined by the USB (125 µs microframe or 1 ms frame).

Кроме того, в таблице 5-8 (на той же стр. 51) указаны цифры максимальных скоростей, которые такие же, как и для "булки".

Я так понял, что для High-speed ендпойнты период опроса может быть вплоть до 125 мксек. Кроме того, за один микрофрейм можно передавать еще и несколько пакетов (до трех штук вроде). В общем, интересная вещь, эти interrupt endpoints. Жаль, что пока очень непонятная...

P.S. У меня появилась одна мысль. Может быть ты можешь провести опыт? Попробуй, пожалуйста, сменить конфигурацию своей endpoint'ы с Bulk на Interrupt (с bInterval = 1) и запустить высокоскоростную передачу. Очень интересно было бы сравнить эти два канала. Какова максимальная скорость передачи? Насколько сильно при этом нагружается процессор? Чем вообще похожи/отличаются эти два вида ендпойнтов?

[Warlord]

Провел я опыт, результаты - 37МБ за 9.4сек, т.е. почти в 10 раз медлененнее. Загрузка проца 10-8-7-5-4-10-0 (P4-2800). Все параметры перепроверил EP bAttributes 0x03 bInterval=0x01, все как надо, девайс говорит - HiSpeed, использую CCyInterruptEndPoint, все как доктор прописал, но увы, что-то не срастается...

[jur]

Провел я опыт, результаты - 37МБ за 9.4сек, т.е. почти в 10 раз медлененнее. Загрузка проца 10-8-7-5-4-10-0 (P4-2800).

Большое тебе спасибо за информацию! Очень интересно! Теперь видно, что Bulk и Interrupt ендпойнты чем-то отличаются. Причем, судя по результатам твоего опыта, отличаются существенно. Однако, при чтении спецификации на USB 2.0 это различие как-то не бросается в глаза... Черт... Придется углубиться в вопрос...

[Warlord]

Тут главное понять для чего вообще нужен это тип EP, немного странно, что у Cypress нет ни одного примера с использованием такого EP. Единственное применение, которое я нашел и реализовал - это HID устройство, виндовый драйвер которого HIDUsb.sys сам опрашивает железяку, а мне оставалось только забирать данные через ReadFile.

[jur]

Привет!

Провел некоторые эксперименты (P4, 3.06 GHz). Я сделал модификацию фирмваре FX2 так, чтобы она постоянно передавала блок данных (там просто мусор, сами данные неважны, передается просто 512 байт). А на компьютерной стороне я применил пример Streamer, который обращается к драйверу, получает данные и ничего с ними не делает, просто считает скорость передачи. Пробовал на двух одинаковых компьютерах. На первом установлена память DDR333. Скорость передачи была порядка 37.5 МБайт/сек. Точно такая же, какую получил в своих опытах коллега Warlord. А на втором установлена память DDR400. При этом скорость передачи возросла почти до 40 тысяч МБайт/сек. Вот скриншоты со второго компьютера:



Потом я еще увеличил число пакетов и длину очереди, скорость еще чуток возросла, но ненамного.

Однако, выплыл ньюанс, гробящий на корню мою быструю передачу. После примерно полутора минут передачи скорость падает больше чем на порядок и дальше болтается у этой очень небольшой величины. Что бы это могло значить? Вот поясняющие скриншоты:



Также я заметил, что при запуске приложения появляется тонкий свист из компьютерного блока, похожий на свист импульсного источника питания при существенном возрастании нагрузки. Особенно громкий свист был при условиях, показанных на самом первом скриншоте.

Предварительный (еще очень ранний) вывод: скорость под 40 МБайт/сек простыми методами недостижима. Коллеги, очень прошу, поделитесь, не сталкивались ли вы с подобными эффектами? Особенно настораживает падение скорости передачи после полутора минут (!) после начала передачи.

Coming soon. Сейчас готовлюсь пойти по стопам коллеги Warlord в направлении Interrupt endpoints :-)

[-Al-]

Потом я еще увеличил число пакетов и длину очереди, скорость еще чуток возросла, но ненамного.

Однако, выплыл ньюанс, гробящий на корню мою быструю передачу. После примерно полутора минут передачи скорость падает больше чем на порядок и дальше болтается у этой очень небольшой величины. Что бы это могло значить? Вот поясняющие скриншоты:
....
Особенно настораживает падение скорости передачи после полутора минут (!) после начала передачи.

Не обращайте на падение скорости внимания, это ошибка программы. Такое происходит потому, что расчет скорости ведется по формуле <суммарное переданное число байт>/<время передачи>. Просто суммарное переданное число байт быстро выходит за пределы unsigned long (32бита, 4ГБ), ну и соответсвенно, отсчет опять начинается с нуля, а время продолжает тикать как обычно

[jur]

Не обращайте на падение скорости внимания, это ошибка программы. Такое происходит потому, что расчет скорости ведется по формуле <суммарное переданное число байт>/<время передачи>. Просто суммарное переданное число байт быстро выходит за пределы unsigned long (32бита, 4ГБ), ну и соответсвенно, отсчет опять начинается с нуля, а время продолжает тикать как обычно

Огромное спасибо, коллега, за разъяснение! Господи, сколько бессмысленных усилий пришлось бы потратить, чтобы понять этот момент! Я исправил переменную с ULONG на _int64 и все стало нормально: уже более 15 минут скорость держится стабильно на уровне 39957 КБайт/сек. Т.е. этот вопрос полностью снят.

Большое спасибо! :-)

[jur]

Привет!

"Играем дальше." (С) Жванецкий :-) Немножко исправил приложение Streamer, сделал передачу данных по Interrupt endpoint. Получил, как и положено, 8000 КБайт/сек. Так получилось потому, что я задал период опроса 1 микрофрейм, а величина ендпойнты составляет 1024 байт. Для контроля правильности эксперимента я параллельно запустил прежний Streamer с Bulk endpoint, который выжимает канал USB досуха. Как и следовало ожидать, эти 8000 КБайт были "откушены" от канала Bulk. Вот скриншоты (Interrupt и Bulk):



После этого я обратился к спецификации USB 2.0 (раздел 5.9 High-Speed, High Bandwidth Endpoints, стр. 56) и выставил число транзакций на микрофрейм равным 3-м. Однако, скорость передачи не изменилась! Вот скриншот:



Причем, число принимаемых байт верное (т.е. если задано 256 буферов по 3072 байта, то именно столько и принимается). Как это понимать? Что я делаю не так?

P.S. Настораживает то, что эти биты, которые задают число транзакций на микрофрейм, не маскируются приложениями. Т.е. USB View, к примеру, рапортует: wMaxPacketSize: 0x1400 (5120). Правда Streamer понимает правильно, но все равно как-то криво рапортует размер пакета в 3072 байта. Это ведь неверно! Размер пакета остался 1024 байт, это число пакетов на микрофрейм должно было бы быть три. А при задании 2-х пакетов на микрофрейм передача вообще не работает...

[jur]

2 ALL... похвастайтесь...

Попробую ;-)

Сегодня запустил свое приложение на дохлой embedded-материнке от VIA (плата EPIA SP). Удивился немерянно! На рабочем месте у меня компьютер Intel P4, 3066 MHz, плата MSI 865PE Neo3-V, чипсет i865PE, который дает 40000 КБайт/сек, а эта слабенькая платка качает со скоростью порядка 44000 КБайт/сек! Вот скриншот:



Однако!...

[Warlord]

Проделал те же шаги, что и jur, касательно bulk передачи, вот мой скриншот:

результаты - один в один Блок питания не шумит, никаких подозрительных звуков не заметил
Результат очень похож на практический потолок для Bulk.

Сообщение отредактировал Warlord - Jan 22 2007, 15:10

[Warlord]

Проделал тоже самое для Interrupt, и здесь результаты одинаковы:

Что касается числа принимаемых байт, то здесь вот какие дела. Камень дает хосту
дескриптор, где в младших 11 битах поля wMaxPacketSize указывает размер буфера и в следующих 2-х еще что-то (спецификации 2.0 нет. Так вот, Streamer как это сказано в хелпе берет это значение и вычисляет MaxPktSize как

Код

If wMaxPacketSize is 0x1400 (binary = 0001 0100 0000 0000)  
  MaxPktSize = [100 0000 0000 binary] * [10 binary + 1] = 1024 * 3 = 3072

далее это число, умноженное на кол-во посылок за раз (Packets per Xfer) передается драйверу, который заготавливает место под данные. Далее, драйвер получает за один прием это число байт и передает аппилкухе. Все. Т.е. те 3072 байта что показывает Streamer никоем образом не влияют на размер передаваемого пакета за микрофрейм. Вот сколько там действительно передается, это вопрос. Судя по тому что скорость предачи не изменилась и осталась на уровне 8МБ\с, то могу предположить что за 1мкФрэйм передаются те же самые 1024 байта :\

Сообщение отредактировал Warlord - Jan 22 2007, 16:18

[jur]

Результат очень похож на практический потолок для Bulk.

Точно! Наверное, это зависит от современных чипсетов. Т.е. 44 тысячи Байт/сек. - это максимально достижимая цифра без каких-то специальных (экзотических) уловок на текущих материнках. (Что интересно, сегодня гонял микросхему (FX2LP) на максимальной скорости весь день - температура ничуть не возросла! Комнатная!)

Что касается числа принимаемых байт, то здесь вот какие дела. Камень дает хосту дескриптор, где в младших 11 битах поля wMaxPacketSize указывает размер буфера и в следующих 2-х еще что-то (спецификации 2.0 нет).

Думаю, что стоит скачать. Полезный документ. Хотя и тяжелый для усвоения...

Вот что написано в разделе 5.9 High-Speed, High Bandwidth Endpoints:

Код

Table 5-11. wMaxPacketSize Field of Endpoint Descriptor:
Bits 15..13 - Reserved, must be set to zero
Bits 12..11 - Number of transactions per microframe
Bits 10..0  - Maximum size of data payload in bytes

Т.е. число транзакций на микрофрейм устанавливается равным трем, а число передаваемых байт не изменяется, как было 8000 Байт/сек так и остается... При двух - вовсе не работает... Чертовщина какая-то...

[Warlord]

Остается только вопрошать технарей Cypress. Пробовал создать аккаунт у них на сайте - дохлый номер, ошибка на странице

Сообщение отредактировал Warlord - Jan 24 2007, 09:50

[jur]

Остается только вопрошать технарей Cypress.

Да, ты прав. Только... Общение с их техподдержкой - спорт не для слабых :-) Нужно будет филигранно сформулировать вопрос, отточить каждую букву. Т.к. первым ответом у них обычно бывает повторение половины моего же вопроса :-) Но, нужно отдать им должное, при достаточной настойчивости ответ получить все-таки можно. По поводу аппаратной проблемы с их CY7C68001 они мне даже раза два на работу звонили! Правда, я не понял ни хрена, сказал, что письмом отвечу :-) Оказалось, моя ошибка была... Я на эту тему в этом форуме даже тред поднимал.

Пробовал создать аккаунт у них на сайте - дохлый номер, ошибка на странице

А я создал год-полтора назад. Думаю, что ошибка на странице возникает из-за их идиотского сайта, написанного какими-то web-пионэрами, мать их... Попробуй с другого броусера зайти, с Оперы какой или Мозиллы.

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

[Warlord]

Давай я переведу вопросы, если ты собираешься писать их на английском, а на ту страницу я с трех браузеров заходил - бесполезно.

[jur]

Давай я переведу вопросы, если ты собираешься писать их на английском

Спасибо, я уже послал вопрос. Уже завершился первый раунд :-) На мой вопрос про передачу 1024-байтных блоков мне посоветовали применить Bulk endpoint :-))) "Играем дальше..." © М.Жванецкий.

а на ту страницу я с трех браузеров заходил - бесполезно.

Во, ёлки... Вот бы пройтись серпом по избранным местам их web-дезайнера... Мечта... ;-)

[jur]

Я обещал сообщить результаты переписки с фирмой Сайпресс в этой теме. Напоминаю, что речь идет о достижении приемлемой скорости передачи данных по Interrupt endpoint с размером пакета 1024 байта. Вы не подумайте, я не забыл и не забросил. Просто я их настолько озадачил, что уже заканчивается третья неделя с тех пор, как я послал им результаты своих экспериментов, а они до сих пор "переваривают"... ;-) В начале недели я им напомнил о себе, что, мол, "Ау! Люди!", но они пока молчат... И CASE не закрывают... Ждем...

[torik]

Думается мне, что они не хотят отвечать... Просто игнорируют нехорошые люди
Завалить их надо письмами!

[jur]

Думается мне, что они не хотят отвечать... Просто игнорируют нехорошые люди
Завалить их надо письмами!

Есть новости!

Мое упорство вызвало у них реакцию отторжения... Несколько недель назад они мне писали, что, цитирую, "микросхема CY7C680013A позволяет передавать данные по Interrupt endpoint с размером пакета 1024 со скоростью 20 и более МБ/сек". У меня это не получилось и я послал им два своих проекта: для микросхемы и для компьютера. Несколько дней назад был получен ответ (после моего напоминания, что я совсем не забыл ;-) ). Типа, извиняемся за долгое молчание. Проверьте, в чем проблема на вашем компьютере. Не является ли система "бутылочным горлышком", которое не позволяет передавать быстрее, чем 8000 КБ/сек. И вообще, мол, не парь нам мозги, а делай на булке :-)

Встает резонный вопрос: "А за базар кто ответит?!" :-) Раз микросхема позволяет - в чем проблема? В моей системе? Вполне возможно. Тогда я пробую на разных материнках (на Интелловских 848 и 865, а также на слабой встроенной embedded-материнке от VIA и более мощной от Kontron). Везде получаю стабильный результат: 40 и более МБ/сек на булке и те же 8000 КБ/сек на Interrupt.

Хочу спросить уважаемых коллег: может быть кто-то из Вас желает присоединиться к эксперименту? Я могу предоставить два проекта (под Кейл для микросхемы, и под VC 6.0 для компьютера) для проверки результатов. Может нам удастся найти ошибку в моих проектах (это, по сути, собственные образцы примеров от Сайпресса)? Анализ этих моих проектов в самой Сайпресс (вот как раз на это они и потратили более двух недель) криминала не выявил, но может быть на самом деле что-то было упущено?

Если же окажется, что в проектах все хорошо, то, на самом деле, давайте завалим их письмами! :-)

[torik]

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

Сообщение отредактировал torik - Mar 8 2007, 11:42

[Warlord]

Думаю хлопцы из сайпресса что-то темнят, что-то не договаривают, врядли ошибка в проекте, у меня тоже ровно 8 МБ\с, т.е. по 1 пакету за мкФрейм. Дело скорее всего в железе. Завалить письмами дело хорошее, только вот куда слать?? Я так понимаю адрес они не дают, работают с case-ами..Хорошо бы поспрашать на иноязычных форумах, может кто сталкивался, не только ж россияне сайпрес-чип используют.

[alexkok]

Думаю хлопцы из сайпресса что-то темнят, что-то не договаривают, врядли ошибка в проекте, у меня тоже ровно 8 МБ\с, т.е. по 1 пакету за мкФрейм. Дело скорее всего в железе. Завалить письмами дело хорошее, только вот куда слать?? Я так понимаю адрес они не дают, работают с case-ами..Хорошо бы поспрашать на иноязычных форумах, может кто сталкивался, не только ж россияне сайпрес-чип используют.

Здравствуйте,

вот что я нашел в USB Complete, Third Edition
(http://proyectosfie.com/html/usb/libro/)

High-speed interrupt transfers can be very fast. A high-speed endpoint can
request up to three 1024-byte packets in each 125-microsecond microframe,
which works out to 24.576 Megabytes/sec. An endpoint that requests more
than 1024 bytes per microframe is called a high-bandwidth endpoint. Windows
XP/Windows Server and earlier don’t support high-bandwidth interrupt
endpoints, however, so the achievable maximum for these operating
systems is 8.192 Megabytes/sec.

[torik]

мдя, интересно.... искали искали, писали долго упорно - а оказалось что спецы из сайпраса сами этого не читали
Интересно, а как у Висты с этим дело обстоит - вообще драйвер CyUSB запашет под ней?

[Warlord]

Спасибо, alexkok, теперь все стало ясно, и со "спецами" из сайпреса в том числе Было бы замечательно, если бы jur написал им что к чему, чтоб перестали мучаться и вводить нас в заблуждение. Документ http://proyectosfie.com/html/usb/libro/capitulo03.pdf 73 страница

[jur]

Большое тебе спасибо, alexkok, очень здорово ты разъяснил этот темный вопрос!

А вот "спецам" из Сайпреса, думаю, пока карты раскрывать преждевременно! ;-) Они мне черным по белому написали, что, цитирую, "Yes, it is possible to achieve 20-30 MB/sec with 1024-bytes blocks transfer speed on CY7C68013A chip using interrupt endpoint." Вот пусть и ответят за базар! Я им написал, что, мол, давайте, колитесь, каковы должны быть характеристики компьютера, что бы achieve эти самые 20-30 MB/sec., какое железо, какая система и т.п. Интересно, что они ответят? ;-)

Ну а для себя, коллеги, я думаю мы с помощью уважаемого alexkok все выяснили? Только сегодня вечером хочу еще попробовать на Висте (о результатах сразу доложу). Оно мне, конечно, пока не подходит (у меня сфера embedded), но со временем станет актуально.

[jur]

Только сегодня вечером хочу еще попробовать на Висте (о результатах сразу доложу).

Докладываю: та же засада. Точно так же не работает на скорости больше 8 МБ/сек. Пробую с тремя пакетами на микрофрейм. Вот скриншот:



P.S. Забыл сказать. Я пробовал на системе Vista RC1, т.е. не на окончательном релизе операционки. Может в окончательном они это пофиксили? Если кто-нибудь попробует, сообщите, пожалуйста.

[alexkok]

А вот "спецам" из Сайпреса, думаю, пока карты раскрывать преждевременно! ;-) Они мне черным по белому написали, что, цитирую, "Yes, it is possible to achieve 20-30 MB/sec with 1024-bytes blocks transfer speed on CY7C68013A chip using interrupt endpoint." Вот пусть и ответят за базар! Я им написал, что, мол, давайте, колитесь, каковы должны быть характеристики компьютера, что бы achieve эти самые 20-30 MB/sec., какое железо, какая система и т.п. Интересно, что они ответят? ;-)

Ну если очень нужен interrupt можно же четыре ендпойнта использовать.
4*8МБ = 32МБ - гарантированных!

[Warlord]

Ответ неверный, будет не 4*8 а 4*2 т.е. те же 8МБ.

[jur]

Ну если очень нужен interrupt можно же четыре ендпойнта использовать.
4*8МБ = 32МБ - гарантированных!

У меня немножко другой случай. Мне проще построить свою аппаратную часть (в приборе), если размер ендпойнты будет 1024 байта. Такой размер может быть только у Interrupt и Isochronous ендпойнтов. К Isochronous я пока отношусь настороженно, т.к. мне очень важно, чтобы доставка пакетов была гарантированной, а это обеспечивается только в Interrupt ендпойнте.

Использовать параллельно несколько ендпойнтов - тоже не выход. Во-первых, их число ограничено, а во-вторых, опять же, это вызовет существенное усложнение моей аппаратной части. Если уж усложнять, то на одной булке лучше сделать :-)

Вот, собственно, именно поэтому я и пристал к этой Interrupt ендпойнте :-)

[alexkok]

Ответ неверный, будет не 4*8 а 4*2 т.е. те же 8МБ.

А можно объяснить поподробнее почему?
32МБ не получается, согласен, нет конфигурации без буферизации.
Но 16МБ должно вроде получиться 2*8МБ = 16МБ.

У меня немножко другой случай. Мне проще построить свою аппаратную часть (в приборе), если размер ендпойнты будет 1024 байта. Такой размер может быть только у Interrupt и Isochronous ендпойнтов. К Isochronous я пока отношусь настороженно, т.к. мне очень важно, чтобы доставка пакетов была гарантированной, а это обеспечивается только в Interrupt ендпойнте.

Гарантированной в смысле отсутствия ошибок или в смысле времени доставки?

Использовать параллельно несколько ендпойнтов - тоже не выход. Во-первых, их число ограничено, а во-вторых, опять же, это вызовет существенное усложнение моей аппаратной части.

Один CPLD за 2-3 доллара это существенное усложнение?

Если уж усложнять, то на одной булке лучше сделать :-)

Если время не критично, то конечно.

Сообщение отредактировал alexkok - Mar 16 2007, 09:24

[Warlord]

2alexkok
USB 2.0 - 1 мкФрейм - 125мс, всего 8000 мкФреймов в секунду. Хост-контроллер USB 2.0 под управлением XP в режиме Interrupt может передать за 1 мкФрейм всего 1 пакет размером 1024 байта. Не больше!! Поэтому суммарная проп.способность будет 8000 * 1 * 1024 или 8 МБ\c. На пальцах: если максимум что можно прокачать через трубу это 1 литр в секунду, то подклчив 2 насоса мощностью 1 литр к одной трубе все равно больше чем 1 литр не прокачаешь.

[jur]

А можно объяснить поподробнее почему?
32МБ не получается, согласен, нет конфигурации без буферизации.
Но 16МБ должно вроде получиться 2*8МБ = 16МБ.

"Нету!" (С) Зощенко :-) Я пробовал запустить параллельно два приложения - получается два по ~4 МБ/сек (одно - стабильно 8 МБ/сек). Больше двух не пробовал, но думаю, что общий траффик в 8 МБ/сек пропорционально поделится между ними.

Гарантированной в смысле отсутствия ошибок или в смысле времени доставки?

Для меня наиболее важно отсутствие ошибок. Я передаю видеокадр (речь идет об ультразвуковом сканере) и любое пропадание лучей или их сбой дают заметные артефакты на изображении.

Один CPLD за 2-3 доллара это существенное усложнение?

У меня уже стоит CPLD :-) Просто мне не хочется "Плодить сущности без надобности" (С) :-) Но если другого выхода не будет - куда я денусь?...

[alexkok]

Хост-контроллер USB 2.0 под управлением XP в режиме Interrupt может передать за 1 мкФрейм всего 1 пакет размером 1024 байта. Не больше!!

Спасибо за информацию. А это касается одного порта или суммарно по всем?

"Нету!" (С) Зощенко :-) Я пробовал запустить параллельно два приложения - получается два по ~4 МБ/сек (одно - стабильно 8 МБ/сек). Больше двух не пробовал, но думаю, что общий траффик в 8 МБ/сек пропорционально поделится между ними.

Спасибо, буду знать. А два приложения - это два устройства?
Если да, то на одном порту или на разных?

[jur]

Спасибо, буду знать. А два приложения - это два устройства?
Если да, то на одном порту или на разных?

Устройство одно. Это просто тестовое устройство, которое непрерывно генерит USB-траффик. Когда я запускаю одно приложение на PC, то имею ~8 МБ/сек (см., например, мое письмо в этой ветке от Mar 13 2007, 19:40). А когда я запускаю еще одно приложение, то траффик разделяется между ними:



P.S. Юбилейный, 100-й пост у меня получился! :-)

[Warlord]

Спасибо за информацию. А это касается одного порта или суммарно по всем?

Это касается хост-контроллера USB на материнке, а он обычно один Поэтому суммарно по всем.

[alexkok]

[attachment=10263:attachment]

Это касается хост-контроллера USB на материнке, а он обычно один Поэтому суммарно по всем.

Жаль, а где это описано?

Сообщение отредактировал alexkok - Mar 20 2007, 00:03

[alexkok]

Устройство одно. Это просто тестовое устройство, которое непрерывно генерит USB-траффик. Когда я запускаю одно приложение на PC, то имею ~8 МБ/сек (см., например, мое письмо в этой ветке от Mar 13 2007, 19:40). А когда я запускаю еще одно приложение, то траффик разделяется между ними:

Ещё одно уточнение.
Каждое приложение работает со своим ендпойнтом? (не с тем же самым?)

[jur]

Ещё одно уточнение.
Каждое приложение работает со своим ендпойнтом? (не с тем же самым?)

Ендпойнта одна. Но это рояли не играет, т.к. в булочном режиме она легко дает более 40 МБ/сек.

[alexkok]

Ендпойнта одна. Но это рояли не играет, т.к. в булочном режиме она легко дает более 40 МБ/сек.

Играет. Интеррапт ендпойнт опрашивается максимум один раз за микрофрейм, не чаще, в отличие от балка. В случае ошибки в пакете, пакет перепосылается в следующем микрофрейме.

[Warlord]

Играет. Интеррапт ендпойнт опрашивается максимум один раз за микрофрейм, не чаще, в отличие от балка. В случае ошибки в пакете, пакет перепосылается в следующем микрофрейме.

Булка тоже опрашивается раз в мкФрейм, просто в булке можно передать гораздо больше пакетов за мкФрейм. В интерапте 1-3, а в булке 1-(15??). Про порты и суммарный поток написано в стандарте по USB где же еще...

[alexkok]

Булка тоже опрашивается раз в мкФрейм, просто в булке можно передать гораздо больше пакетов за мкФрейм. В интерапте 1-3, а в булке 1-(15??). Про порты и суммарный поток написано в стандарте по USB где же еще...

Ну что ж, открываем стандарт по USB,

Universal Serial Bus Specification Revision 2.0

Table 5-8. High-speed Interrupt Transaction Limits

Data.........Max.................Microframe......Max..........Bytes.........Byte
s/
Payload....Bandwidth........Bandwidth.......Transfers...Remaining..Microframe
..............(bytes/second)...per Transfer.....................................Useful Data

1024........ 49152000............14%................6.............1026........6144


И где же здесь 8МБ лимит?

[Warlord]

8МБ лимит - это касательно определенной ОС, конкретно WinXP и похоже Vista. Эти ОС позволяют передавать всего 1 пакет 1024 байта за мкФрейм. Но меня смущает цифра 6 в колонке Max Transfers. Уж не хотят ли они сказать, что шесть INT EP могут передать 6*1024 за мкФрейм?? Надо будет попробовать сделать хотя бы 2 EP...

[Aaron]

Доброго всем дня. Подскажите, плз, в каком направлении мне думать:
Имею свою плату на CY7C68013A. Скачал с сайпресса CY4604 (DevStudio + Streamer example) и CY4603 (CyStream). В обоих архивах имеется cystream.iic, только в 4603 он с исходниками. Взял исходники, подправил их под себя (убрал код, предназначенный для ДевБоарда), - с программой CyStream от 4603 все нормально работает.
Вот данные, которые показывает прога CyStream (приближенно):
FS ISO-OUT 1023 2-buf -- 1000KBps
HS ISO-IN 1024 2-buf -- 8000KBps
HS ISO-IN 3x1024 2-buf -- 24000KBps
HS BULK-IN 512 2-buf -- 39000KBps
Картинки прилагаются. Однако начинаю проверять эти передачи с помощью USB-анализатора (Ellisys USB Explorer), и он показывает скорости гораздо меньшие, чем отображает CyStream. К примеру, при передаче ISO-IN 3x1024 2-buf анализатор показывает около 3МБ/с. Возникает резонное предположение, что CyStream отображает данные в килобит/с. Однако в описании к проге из их скриншотов, таблиц и выводов я заключаю, что в проге указана скорость в килобайт/с. Чему мне верить?
И еще: Streamer, взятый из CY4604, у меня отказывается вообще работать с любыми девайсами. Даже если и кнопка "Start" нормально нажимается. Скриншот прилагается. Думал, может виноват драйвер? Пробовал с разными версиями cyusb.sys, cydvk.sys, - не помогает. Вот. Прошу помощи, уже не знаю, что и делать.

ЗЫ: просто хочется знать реальную пропускную способность девайса, а из ПО сейчас работаю тока в Кейле, VisualC++ равно как и BorlandC можно сказать совсем не помню, так что писать свою прогу для компа - ;(( оч много времени уйдет, пока все заново изучу.

ЗЫ2: система Celeron 1200MHz 256MB DDR WinXPSP2Pro USB2.0 контроллер на PCI-плате от Acorp.

Сообщение отредактировал Aaron - Mar 23 2007, 17:03

Эскизы прикрепленных изображений

 

[alexkok]

Картинки прилагаются. Однако начинаю проверять эти передачи с помощью USB-анализатора (Ellisys USB Explorer), и он показывает скорости гораздо меньшие, чем отображает CyStream. К примеру, при передаче ISO-IN 3x1024 2-buf анализатор показывает около 3МБ/с. Возникает резонное предположение, что CyStream отображает данные в килобит/с. Однако в описании к проге из их скриншотов, таблиц и выводов я заключаю, что в проге указана скорость в килобайт/с. Чему мне верить?
ЗЫ2: система Celeron 1200MHz 256MB DDR WinXPSP2Pro USB2.0 контроллер на PCI-плате от Acorp.

Скорее всего система слабовата для Ellisys USB Explorer. В его в мануале это написано.
Так что CyStreamу больше доверия.

[Aaron]

Скорее всего система слабовата для Ellisys USB Explorer. В его в мануале это написано.
Так что CyStreamу больше доверия.

Да, действительно. Сейчас попробовал USB Explorer подключить к компу 2000МГц / 512МБ DDR - уже показывает 100МБ за 10сек. (При этом реально прокачиваемые данные выходили около 15МБ/с). Интересно, конечно, получается. Хотя в мануале к USB Explorer написано, что для нормальной его работы достаточно Пня 600МГц / 128МБ RAM.
Кстати, Реальные 15МБ/с моя железка выдавала как на моем старом компе, так и на том, который пробовал сейчас еще.

Сообщение отредактировал Aaron - Mar 26 2007, 14:03

[klop]

А не подскажете где можно найти етот самый ezusb.sys поновее. А то у меня железка пришла с софтиной которая работает с етим ezusb.sys и на Висте становиться не хочет.

Заранее спасибо.

[brag]

Возможно тема очень старая и уже давно пора переходить на CYUSB3, но тем не менее...
Стыкнулся я тоже с проблеммой получения гарантированной производительности Interrupt endpoint, ответа ессно не нашел ни в этой теме, ни на cypress. Так что отвечаю я
Чтобы получить максимальную производительность 24576000 байт/сек нужно успеть за микрофрейм(125мкс) записать в буффер 3072 байт. Тобышь IFCLK должна быть >24.576мгц. Запишете хоть на 1 байт меньше за выделенные 125мкс - весь микрофрейм коту под хвост, вернее посылка будет передана в следующие 125мкс, а это почти 125мкс простоя, от этого и производительность падает примерно в 2 раза.

Если нужно передавать с частотой меньше 24.576мгц, скажем 24мгц, как в моем реальном проекте - поступаем следующим образом:
1. wMaxPacketSize остается без изменений и равен 0x1400 (1024 байт, 2 доп. пакета в микрофрейме). bInterval=1, еснно
2. Endpoint (EP2CFG/EP6CFG) тоже настраиваем как обычнно - 1024 байт, 2-4хbuffer
3. EP2FIFOCFG=EPxFIFOCFG_AUTOIN|EPxFIFOCFG_ZEROLENIN
4. EP2AUTOINLEN=1000
В итоге CY будет комитить пакеты размером не 1024байта, а 1000, но опять же 3000 байт нужно успеть записать за 125мкс, тобышь ifclk должен быть >24мгц (1000*3/125е-6)

[QingTing]

Добрый день уважаемые форумчане. Я использую FX2 в своих проектах уже около четырех лет. Задачи которые она выполняет это передача определенного количества данных из ПЛИС в ПК только в одном направлении (например: по команде я передаю заведомо известное количество данных в ПК. ПК принимает заведомо известное количество данных и записывает в память). FX2 включена как SLAVE FIFO (асинхронный режим), используется только одна конечная точка EP2, режим Bulk, размер пакета 512 байт, размер буфера 4096 байт.

До недавнего времени такая конфигурация вполне устраивала. Но появилась новая задача, передача непрерывного потока данных (отсчеты сигнала от АЦП) в ПК. И здесь появилась проблема.

Непрерывная передача работает с пропусками отсчетов сигнала. Я непрерывно загружаю данные из ПЛИС в FX2. ПК принимает данные "кусками" по 50 Мбайт (из слов программиста, он запрашивает по 50 Мб). Внутри "куска" разрывов данных нет (разрывов сигнала), а между "кусками" появляются разрывы по времени приблизительно 200 мс. Т.е. когда после приема 50 Мб данных он дает запрос на следующие 50 Мб данных, на это уходит какое то время. За это время буфер FX2 соответственно переполняется и запись в него данных мною прекращается, пока буфер не освободится.

Я понимаю что такая реализация неверна. Как правильно делается непрерывная передача данных при помощи FX2? Какой режим использовать? Поделитесь пожалуйста своим опытом.

[jcxz]

Выпрямляйте руки вашему "программисту" - почти наверняка он не использует BeginDataXfer/FinishDataXfer.
Да и себе заодно - наверняка у вас bulk там где должна быть изохронная.
А вообще тема тут уже сто раз муссировалась.

У меня в проекте было isochronous + BeginDataXfer/FinishDataXfer непрерывно.
Единственно косяк был (который так и не удалось побороть и который похоже косяк CyUSB.lib, а не CY7C680013A) -
это когда во время работающей передачи свернуть/развернуть любое окно в винде - возникала дырка в обмене
(просто отсутствовали фреймы на время разворачивания). Проявляется это только под XP, под более новыми виндами то же самое
ПО работает без всяких дырок. Причём больше никакие другие события в системе почему-то к таким дыркам не приводят
(даже если загрузить CPU высокоприоритетной задачей на 100% - всё ок, но если развернуть окно - всё, труба).
Это проблема именно CyUSB.lib, так как абсолютно так же проявляется и в других моих проектах на ней с другими CPU
(без CY7C680013A).

[QingTing]

Да, возможно программист что то делает не так. Спасибо за подсказку я ему обязательно покажу Ваш пост, пусть почитает.
Я много тем прочитал по FX2 на этом форуме, и почему то все отговаривают от использования изохронного режима передачи данных. Якобы существует вероятность потери данных. В моем проекте это недопустимо, не должно быть разрывов сигнала. Темп следования данных на входе FX2 составляет 2 МГц, разрядность данных 16 бит, соответственно скорость передачи данных будет 4 Мб/с.

То есть мне надо обязательно использовать изохронный режим? Или в моем случае можно обойтись балком? Какое преимущество изохронного режима перед балком?
Заранее благодарен за ответ.

[jcxz]

Я много тем прочитал по FX2 на этом форуме, и почему то все отговаривают от использования изохронного режима передачи данных. Якобы существует вероятность потери данных. В моем проекте это недопустимо, не должно быть разрывов сигнала. Темп следования данных на входе FX2 составляет 2 МГц, разрядность данных 16 бит, соответственно скорость передачи данных будет 4 Мб/с.

А с чего бы этим данным теряться? Из-за помех? А какова их вероятность?
А что, на bulk - помехи не действуют? Ах, ну да, там гарантированная доставка! Думаете она святым духом сама собой реализуется?
Нет, всего лишь повтором недоставленных данных.
А Вы это учитываете? В объёме буферов и полосе передачи заложили избыток?
Хватит у вас объёма буферов чтобы они не переполнились на время переповтора (сколько там мсек?)?
А учитываете что bulk - самый низкоприоритетный вид передачи (и самой спецификацией предназначен для фоновых передач)?

А знаете что куча устройств, сидящих на этой-же шине и использующих bulk (или не дай бог - более приоритетные виды передач)
могут во время работы вашего устройства запросить полосу и хост обязан её им предоставить равномерно раздав всем просящим поровну?
Где тогда будут ваши 4МБ/сек?

То есть мне надо обязательно использовать изохронный режим? Или в моем случае можно обойтись балком? Какое преимущество изохронного режима перед балком?

Такое, что когда втыкается изохронная точка, хост ОБЯЗАН предоставить ей запрашиваемую полосу. Если же он не может - он отключит устройство.
И если полоса предоставлена, то она будет ГАРАНТИРОВАННО закреплена за этим девайсом и никакой другой девайс не сможет её занять.

изохронный - гарантированная полоса передачи, с маловероятной недоставкой.
bulk - гарантированная доставка, с непредсказуемым временем.

В результате, при воздействии помехи (если Вы их так боитесь) у Вас и ваш bulk захлебнётся, так как Вы не обеспечили ему требуемой глубины буферизации.

[QingTing]

Спасибо большое за такой развернутый ответ. Буду менять конфигурацию FX2 и пробовать.