dxp

Знаю такое, как-то пользовался, но потом бросил. Глюкавая слишком. Работает не со всеми программами - для той же Оперы надо отдельную длл доить. И встроенныя в Протел фича работает лучше - мягче, естественнее, комфортнее. Имп по тактильности к не приближается, если поставить чувстительность на минимум (3%, afair). И все равно не дотягивает. Хотя согласен, что если такого вообще нет, то фича может оказаться кстати. Было бы очень неплохо, если бы можно было указать программы-исключения, т.е. те, в которых фича не активируется. Если бы это было возможно, я бы пользовался.

Достаточно весело ;О) А не подскажет ли уважаемый Дон, сколько периодов ОСЦ содержыт "1 такт" у АДСП-21-хх и у "других" контроллеров? То-то же. А у АВР - 1:1! Уважаемый Сеньйор должен помнить, что у АДСП-21хх любая команда выполняецца за один такт ОСЦ. Т.е. 40 МГц кварц (или внешний клок) дает 40 МИПС производительности - т.е. 40 миллионов честных апераций в секунду. И абращщение ф память - не исключение. То, что внутри растактовка на 4 идет, ничего не меняет. У AVR тоже внутри на 4 фазы побито, как они организуются - следующий вопрос (с ФАПЧем или на задержках). У АДСП - ФАПЧ. Но там и частоты недеццкие. При 8 МГц АДСП вполне бы без ФАПЧа мог абайтись. Кстате, PIC18 тоже за один такт ОСЦ успевает. И тоже с ФАПЧем. Это фсе детали реализацции. Если бы Вы сравнили кодогенераццийю упомнянотого MSP430 с оной обсуждаемого AVR, Вы бы без труда поняли, почему гарвардский AVR сливает фоннеймановскому MSP430 даже при работе с 8-битными данными. Именно из-за нее родимой - из-за ортогональности регистрового файла, когда нету ни одной операции пересылки между регистрами, чтобы сохранить или загрузить адрес - в каком регистре адрес пощщитали, с того и работаем. А в AVR пастаянна приходиццо туда-сюда адреса таскть из Z-поинтера и абратна в нево. Речь идет не а том, што без нее жыть нельззя, а а том, што без нейо хуже, чем с ней. Паэтаму ацсуцтвие артаганальности скорее несдостаток, нежели достоинство. А жыть, канешно, можно, можно ваапще без AVR'ов жить - жили же и ничего, не тужили. Это што за праграммы? На голом асме, што-ли? Не, на астме можно извращацца как угодно, только вот если кампилятором пользоваццо, то без r16:r31 не абайдетесь никак. Факт ф том, што без r0:r15 можной обойтись, а без r16:r31 - ну никак! Даже литерал не смогёте в регистор загрузить. Поэтому вопрос, какая половина нужнее, не стоИт ваапще - вопрос стоИт, насколько нужна эта нижняя половина, если вместо нее можно получить более полезную функциональность. Кстате, при испозьзовании вытесняющих RTOS количество регистров обратно пропроционально эффективности ОС, и таскать 16 бестолковых регистров там вопще некстате. И ещщо рас повторю - жыть можно, никто не говорил, што нельзя. Вапрос только ф том, как оно лутше. Свайё имхо я сказал. Ну зрасьте! Да просто скопировать кусок данных - нада два поинтера. Причем не в цыкле скопировать, а, например, несколько полей структуры/класса. А если у меня в классе массив есть и мне нужно к йево членам абращаццо? Тут получаецца, што в Z-поинтере лежит this, а адрес массива грузить некуда - X-поинтер не патходит - он не умейет со смещщением адресаваццо, Y-поинтер занят под указатель стэка. Што делаем? Пральна - сахраняйем значение Z-поинтера (указатель this), грузим в Z-пойинтер адрес массива, работаем, патом абратна вертаем this. И таких случаев ещщо есть, я не придумал это. На эту тему плотно абщалсцо с IAR'воской паддержкой, абсуждали стратегии register allocation, чтобы оверхеда было меньше. Весь гимаррой там из-за убогости системы регистов-указателей (мала их), усугубленной ацсуцтвием нармального указателя стека, штобы данные можено было им же манагить. И чо? Вы знаете кампилятор лучше, чем IAR для AVR? Упомянуная поддержка умножителя на плавучке - это вапще к камилятару атнашэния не имейет - это сугубо дело библиотеки, там все на астме написано. Если Вам оно так было нужно - напесали бы себе свою библу и вуаля. Сообщу еще тайну (тоже суппорт в свайо время раскалолся): разработчики компилятора (где кодогенерация, оптимизация и прочее) и библиотек - это несколько разные люди. Если в библе оно появилось поздно, это вопрос управления этим процессом - вопрос к EWAVR продукт манагеру. Этот вопрос я не задавал, мне оно без надобности было - в моих проектах плавучка и так успевала со свистом. А это тут причем? IAR'овские компиляторы далеко не лучшие для фсех платформ. К примеру, для того же старика 51-го IAR'овский кампилер всегда уступал и Кейлу, и Таскингу. Нащщет АРМа не скажу, мы щяс не йево апсуждаем. А для AVR IAR - лучший кампилер абъективно! Вапще, в чом вапрос-то? Просили недостаки азвучить. Что и сделано. Никто ж не утверждает, што AVR - аццтой. Нормальный, приличный МК. Идеального МК (как и фсего другого) нет, и, видимо, никагда не будет - у фсех фсегда что-то да не так. Ну и ладно. Но это не устраняет реальные абъективные недастаки AVR, што плохова, если аб этом будут знать те, кто еще сам не дошел, не столкнулся, не наступил и т.д.? Имхо, ничего плохого нет. Я, кстате, еще не фсе упомянул. Там в AVR еще пенок хватает. Например, эта их идея с оддельной областью IO. Ведь ясно же было, што кончицца она. И кончилась - вон на меге 128 начался гимарой, когда за адреса 0x60 вылезли. Канешно, жыть-то можно, только фсе равно геморрой. А то, что в битовоадресуему область поместили регистр данных АЦП! Это ж нада было до этого додумацца! Битами таймера рули по маскам, а биты данных АЦП доступны индивидуально! Цирк!! Но про такие мелочи я даже упоминать не стал, думал, перечисленного значимого достаточно... ашыпся выходит. В заключение, я нигде на AVR не наезжаю, сам долго с ним работал, если сейчас не работаю, то это просто тематика сменилась, AVR туда не катит. Я, в отличие от некоторых других участников форума, не считаю что AVR для радиолюбительских поделок, а не для серьезных промышленных (в том числе) изделий. Нормальный МК, достаточно поизводительный, достаточно простой и прозрачный, с достаточно богатой периферией, достаточно надежный. По крайней мере, почти по всем основным характеристикам не уступающий своим одноклассникам. Вполне достойное семейство для любых ембеддед применений.

