dxp

Протел меня все время как-то удивляет: то они запрещают пользователю оформлять 4-way junction, Почему запрещают? Это на автомате он не дает делать такие соединения, а поставить точку соединения вручную никто не мешает. ??? Так ведь сразу же видно, что нарушение - цветом ярко загораются все объекты, участвующие в нарушении! Т.е. все видно сразу, сразу же и ведешь, как надо. Что касается Пикада. Не знаю, как сейчас, но в 2000/1 процесс таскания проводников был совершенно безобразный - не то, что look-ahead нету, а вообще нормально проводник трассировать невозможно - либо проводника не видно, либо надо все время держать нажатой кнопку. Если до конца не довел, нажал не Esc, оно само по своему разумению доканчивает трассировку проводника. Надо ли говорить, что заканчивает всегда просто дебильно. Т.ч. приходится это исправлять. В Протеле мне больше всего не нравится (в контексте трассировки) то, что он до сих пор не умеет по нормальному drag'ать объекты - потащил сегмент или переходное - соединенные с ним тащются под произвольными углами, что не есть гуд (хотя с точки зрения TopoR'а, наверное, только так и надо :) ). Это раздражает.

В третьем режиме у меня почему-то возможна прокладка проводника по контактным площадкам других цепей/компонентов. Соотв. правило на зазор проводник-КП определено как 0.3 мм. Зазоры проводник-проводник в этом режиме соблюдаются. <{POST_SNAPBACK}> Дело в том, что в этом режиме двигаются только проводники, а пады стоят на месте. Когда вы тащите проводник дальше, куда нельзя, программа имеет два выбора: либо вести себя как в первом режиме, либо - как во втором. Протел выбирает первый, что, очевидно, Вам не нравится - Вам бы, видимо, хотелось бы, чтобы было как во втором - уперся в препятствие и все. Какой из вариантов лучше, не знаю, но принципиальной разницы не вижу. В любом случае видно же, что нарушение возникает, не тащи туда. Главное, что проводники раздвигаются и не нужно делать переразводку всей шины в случае, если надо проводник вклинить.

Мда... Три режима интерактивной трассировки, но как их эффективно использовать? Программа раздвигает проводники только в случае необходимости редактирования уже проложенного - об этом прямо в хелпе написано. А раздвигать надо при прокладке, как в PCAD и PADS... <{POST_SNAPBACK}> Именно при прокладке и двигает. Есть три режима интерактивной трассировки: 1) Ignore Obstacle. 2) Avoid Obstacle. 3) Push Obstacle. В первом режиме когда ведешь проводник, можно спокойно пересекать трассы, программа этому не препятствует, только подсвечивает нарушения, т.ч. сразу видно, где замыкание либо узкое место. Во втором режиме прогрмма не дает делать нарушения - проводник не проведешь через уже проложенные объекты, принадлежащие другим связям. И в третьем режиме когда ведешь проводник, если необходимо, уже проложенные раздвигаются. Все это происходит в соответствии установленными правилами на зазоры. При ведении проводника можно оперативно переключаться между всеми тремя режимами по хоткею Shift+R. Название текущего режима отображается в строке состояния.

