XShocK

Спасибо за ответы. Про "первую мысль" это я переусердствовал, дизайн мы отполировали в PowerPlay+Optimizer'е, вот я и надумал дешевое решение. Судя по всему вы правы, и снижать меньше рекомендованой производителем лучше не стоит. Буду копать в сторону оптимизации как вы рекомендовали.

Есть задача уменьшить потребление Cyclone 3 120K до минимума. Первая мысль пришедшая в голову - уменьшить напряжение VCCint. Кто пробовал такой способ, отпишитесь пожалуйста. Реализуемая максимальная частота после синтезации дизайна на 50% выше желаемой, так что в принципе есть место для уменьшения напряжения. Насколько посстрадает Fmax если уменьшить Vcore скажем с 1.2В до 1.0В? А так-же, насколько уменьшиться потребление? Altera не говорит ни слова о вариации напряжения VCCint. В принципе уменьшение VCCpll тоже может помочь.

У меня такое происходит когда JTAG шумный, и не может без ошибок загрузить ПЛИСину. Для теста проверьте ваш JTAG Chain в меню Processing -> JTAG Chain Debugger -> Run until stopped посмотрите, появляются-ли ошибки время от времени, у меня вот сейчас такая проблема, JTAG chain is uncertain.

Раз уж зашла речь о размерах soft процессоров и их скоростей, то стоит опомянуть ZPU(http://www.opencores.org/?do=project&who=zpu). В самом мельком виде процессор довольно маленький(зато полный 32-бит проц), есть отличный С компилятор на базе GCC, размер кода достаточно мелький тоже. Есть несколько градаций процессора размер/скорость, конечно скоростей больше 2-5MIPS ждать не стоит, но как мелкий проц ZPU очень даже удобен. Сам проц безплатный, компилятор тоже. Если уж очень нужен дебаггер(c JTAG или нет не знаю), стоит вроде 200уе, для наших нужд он никогда не был нужен. ЗЫ: Забыл добавить что под него и eCos портировали, что хоть и не сложно, но удобно.

Где можно его взять? Я сам студент, сразу просто купить не могу, нужно сначала посмотреть стоит оно того или нет. Спасибо. ЗЫ: На electronix ftp не нашел.

Держу Gta01v4 в своих руках. Железо действительно сыровато. Использовать по назначению трудновато, глюки с засыпанием убивают батарею менее чем за 5 часов. Есть прочие недочеты, самому пришлось отпаивать транзистор для работы засыпания(этот глюк правда был исправлен в версиях ушедших на производство, у меня-же pre-mass production development unit). Если есть вопросы, задавайте.

Полностью аналогичная проблема. Он вообще ни на что не реагирует, пишет что статус 8(CHAIN_COMPLETE, because OWNED_BY_HW=0) и ни байтика не копирует.

Кол-во tap показывает сколько сэмплов передается за один такт. Так как в базовом камералинке имеется 28 линий для данных, то можно передать 2 сэмпла по 10-12 бит информации в каждом, тем самым уменьшая частоту клока в два раза. Мда. Чувствовал, что что-то не так. И только сейчас понял, что на дворе уже 2007 год, а вопрос был задан ровно 360 дней назад. :)))

Использую Tutty для всего. От последовательного порта до SSH.

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

Дома использую Konica Minolta PagePro 1350W. Доволен принтером и лазерно-утюжной печатью. В картридже встроен барабан, тем самым сильно увеличивает стоимость нового картриджа. Но я уже второй раз успешно его перезаправляю. Первый раз пришлось его разобрать и почистить(он давал белые полосы после перезаправки, стоило почистить лезвие захвата тонера и все начало работать как новое). Разрешения 1200х600 мне хватает за глаза для пайки CY7C68013(не помню спейсинг) и SN75LVDS386(PSOP 48, 0.5 BSC spacing) и прочих. ЗЫ: Оригинальный тонер для принтера давал лучшее качество чем перезаправленный. Картинка получалась реально черной без заметных просветов в тонере. После перезаправки стали заметны мелкие точки просветов. Мне это сильно не мешает так как я использую эту разрекламированную зеленую пленку и растворяющуюся бумагу. Очень доволен кстати. ЗЗЫ: Я читал, что BROTHER HL2040R используют "плохой" тонер, и он не прилипает к платам, насчет BROTHER HL2030R не знаю, но посоветовал-бы сначала проверить.

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

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

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

Размер буфера на весь кадр, тоесть примерно 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.