Тот случай был в своем роде уникальным. Тогда был общемировой кризис, и трудности с поставками были у многих. Со 103-й мегой получилось следующее: основные объемы у фирмы Атмел (в те времена) занимало производство флеши. На флеши фирма и поднялась (а не на производстве флешовых 51-х МК), это ее основной доходный сегмент. AVR - детище Атмел, но второстепенная ветвь, не основной по доходности бизнес. Естественно, что когда наступил кризис, второстепенные направления пострадали больше всего. Кстати, флешь атмеловскую в те времена совершенно свободно покупали без каких-либо проблем. А из AVR больше всех пострадала именно мего103 - угадай, по какой причине? :) Пральна - потому, что флеши в ней много. Поэтому из всех приборов AVR именно мега103 и попала под основное сокращение - именно по ней были несуразные сроки поставки, - просто производство их было значительно сокращено. Остальные AVR'ки, кстати, мы брали безо всяких проблем, 103-и меги тогда не применяли, поэтому никаких последствий негативных не ощутили. Эк тебя запугали. :) Лично меня Атмел обманул только в одном - в самом начале были анонсировны 8515 с тактовой 20 МГц - мне это тогда оченно было надо. Но на поверку вышло, что 8 МГц и баста. В общем, не дождался я этого (да и ждал недолго), пришлось ПЛИСы осваивать для решения задачи, о чем, собсно, не жалею. :)