Совершенно верные замечания. Во-первых, цена. Во-вторых, при меньшей цене возможности шире - частота оцифровки выше, памяти больше, частотные характеристики лучше - например, джиттер семплинга лучше в несколько раз (3 пс против 15 пс у Аджилент 6000 и 15 пс у Тек 5000), математики встроенной куча - компьютер как-никак! :) При этом же интеграция с другими программами, когда можно, например, вызывать матлабовскую функцию для обработки. Можно писать вообще свое приложение. Более того, скоп можно использовать как удаленный сервер - программа на одном компе крутится, а измерительная часть - на другом. Рулез, короче, неимоверный! :) Единственное, что у Agilent серии 6000 круче - это экран. У Лекроев 800х600 точек. А у Аджилентов - 1024х768. Правда, у Лекроя экран сенсорный, что дает офигительные удобства по рулению прибором, а у Аджилетов экран обычный, насколько понял. Т.ч. и тут я бы все-таки отдал бы предпочтение пусть меньшему экрану, но с тачскрином. Что касается фич. Да, все фичи уже встроены. Например, на моем 6051А штатно идет 4М памяти. А физически ее там встроено аж 24М. И ее можно активировать с помощью ключа. Но опция эта стОит ого-го - 384 тонны рублей, т.е. дороже самого скопа (который где-то около 284 000). И вся могучая математика и программные фичи тоже уже есть. Я думал поначалу, почему фирмаваря такая толстая - аж почти 100 мегов. Потом как узнал про этот их подход, так сразу и понял: там ВСЕ УЖЕ ЕСТЬ. И это очень правильно и грамотно - апгрейд для фирмы и ее представительств упрощается до предела - не нужно дорогой, сложный и хрупкий девайс никуда возить для этого. Не нужно его вскрывать и лезть внутрь. И то, например, что память вся там уже есть, говорит о том, что в отличие от старых времен, когда память была действительно дорогой и ее было мало, сегодня эта память недорогая - настолько недорогая, что ее себестоимость почти ничего не вносит в стоимость всего прибора. И объемы стали неслабые. В последних моделях самых крутых Лекроев - WaveExpert - объем памяти доходит до 512 мегов! Подозреваю, что там сейчас ставят обычную DDR2 или QDR. Что касается доступа. К сожалению, тут ничего утешительного для нас нищих нет. Точно не знаю, т.к. про это помалкивают, но думаю, что анализ ключей, активация фич, запоминание ключей и т.д. возложено не на программу-приложение осциллографа, а на железо, которое представляет собой по отношению к встроенному компу обычное PCI устройство. Т.ч. просто так сломать как обычную программу будет крайне сложно. Единственный путь, если кто-нить, у кого есть, поделится генератором, что маловероятно, т.к. это владельцы, либо если есть ключи для одной модели, по ним сделать кейген. Но и тут, думаю, особо ждать нечего, т.к. вещи эти не массовые, а среди пользователей приборов умельцев таких мало. В любом случае, девайс просто рулез. Если хотите достойный иструмент, берите Лекрой - не прогадаете! Это не просто скоп, смотрелка сигналов - это гораздо больше - это, без преувеличения, целый измерительный комплекс!

с удивлением узнал что готовиться новая редакция стандарта VHDL пока рабочее название VHDL 200x :) <{POST_SNAPBACK}> Откуда инфа? Что там нового?

А на LeCroy не посмотрели? Зря. Вот зайдите сюда Оциллографы LeCroy Имхо, всяко не хуже хьюлетов.

А верно ли, что DXP2004sp4 не умеет расталкивать прводники при интерактивной трассировке? <{POST_SNAPBACK}> Умеет. Как и все предыдущие.

Там, afaik, нет задания отдельного пути для библиотеки. Нужно просто поместить исходный файл библиотеки в проект и все. Пути к файлам проекта прописываются, как обычно, в файле проекта (скриптик tcl'ный это).

Тоже рекомендую тектроникс. Можно подобрать по хорошей цене. И смотрите архив форума. Тут кто-то что-то похожее продавал с большой скидкой. <{POST_SNAPBACK}> Вот чего не рекомендую, так это Тектроникс. Если есть деньги на TDS-3032, то уж совершенно однозначно взять WaveSurfer WS-422 (432) от LeCroy! Кроет Тека по всем статьям, и вообще на голову выше и по качеству измерительного тракта, и по интрефейсу, и по возможностям софта. Еще альтернативу может составить Agilent с его MSO 6000-й серии. Но у них нет, насколько знаю, встроенного компа. Этих реально не видел, не шупал, конкретно сказать не могу. Но насчет Тек vs LeCroy - выбор однозначен. Если есть больше денег, то можно и постарше семейство посмотреть - WaveRunner, например.

Скока денег есть?

И что ето такое ? это бред сивой кобылы. Берется шим с частотой в 100 раз большей частоты дискретизации в нашем случае она будет равна 480 кГц. Потом раз в 1/48000 с заносятся новые параметры скважности (ваши 16 бит), итого мы имем на выходе 65535 значений напряжения (это в идеале на практике немного хуже). С 480кГц AVR справится на ура. <{POST_SNAPBACK}> И что, при этом будет 16-разрядный ШИМ? <{POST_SNAPBACK}> Именно !!! <{POST_SNAPBACK}> Либо Вы себе неправильно представляете, что такое 16-разнядный ШИМ, либо одно из двух. :) На всякий случай: обновление регистра, где прописывается значение скважности, производится не чаще, чем период ШИМ, иначе работа будет некорректной. Период 16-разрядного ШИМ - это период переполения 16-разрядного счетчика, т.е. 65536 тактов. Другими словами, в одном периоде выходного ШИМ должно быть 65536 периодов тактовой частоты. Если частота ШИМ 48 кГц, то частота тактовой в 65536 раз выше. О чем Вам выше и говорили.

