Warlord

да, CSL без граф.конфигуратора пользоваться можно, но русский чел он же ленив, поэтому, если есть возможность, нагляднее ткнуть в графику, а то приходится структуры прописывать, функции конфигурирования вызывать.. Вот только мне все же непонятна логика спецов TI: На 5510 и 5509 CSL в граф.кофигураторе BIOSа присутствует, а для 5502 нет, чем этот камень хуже...

я именно графический конфигуратор и имею ввиду :) А почему в 2.x его не может быть?? В таком случае всю периферию придется руками описывать??

Ни в CCS2.xx ни в CCS3.xx нет Chip Support Library в BIOS для камня 5502. Это прикол TI??

Уговоренный драйвер работать не захотел, тогда я просто заменил его из старого комплекта и CCS завелся, правда теперь при загрузке программы каждый раз ругается, что "RTDX Configuration Control" "Unable to determine default Pin/Port configuration".

Update Advisor->Check for Updates, приводит на страницу, где как я понял, надо зарегистрироваться, чтобы выкачать апдейты :( CCS не купленый, поэтому проблема. P.S. Скачал дрова, по подсказке serwz, установил, запустил - красный крест(лампочкой мигнул только), смотрю лог, а там Invalid firmware version >>Need: TMS320C5510 DSK Firmware $Revision: 24 $ $Date: 7/12/04 10:40a $ >>Found: TMS320C5510 DSK Firmware $Revision: 18 $ $Date: 9/19/02 3:00p $ Т.е. прошивка не по нраву...Как поступать?? Можно попробовать уговорить конечна...

В комплекте шел CCS 2.12 Думал просто перенести нужые файлы, перенес, конфигурацию импортировал, драйвер указал, запускаю - ан нет, не видит студия девайса. Может Update какой есть??

Почему 13МБ\с получилось?? Через каждые 3 такта - это есть на каждый 4-й. Т.е. частота 5МГц, по 2 байта за герц, получается 10МБ\с. Это совпадает с результатами Streamer-а :) Если все же 13МБ\с, то проверьте действительно ли записываются 16 бит (если 8 то результат тоже объясним).

2Гяук Какова ширина шины фифо?? Разницы как работать с SX2 синхронно или асинхронно ИМХО нет. Дескриптор тоже рояли не играет. Попробуйте проект Streamer и поиграйте параметрами, какую скорость он покажет в Вашем случае??

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

Согласен, 64 байта в буфере - это косяк, тут без специалиста TI не разобраться.. т.е. если одни NOP-ы идут, то следовало ожидать, что наполненность буфера будет колебаться от 20 до 24, наполняясь каждые 4 такта.

прости, я про fx2... но не суть важно, убедись, что камень считывает ПЗУху, т.е. достает информацию. А то может он стучит, а достучаться не может.. В мануале сказано, что если нет памяти внешней никакой, то камень грузит инфу по умолчанию, так вот я проверил, что если выдернуть ПЗУху, то камень молчит как партизан, виндофс говорит, что устройство неправильно пронумеровано, а USBView соотвесно дает нули.. почему камень не энумеруется, вот вопрос..

присутствие NOP-а отодвигает начало функции на байт. Если начало функции выровнено по 4байтовой границе, то stall есть, иначе его нет. Т.е. без NOP-а начало 0x218 - stall, с NOP-ом начало 0x219 - нет stall-а. В этом случае буфер не опорожняется (prefetcher не останавливается) а когда на преддекод поступает команда RET, то буфер забивается 64 байтами (1байт начитается сразу после call test, так называемый speculative fetch). Тут все правильно, так и д.б. Но почему prefetcher останавливается(если адрес выровнен), это вопрос..

Если по нулям, то может камню не нравится содержимое пзухи или он не может ее прочитать, хотя делает попытки... А почему первый байт 0xC4??

Ответ: нельзя. В принципе все равно какой используется класс, тут главное скорость передачи. Low-speed(1.5 МБит\c), Full-speed(12 МБит\c) и Hi-speed(480 МБит\c). Судя по тому что 1Мб передается за 30!! секунд, можно сказать что это не есть нормально. Ищи косяки. Даже при Low-speed картинка передастся быстрее (секунд за 6). На Hi-speed реально достичь 44МБ\с

Какие грузить VID и PID - это все равно, проблема еще в чем-то. Попробуй микросовтовскую утилиту USBView или USB Monitor, глянь ходит ли там ваще чего-нибудь.

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