А почему? У фон Неймана только один недостаток перед Гарвардом - он в принципе медленнее, т.к. не может распареллелить обращения к данным и коду. Во всем остальном там все как минимум не хуже. И он проще и для понимания, и в работе. Простой пример - когда мне надо разместить константы в MSP430, я просто пишу const, и эти объекты попадают во флешь. На AVR так просто не пройдет - нужны уже расширения языка типа __flash. Особенно весело становится, когда надо использовать указатели на флешь - регулярно всплывают соответствующие вопросы. Скажете - мелочь. Может и мелочь. Но не всегда. Простой пример: в популятрой RTOS uCOS планировщик использует таблицу - массив const char [256] для быстрого нахождения наиболее приорететной задачи из готовых к выполнению. На фон неймановском MSP430 эта таблица молча ляжет во флешь, а на гарвардском AVR - в ОЗУ. И это при и так жеском дефиците ОЗУ. И 256 байт ОЗУ для AVR - это уже не мелочь. Можно и еще примеры найти. В итоге, фон неймановский проц как таковой в обращении ничем не хуже, он проще для понимания и логичнее. Ужаса там точно никакого нет. :)

Поругать? Это пожалуйста. :) Итак. AVR при всех прекрасных инновационных идеях очень пострадал в плане реализации. 1) Регистровый файл. У AVR слишком много регистров при том, что используются они бестолково. Например, они неортогональны - нижняя половина регистров не может использоваться так же как верхняя, из-за чего регистры с 16-го по 31-й используются гораздо чаще, чем с 0-го по 15-й. И это мягко сказано - реально верхняя половина используется чуть ли не в 90% случаев. Т.е. можно было бы отказаться от нижней половины, при этом бы появился хоть и небольшой, но ресурс для улучшения функциональности - большое количество регистров небесплатно дается. Далее. В сегменте r16:r31 тоже не все хорошо. Там не все регистры так же ортогональны - для адресной арифметики подходят только четыре верхних регистровых пары, а для адресации - только три из них. Причем и среди регистровых пар-указателей тоже отогональности нет - в итоге имеем не три указателя, а в лучшем случае два с половиной (Z, Y - полноценные, X - ущербный, у него нет очень важного режима адресации со смещением - этот режим адресации является, по сути, ключевым при используемой в AVR архитекитуре Load/Store). А в виду отсутствия нормального указателя стека (или отдельного фреймпоинтера) - об этом ниже, - остается только полтора указателя... Тут могут спросить: "А чего до этой отрогональности докопались, кому она мешает?" Ответ: ортогональность есть очень важный элемент, она очень сильно влияет на эффективность кода. Я как-то сравнивал оную эффективность между AVR и MSP430, ожидая, что уж на 8-битных-то данных AVR будет шустрее - гарвард как-никак. Ан нет, оказалось, что все далеко не так - у MSP430 как раз 12 РОН, которые полностью ортогональны - каждый из них может быть источинком данных, приемником, указателем для адресации данных и кода (когда функцию по адресу надо вызвать), т.е. обычная и адресная арифметика там совершенно прозрачны и после вычисления адресов не надо никуда ничего копировать, а можно прямо непосредственно работать с вычисленными адресами. В AVR, напротив, постоянно приходится копировать данные между Z-указателем и другими регистрами и на этом AVR в основном и "сливает". Будь у него все регистры с возможность образовывать регистровые пары, которые равнозначны и при вычислениях, и при адресации, все было бы гораздо веселей. 2) Указатель стека. Указатель стека у AVR (который SP) - просто убогий. SP совершенно не пригоден для работы с данными. Именно поэтому фирма IAR задействовала Y-указатель в качестве указателя стека (данных). Само по себе два стека есть неудобство, раз, и хоть и небольшой, но дополнительный расход ОЗУ, два. (Опять же, вспоминая MSP430, видно, что нормальный указатель стека прекрасно решает все задачи и по сохранению адресов возвратов, и по работе с данными). Но все весьма усугубляется тем, что указателей нормальных всего два - их и так почти нет, а тут еще один отдай! И из-за чего!??! Кстати, avr-gcc не использует Y-pointer как указатель стека данных, все базирует на SP, иногда только используя Y в качестве Frame Pointer'а, но в итоге эффективность кода (и по размеру, и по скорости) получается еще хуже, т.е. IAR выбрала правильный подход. 3) Работа с памятью. Работа с памятью у AVR непростительно медленная для Load/Store архитектуры - два такта на обращение. Т.е. непростительно много времени уходит на пересылку между регистрами и памятью, а пересылка эта является совершенно неотъемлемой частью процесса работы МК и занимает очень большую долю. Иными словами, персылка память-регистр и регистр-память в AVR должна занимать 1 такт! Как это сделано в других процессорах с Load/Store архитектурой (например, ADSP-21xx и др.). И технических проблем тут не просматривается - шина данных 8 бит, шина адресов 16-бит. Т.ч. чисто реализация. Итого, значительно лучший результат от AVR можно было бы ожидать будь у него не 32 теперешних регистра, а пусть 16, но образующих 8 регистровых пар-указателей полностью равнозначных, одна из которых образовывала бы указатель стека. Обращение в память за 1 такт. Такой AVR был бы раза в полтора-два быстрее сегодняшнего при той же тактовой. Все перечисленное является плодом незрелости фирмы Атмел как процессоростроителя, делай они AVR сегодня, уверен, всех бы этих косяков им удалось бы избежать. На протяжении всего развития этого семейства отчетливо видна тенденция на улучшение и ядра, и периферии, и электрических характеристик (чего стОил только косяк со слетанием EEPROM или отстутствие средств определить, какой был старт (холодный, теплый) в AT90S8515 - в 8535 уже все появилось). Т.е. производитель сам рос по ходу развития AVR, набирался опыта. Но сегодня паровоз уже несколько ушел, есть требования по совместимости, поэтому все эти несуразности были, есть и будут. К достоинствам AVR. Не буду повторять то, что уже сказали. Отмечу лишь, что очень важным и значимым достоинством этого МК является простота его освоения и использования. Это очень важный фактор, который на популярность влияет зачастую значительно больше, нежели фичи. Еще работая на прошлой работе, была у меня разработка 1998 года, с 1999 года она в серии на заводе до сих пор. Там стоял 90S8515. Сегодня там стоит мега8515. Заменили ее без моего участия (как основного разработчика), никаких трудностей не испытали. Это при том, что завод там савеццкий ВПКшный, дубовость там высшей пробы. И ничего - асилили без единого вопроса. Т.ч. проблема, имхо, несколько надумана. Реально проблема может возникнуть, если чип снимается с производтства и ничего на замену не предлагается. Но Атмел так никогда не делал.