И что ето такое ? это бред сивой кобылы. Берется шим с частотой в 100 раз большей частоты дискретизации в нашем случае она будет равна 480 кГц. Потом раз в 1/48000 с заносятся новые параметры скважности (ваши 16 бит), итого мы имем на выходе 65535 значений напряжения (это в идеале на практике немного хуже). С 480кГц AVR справится на ура. <{POST_SNAPBACK}> И что, при этом будет 16-разрядный ШИМ?

Атом - неделимый. Атомарность, соответственно, - "неделимость. В констексте ОС под атомарностью понимается ситуация, когда операция (фрагмент кода) не может быть прервана и управление отдано другому процессу (задаче). Имеет смысл в вытесняющих ОС. Например, когда надо, чтобы код выполнялся гарантировано без передачи управления, его можно поместить в критическую секцию - прерывания будут запрещены, все операции критической секции будут выполнятся одна за другой. В контексте процессоров понятие "атомарность" обычно применяется к инструкциям процессора. Например, в одном процессоре операция инкремента ячейки памяти делается одной инструкцией (хотя и за много тактов), а в другом это требует загрузки значения в регистр, инкремент регистра, сохранение ячейки обратно. Первая операция будет атомарной - ее нельзя прервать. Вторая - не атомарна, - если во время этой последовательности произойдет прерывание, где осуществляется доступ к инкрементируемой ячейке, то, скорее всего, будут коллизии в программе. Это, так сказать, смысл, который стоит за понятием "атомартность". В любом случае, имеется в виду, что при атоматной операции те или иные действия выполняются неразрывно.

Ясно, денег своих платить не хотят. А кто на приличной фирме работает, для того это не проблема - три тонны баксов окупаются на той же поддержке довольно быстро. Какие низкоуровневые операции переписывать? С чего переписывать?... В самом GCC никаких прикладных нестандартных вещей нет - это обычный программерский пакет, такой же как и IAR. Если кто-то для него написал библиотеку, так это другое дело. Для IAR тоже много чего написано. По большому счету, совершенно не важно, для какого пакета написан код, если он написан на С/С++ и написан грамотно. Наличие в CodeVision поддержки LCD для кого-то, возможно, и является значимым плюсом, но, имхо, это просто мелкая фенька. Гораздо важнее, что кодогенерация у IAR'а заметно лучше, и вообще фичи языка IAR поддерживает несравненно лучше - взять хотя бы ++, которых у CV вообще нет (и вряд ли появятся). К тому же лично, например, предпочитаю реализовывать подобные вещи сам - разобраться надо по-любому, а собственно реализация, когда уже знаешь, что к чему, много времени и сил не занимает. Прошу простить, но это звучит достаточно бредово. Пакет как таковой тут вообще роль играет довольно слабо. На первом месте всегда сложность прикладной задачи и квалификация разарботчика в предметной области. Это главное. На втором месте то, как разработчик владеет тем или иным инстуменатрием. Если привык к GCC, на нем сделаешь быстрее, чем на IAR', даже, если по всем признакам IAR рулит (другое дело, что в данной ситуации имеет смысл задуматься об освоении более подходящего инструмента)... И напоследок. Вот подумайте над такой вещью. Вот надо мне кольцевой буфер. Для байтов. Вот написал я его. А потом понадобилось то же самое для целых. Или для структур. На IAR'е я напишу шаблон: template<typename T, word size, typename S = byte> class ring_buffer { ... } и буду инстанцировать себе буфера: ring_buffer<char, 16> CharBuf; // колцевой буфер на 16 char ring_buffer<int, 8> IntBuf; // колцевой буфер на 8 интов IAR это позволяет. GCC тоже. А CV? И сколько нужно времени, чтобы переписывать для CV одно и то же? И надо ли? Т.ч. еще вопрос, откуда и что переписывать. И где на выходе результат быстрее получится.

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

Вы бы код привели лучше, мы бы сами посмотрели, чем гадать...

