[jur 0]

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

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

[VitalyM4 0]

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

 

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

:blink: :blink:

[jur 0]

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

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

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

[VitalyM4 0]

Ладно сделаем посмотрим.

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

[XShocK 0]

Теперь правда беда, скорость с 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 0]

Еще вопрос, в режиме 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 0]

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

 

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

[XShocK 0]

Дело в том, что если использовать оочень большой буфер(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- 0]

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

 

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

[XShocK 0]

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

[VitalyM4 0]

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

 

 

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

 

СПС!

[-Al- 0]

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

 

 

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

 

СПС!

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

[Gate 0]

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

measuring_delivered_usb_2_0_bandwidth_with_an_ez_usb_fx2_development_board_9.pdf

streaming_data_through_isochronous_bulk_endpoints_on_ez_usb_fx2__9.pdf

streaming_over_usb_with_isochronous_and_bulk_transfers_16.pdf

[jur 0]

Все больше и больше мне становиться интересно какой-же все-таки метод передачи является самым быстрым. И как лучше всего передавать данные по самому 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 0]

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

 

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

 

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

 

Спасибо.