Понятно. Такой вариант подходит, если нет требований по порядку нумерации. Но в случае с требованиями аля ГОСТ и нормоконтролем тут получается не радужно. Кстати, одной из значимых причин перехода с Оркада на Протел для меня была именно возможность аннотирования элементов по ГОСТ - сверху-вниз, слева-направо (по-китайски, то есть :) ) с возможностью автоматического внесения изменений в плату - реально экономит колоссальное количество времени и сил (с содроганием вспоминаю, как приходилось в случае добавления элемента сначала в Оркаде ручками переименовывать компоненты (тут есть пара приемов, один из них - с поворотом схемы на 90 градусов, аннотированием и обратным поворотом, когда схема большая, это очень экономит силы, время и нервы), а потом - самое нудное и гадкое, - в редакторе ПП (в Протеле то бишь в моем случае). Кстати, как дела с этим моментом (возможностью аннотировать по ГОСТ) обстоят в других пакетах? PCAD 200x? PADS 200x? WG200x (DC или DxDesigner)? Поделитесь инфой, кто знает?

И ничего не "съезжает"? Т.е., к примеру, добавили конденсатор, переаннотировали схему - некоторые позиционные по конденсаторам (C?) сдвинулись. Если теперь просто волюнтаристски запихнуть новый нетлист в плату, то будет куча ошибок, т.к. позиционные не соответствуют связям. Или что? Или Вы не производите переаннотирования?

А мы брали в первую очередь не из-за интерфейса, а из-за характеристик. Хотя и интерфейс в виде сенсорного экрана 800х600 тоже играл не последнюю роль. Но главное, имхо, все-таки - это хорошая АЦ часть, отличная система синхронизации и превосходные временнЫе характеристики, такие как перекос по каналам, джиттер сэмплинга. Во! Не сталкивались с этим ни разу. У нас один пока непобежденный глюк - прога выдает ошибку при создании новой записи в лабораторной записной книжке. Причем, не вываливается, можно продолжить работу - запись она создает, ее можно редактировать. Да и потребность в этой фиче довольно редкая - в основном скриншоты используются. В общем, не фатально. Какая у Вас версия фирмвари?

Это странно. Конечно, лучше, чем на ОУ с транзистором не получится, но ситуация должна была заметно улучшиться. Хотя если прикинуть, что 250 мкА при резисторе 1к даст всего 250 мВ, при падении на БЭ порядка 600-650 мВ, то глубина ОС просто получается маленькой. Сделайте хотя бы 1 В падения на резисторе ОС и эффект не замедлит проявиться. Вообще, все это можно смоделировать в спайсе. Там у транзистора есть такой коэффициент неидеальности, его можно варьировать. И можно будет конкретно увидеть вклад ОС на уменьшение разброса транзисторов. Было время, занимался этим вопросом, вполне пристойно сходилось. В общем, все это можно сделать. Если ради интереса. Потому что, как уже было сказано, вариант на ОУ и полевике лучше во всех смыслах. Два корпуса счетверенных полевиков, 4 копруса сдвоенных транзисторов, 8 резисторов (или сборка). Вот и все.

Какие трудности Вы там обнаружили? По-моему, все более, чем просто и прозрачно. Очень удобный и продуманный интерфейс.

Не измерял - это Квартус позволяет задавать в свойствах мегафункции ФАПЧ. И в симуляторе (на времянках) это отследил - точно так и есть. До железяки дело пока недошло (через пару месяцев должно дойти), там и проверим, для этого есть резвый цифровой скоп. Только с чего там погрешности-то взяться? Только некоторый разброс задержки от триггера элемента ввода-вывода до пина. А он не долен быть большим. Вот заодно и узнаем, как оно на самом деле. :)