Кроме самого проца придется еще питание ему организовать и загрузку. И никакой внутрисхемной отладки. В упомянутом ките все уже есть сразу. Но согласен, что недешев, зараза. :( Флеши нет (и правильно, бо медленная она, флешь-то). Схема кита есть на сайте у производителя.

Ну а собственно говоря, почему в разы по сравнению с графическим вводом?? В чем уж такое большое преимущество текстового ввода теста? <{POST_SNAPBACK}> Потому, что при текстовом вводе на языке доступно, во-первых, поведенческое описание, во-вторых, можно легко описать логику обработки выходных сигналов синтезируемой части и генерировать входные сигналы в соответствии с логикой работы окружения, т.е. моделировать всю систему, а не только синтезируемую часть. Разница, как грицца, половая. :) Т.ч. мужчины правильно советуют.

АВРСтудия и постарше будет - с 1997 года (если не раньше) она идет и глюков в ней всегда было выше ушей, м.б. в последних версиях стало получше. Во-вторых, в студии нет С-комплятора. Не помню беслатных сред от производителей, где был бы в составе С-компилятор. Т.ч., имхо, сравнение не совсем корректно. :)

Работать-то будет. Оно ж всегда с запасиком делается. Более того, когда на телесисках это обсуждали, кто-то специально засунул несколько плат в камеру мороза на -40, все они работали. Т.ч. по факту оно работоспособно, но не гарантируется захват опорного клока, т.е. использовние ниже -20 градусов - не в режиме. :( А толку-то его менять? Ну сделаете, например 4, тогда это будет означать, что вы должны подать на вход 200*4=800 МГц, которые потом поделятся внутри на 4. То же самое, что и просто подать 200 МГц без последующего деления. Только 200 МГц - это, имхо, еще реально вполне, а вот 800 МГц по плате таскать - это я уже себе слабо представляю. :)

Значит, он не тестовый проект компиляет - в тестовом ключ --eec++ указан.

Значит готовых библиотек UART'a под ПЛИС нет? <{POST_SNAPBACK}> Их есть. Более того, описать простейший UART несложно и самому (во всяком случае я бы подумал, прежде чем остановиться на том или ином варианте - поиск подходящего готового, его верификация, поиск возможных глюков где-то сравним по времени и трудозатратам с написанием такого приемопередатчика самому). Тут в другом трудности возникнут - помимо передачи битов придется ведь протокол городить и всю логику, связанную с отправкой и приемом блоков, обработкой ошибок, таймаутов и прочего, поэтому логики там получится весьма... На МК такие вещи делаются на порядок проще. Поэтому des00 совершенно правильно посоветовал разбить задачу на две части - сбор возложить на ПЛИС, функциональность общения с хостом - на МК. Связь между ПЛИС и МК - через 4-проводной SPI, благо он архипрост. В любом случае связка ПЛИС+МК несравненно гибче и мощнее, нежели что-либо одно из них, и ее освоить, "обкатать" стОит в любом случае - не в этой задаче, так в следующей это обязательно пригодится.

:) ну называеться он так в документации :) capture compare module построен на основе счетчика, и кстати и длительность сигнала можно мерить на нем, просто нужно настроить его входной модуль на автозахват состояния счетчика по событию (восходящий и нисходящий фронт) и потом просто взять разницу :) хотя тут есть подводные камни. :) <{POST_SNAPBACK}> Э-э, не понял, причем тут вообще capture module (что это такое, я в курсе)? Речь шла о подсчете импульсов. Т.е. достаточно подать сигнал на счетный вход таймера/счетчика. Никакие фенки capture module (как то регистр захвата, noise canceler и прочее) тут не нужны. Более того, для подсчета импульсов можно использовать таймер, вообще не содержащий никаких capture модулей. Capture модуль - для засекания времянок, тут он не нужен никак. Что не так?

А что конкретно говорит? Вывод компилятора можно показать?

А, ну если только импульсы считать (а не засекать времена между ними), то, пожалуй, и прокатит. Меня сбило с толку упоминание про модуль захвата - модуль захвата используется для засекания временнОго положения перепада. А для подсчета он не нужен - таймер/счетчик в этом случае используется как счетчик - просто тупо считает импульсы. Емкость там весьма приличная - 65535, т.ч. достаточно раз в несколько сотен микросекунд считывать значение счетчика и все.