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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Думаю хлопцы из сайпресса что-то темнят, что-то не договаривают, врядли ошибка в проекте, у меня тоже ровно 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.

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

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

Большое тебе спасибо, 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), но со временем станет актуально.

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



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

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

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

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

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

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

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


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


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

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

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

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

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

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

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


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

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



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

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

Нажмите для просмотра прикрепленного файла
Жаль, а где это описано?

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

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

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

Булка тоже опрашивается раз в мкФрейм, просто в булке можно передать гораздо больше пакетов за мкФрейм. В интерапте 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МБ лимит?

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

Доброго всем дня. Подскажите, плз, в каком направлении мне думать:
Имею свою плату на 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.

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

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

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

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

Возможно тема очень старая и уже давно пора переходить на 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)

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

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

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

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

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

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

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

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

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

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


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

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

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

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