Ничего определенного сказать не могу. Проект некоммерческий, делается в свободное время, которого что-то все меньше и меньше. :( Пока в планах две задумки, одна - в связи с появлением __raw в EWAVR, другая помасштабнее (подробности не хочу пока раскрывать, связано с механизмом перепланировки). В скором времени подойдет работа с процом, на ней и обкатаю. Что касается отладки, то не очень понимаю, что там нужно. Вещица очень простая, прозрачная, чего там, собсно, отлаживать. Если только написать монитор, к нему интерфейс и ГУИ на ПК, чтобы смотреть загрузку процессов... Не знаю, такая работа сама по себе достаточно трудоемка, а смысла в ней большого, имхо, нет. К тому же, такой монитор внесет тормозов, во всяком случае его оверхед будет соизмерим с оверхедом самой RTOS. Поскольку главный смысл этой RTOS - получить максимальное быстродействие при минимальных накладных расходах (а также максимальную простоту использования), то любая сколько-нибудь посторонняя фишка в той или иной степени нивелирует эту самую основную идею. Т.ч., исходя из перечисленных причин, даже не задумывался об каких-то специальных средствах отладки.

:) Я Вас тоже смог идентифицировать только после того, как Вы у меня сорцы библиотек из EWAVR 4.хх спросили (у меня не оказалось), а потом этот же вопрос на форуме задали. Тут-то я и сообразил, кто у нас модератор. :)