Запустил CCS 3.1 где плаг версии 3.0. Тут несколько другая картина Рис.1 NOP_16 || NOP <- адрес 0x12b9a находится в предекоде. NOP_16 || NOP_16 <-3 байта из 4х находятся в буфере NOP_16 || NOP_16 NOP_16 || NOP_16 RET В преддекоде сидит NOP_16 || NOP(в буфере она не отображается). В буфере 3 байта следующей 4 байтовой инструкции NOP_16 || NOP_16 Рис.2 NOP_16 || NOP <- уходит в execute конвееер в фазу D NOP_16 || NOP_16 <-адрес 0x12b9d уходит в предекод. NOP_16 || NOP_16 <- начиная с этого адреса в буфере лежит 64 байта NOP_16 || NOP_16 RET Проц считывает в буфер 1+64 байта (вместо положенных 4) и 3+1 уходят на преддекодирование. Видно что в буфере остается 64 байта. Рис.3 Буфер полностью очищается и в него поступают почему-то 3 байта!! а на преддекодирование идет пустышка, и возникает stall. NOP_16 || NOP NOP_16 || NOP_16 <- уходит в execute конвееер в фазу D NOP_16 || NOP_16 <- снова адрес 0x12b9d(хотя уже считано)в буфер ложатся 3 байта, возникает stall NOP_16 || NOP_16 RET Рис. 4 В очередь дочитывается след.4 байта, 3+1 (NOP_16 || NOP_16) уходят на предекодирование и далее все нормально. NOP_16 || NOP NOP_16 || NOP_16 NOP_16 || NOP_16 <- адрес 0x12ba1 находится в предекоде, в фазу D пустышка NOP_16 || NOP_16 RET Если не трудно, просимулите этот пример, может чего прояснится..

Опечатался со stall-ом в AC2. Рис.1 буфер пуст, хотя показывает 64/64 от балды что ли?? Потом возникает IBQ-stall рис.2 и в конвеер вваливается пустышка рис.3 Так вот непонятный это первый рисунок, почему буфер пустой, почему его размер 64/64 и что мешает ему заполняться... Что касается RET то тут все правильно и ясно, конфликтов нет, адрес возврата берется из регистра RETA.

Stall происходит потому что по непонятным причинам опустошается IB и нечего подавать на фазу D. Это случается еще до попадания в фазу D инструкции RET. На скриншоте два stall-а, первый из которых - непонятный(фаза AC2), а второй - это происходит принудительная очистка конвеера перед возвратом из функции. Одно совпадает точно - IB наполняется с постоянной скоростью 4 байта или не наполняется вовсе. Если команды - одиночные NOP-ы, то видно что IB опустошается не 6 байтами, а как и следовало ожидать по 1 байту. Мануал магически говорит: Вообще говоря, работа плагина как-то не вяжется с описанием работы конвеера, так та пачка(по сути преддекодированая инструкция), что д.поступить в D куда-то из IBQ пропадает, и IBQ уменьшается ровно на размер этой пачки. Иногда размер IBQ становится равным 64/64, хотя видно, что очередь пуста... Хоть в TI support пиши, чтоб объяснили...

Жизнь совпадает с симулятором - 32 такта, включая CALL(5) и RET(11), 15 инструкций, 1 stall

О том как работает fetch конвейер в мануалах TI написано скупо и поверхностно. Буфер IB наполняется со скоростью 4 байта, а опустошается 1-6 байт. Смотрю в Pipeline Stall Analyzer по ходу программы IB начинает опустошаться и возникает IBQ stall причем никакими страшными 5 и 6 байтными командами и вызовами и циклами не пахнет. Отсюда возникают вопросы: При каких условиях перестает наполняться очередь и при каких вознобновляется. Вот для примера кусочек кода: _func NOP_16 || NOP NOP_16 || NOP_16 NOP_16 || NOP NOP_16 || NOP NOP_16 || NOP NOP_16 || NOP_16 NOP_16 NOP_16 || NOP NOP_16 NOP_16 || NOP NOP_16 || NOP_16 NOP_16 || NOP NOP_16 || NOP_16 NOP_16 || NOP_16 NOP_16 || NOP_16 RET В процессе выполнения последние 2 инструкции перед RET оказываются отсеченными IBQ stall. Почему? Никаких видимых препятствий для наполнения буфера нет.

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

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 а 4*2 т.е. те же 8МБ.

2Igoryok Работать с несколькими девайсами можно. Для этого нужно для каждого девайса создать свой класс. В параметрах конструктора указывается GUID девайса, соответсвенно, в inf файле каждой железки перед инсталяцией прописывается индивидульный GUID. Короче читай мануал на CyUSB там это есть.