:) Вам бы аналитиком в контрразведке работать. Ни один шпион бы мимо не прошел. :)

То, что есть, без сомнений. Вопрос, насколько это доставабельно. Все-таки по используемости (и, как следствие, доставабельности) такие вещи не сравнятся с операционниками и обычными транзисторами. Да, параметры не чемпионские и других проблем хватает. Любопытный вариант :), но зачем такие извраты, когда все можно сделать на недорогом прецизионном ОУ, мелком MOSFET'е и прецизионном резисторе. Это многократно проще, повторяемее, точнее и стабильнее. Все компоненты можно брать по нескольку штук в корпусе, тогда и самих компонентов будет меньше, чем каналов.

Знакомо. Тоже долго на Оркаде сидел - как познакомился еще с досовых версий 3, так через SDT 4, потом на виндовые 6.х, 7.х, 9.1. И тоже не мог слезть - привычка, казалось, что это лучший схемный редактор. Но сегодня, работая в Протеле, периодически пользуюсь Оркадовским схематиком (для Спайса), и он так "ломает". :( Очень не хватает возможности настроить хоткеи. Очень не хватает возможности двигать схему, зажав правую кнопу мышки. А уж глобальный поиск и редактирование вообще ни в какое сравнение не идет. То же самое касается и навигации. В общем, я бы не был так категоричен. Оркад в свое время был на гребне среди аналогичных продуктов для PC. И то, что он одним из первых вышел на винду - это был просто рывок: новый удобный интерфейс, новая идеология построения проекта. К сожалению, с тех пор он не очень развивался, интерфейс и возможности остались почти на том же уровне. Самое значимое приобретение - это микросимовский спайс. Не знаю, как он сейчас в составе Каденса равивается, но что-то сомнительно, что там что-то кардинально изменилось. Периодически слышно, как народ ругает 10.хх версии, говоря, что вот в 9.хх все стабильно работало. В общем, все течет, все изменяется, надо следить за этим и корректировать свой путь. :)

Это ключевое слово было введено изначально только в пакет EW430 исключительно по личной просьбе. До него в версиях пакета до 2.20 включительно эту функциональность выполняло сочетание __task __interrupt (выглядит забавно-шокирующе, но работало), в дальнейшем в версии 2.21 такое сочетание было запрещено по идеологическим причинам (что, в общем, правильно). Но поскольку потребность в выполняемой ими функциональности никуда не делась, то в версиях 3.хх появилось новое слово __raw (еще рассматривался вариант __naked, как в ГНУтых компиляторах, но IAR'овцы открестились от него - gcc наиболее серьезный конкурент их продуктам). Такова вкратце история появления оного ключевого слова. Поскольку все это шло в контексте EW430, то неудивительно, что в пакетах под другие платформы такого слова нет. Возможно, это только временно. Я ожидал, что в EWAVR 4.10А это появится. Не появилось. Поэтому и удивился, когда сказали, что в 4.11[2] появилось. Видать, осознали. :) Т.ч. может и для АРМов тоже со временем появится. Хотя не факт. Хм, это странно. Такое слово было всегда. Сначала оно называлось C_task. Потом __C_task. Потом привели к общему виду __task. Смысл в нем был, есть и будет всегда. Странно, если EWARM этого не имеет. Может оно там просто по-другому называется?

Ну, а чем не канает вариант с ОУ и транзистором? Делаете 8 каналов, подаете на все каналы одну и ту же опору, они Вам выдадут одинаковый ток (или разный - если надо). Точность будет определяться точностью резисторов - датчиков тока (которые в эмиттере транзистора, с которых ОС берется на ОУ) и смещением ОУ. Это уже совсем не проблема. Имхо, этот вариант намного более реальный.

Пропускание тока, очевидно, и уменьшение падения. Какой результирующий ток требуется?

Характеристики можно улучшить, если добавить местную ОС - резисторы в эмиттеры транзисторов. Чем глубже ОС (больше падение на резисторе по отношению к Uбэ), тем лучше точность. Самое правильное - использовать не дискретные транзисторы, а сборки, и не просто сборки, а сборки согласованных транзисторов - так называемые matched transistors, т.е. сборки, у которых нормированы "разногласия" между отдельными транзисторами. :) Бывают очень хорошие сборки - к примеру, АДшный MAT04 (если название не путаю) обещал, что у него разброс Uбэ (на 1 мА кажется) не более 40 мкВ. Правда, там только два транзистора и корпус здоровенный. Вообще, найти такие вещи сегодня непросто - сборки есть, но насчет согласованности обычно ничего не приводят, т.е. просто сборки. Они, конечно, лучше дискретных тразнисторов - все же как-никак в едином технологическом цикле сделаны, на одной подложке, т.е. температурный режим похож, но все-таки никто ничего там не обещал. Все зависит от той точности, какая Вам нужна. Возможно, сочетание использования сборки и местной ОС даст удовлетворительный результат. А найти согласованные транзисторы сегодня сложно, имхо, потому, что спроса на них почти нет - где требуется прецизионность, там просто используют прецизионные ОУ и прочее хозяйство. В чистом виде прецизионное токовое зеркало мало на сегодняшний день мало кому нужно. Возмножно, есть смысл поискать прямо готовые токовые зеркала - скажем, Бурые Брауны (еще в бытность свою, сейчас все это хозяйство у ТИ) делали такую вещь как REF200 (опять же если не путаю название, давно было, а лезть смотреть немного лень :)), там в одной микрухе 8-ногой более-менее прецизионный истончик тока и токовое зеркало. Возможно, если обрисуете задачу более подробно, удастся что-то более дельное посоветовать.

Неа, на выходе будет постоянный уровень --- 1 или 0, в зависимости от того, какой клок куда завести. Точно - прогнал! :) У меня не так было: нужен был клок 100 МГц, задержанный от данных, сгенерил на ФАПЧе два клока 100 МГц и 200 МГц со сдвигом (200 МГц задержан относительно 100 МГц). 100 МГц - системый клок, а двухсотмегагерцовым тактировал тот I/O триггер, через который клок наружу шел. Задержка четко была, как заказано (где-то порядка 1.7 нс). Т.е. если честно делать синхронный дизайн, то, похоже, без более скоростного клока не обойтись.

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

Не обязательно. Если есть возможность сгенерить сдвинутые клоки, то задержанным можно тактировать опережающий. Например, в некотороых альтеровских ПЛИС есть модуль ФАПЧ, который может выдавать две частоты, причем сдвиг фазы можно задавать в широких пределах и с неплохой дискретностью. Таким обрзом, скажем, можно соорудить два сдвинутых клока на 100 МГц, первый завести на входы триггеров элементов ввода-вывода, а второй - на тактовые входы этих триггеров. На выходе сигналы будут синхронны и синфазны. Посмотрите, имеется ли у Вас возможность сгенерить такие сдвинутые клоки, если имеется, то вуаля. :)

А что в EWAVR тоже __raw включили? В 4.10А я специально смотрел, не было там (не нашел ни в доке, ни в перечне ключей компилятора).

Чудеса рассказываете! :) Не должно ничего с ним случиться - фирма даже рекомендует оставлять при выключении жало неочищенным и незалуженным, чтобы оно не окислялось. Потом при включении надо просто его (после того, как нагреется) повозить по мокрой губке, которая в подставке (воды тута налить предварительно), жало должно очиститься. Тогда его можно залудить. Этот процесс можно повторить несколько раз. В крайнем случае можно попробовать аккуратно почисить чем-нибудь твердым, но не абразивным - например, тыльной стороной скальпеля. Я однажды выпачкал жало в какой-то органической фигне (то ли изоляция, то ли еще какая-то фигня), тоже об губку не мог очистить, просто соскоблил, потом о губку, потом залудил, все стало ок. Хотя, если Вы его перекалили, то тут фиг его знает, такого опыта не имею. Но это, имхо, маловероятно - жало качественное, долговечное.