AVR vs PIC

2-Aug-04 15:27 George Shepelev wrote to Maxim Polyanskiy:

GS>>>> состояния линии 1 порта 0 на линию 2 порта 1: GS>>>> MOV C,P0+1 GS>>>> MOV P1+2,C OR>>> Ой, а нельзя ли для меня, тупого, уточнить - в каких таких OR>>> клонах MCS51 этот кусочек кода выполняется за ДВА цикла? OR>>> Hасколько я знаю, в MP>> Странно что тебя не смущаеют плюсы вместо точки, которые означают ну MP>> совсем другую опцию ;)

GS> Давай не будем обсуждать _синтаксис_ _конкретного_ компилятора, да?

Да не будем, не будем. Я уже когда отправил ответ на это - подумал, что по сути MCS51-й архитектуры setb P3+1 *должен* жрать *любой* ассемблер для неё.

Но действительно выглядит непривычно по сравнению с каноническим (и жрущимся и 2500 A.D., и Avocet-ом, и keil-ом) setb P3.1 Интересно, есть ли какой-то *приличный* ассемблер для MCS51, который не понимает P3.1 ? В смысле неужели в ассемблере с богатыми возможностями имеет смысл экономить на коде разбора и всё равно необходимую addr+const делать, а addr.const не делать?

А в привычке писать P2+offset есть свои плюсы :-) setb P2+15 clr P0+11 и пусть кто не помнит наизусть всю таблицу SFR 51-го разбирается :-)

Привет!

Прошу прощения за длительные паузы.

Wed Jul 28 2004 12:24, Harry Zhurov wrote to Alexander Golov:

...

AG>>>> Я, по-моему, прямо сказал, что его DSP Engine не рассматриваю. AG>>>> dsPIC30F как раз очень хорош как универсальный МК,

HZ>>> А как у него с потреблением и ценой? Ведь этот DSP Engine - не HZ>>> бесплатная вещь. Он и место на кристалле занимает (цена), и энергию HZ>>> жрет, причем из-за своей толщины весьма приличную.

...

HZ>>> В итоге потребление на полной скорости в полтораста мА

AG>> Это не правда. Hапример, для 2010 типовое потребление при 30 MIPS и 5 В AG>> -- 67 мА. Широкий диапазон рабочих напряжений даёт место для манёвра, AG>> например, при 20 MIPS и 3,3 В потребление лишь 26 мА. При 10 MIPS он AG>> потребляет лишь немногим больше чем PIC18. (Для упоминавшегося ниже 5011 AG>> эти параметры на данный момент TBD и оценить их заочно невозможно.)

HZ> Hе знаю, откуда ты взял эти данные.

Из даташита на dsPIC30F2010 (DS70118C).

HZ> Я вот смотрю даташит (70083F.PDF), там таблицы приведены. HZ> Из 23-1 следует, что на при 3.3 В HZ> максимальная производительность вообще 15 МИПС!

У 2010-30I -- 30 МГц от 4,5 В, 20 МГц от 3,0 В и 10 МГЦ от 2,5 В. На самом деле все даташиты "Preliminary", нужно ждать когда ляпы поправят и заполнят все клетки таблиц. В реальности же, так как имеет место противоречивая информация, нужно всё проверить. Как только я смогу дотянуться до того же 2010 я залью в него несколько тестов и проверю потребление. О результатах расскажу.

...

HZ>>> и цена среднего кристалла (5011) в розницу (Digi-Key) под два HZ>>> десятка баксов.

AG>> В реальности там со склада доступны лишь несколько моделей (6014 и т.п.) AG>> по цене около $30...

...

HZ> Именно. Когда Атмел толкал АВРы, цены он предлагал очень приемлемые, HZ> хотя, как говорили на семинарах, делал это чуть ли не в ущерб себе - HZ> стремился влезть на рынок, переманить потребителя. В случае с дсПИКами HZ> Микрочип, похоже, сделать этого не может. Интересно, на что он HZ> рассчитывает, предлагая кристаллы по 30 баксов в той нише, где существует HZ> уже масса альтернативных решений?

Да причём тут Microchip? Это Digi-Key химичит. Зайди на Mouser, там со склада по 1 шт. предлагаются 2010 за $6...7 (в зависимости от исполнения), а самый жирный -- 6014 за $17...20.

HZ>>> В итоге в нише AVR/PIC/MSP430 по этим (важнейшим) показателям он не HZ>>> конкурент,

AG>> Пожалуй единственное чем упоминаемые выше семейства могут конкурировать AG>> с dsPIC30F на скоростных задачах это цена (и то это не факт). Hо AG>> большинство задач которые 30-му вполне по плечу для остальных не AG>> оставляют никаких шансов.

HZ> Hе забывай про потребление! В очень многих случаях 20 МГц АВР вполне HZ> рулит.

Есть задачи (в частности у меня в данный момент) где упоминаемые выше не рулят. Например, при 2,5 В и 10 MIPS потребление 2010 скорее всего не более 11 мА (14,3 мА при 3,3 В). При этом никто из вышеупомянутых не способен обеспечить 10 MIPS при питании до 3,0 В (и тем более 20 MIPS до 3,6 В), не говоря уж от том, что "вес" их MIPS'а существенно ниже чем у dsPIC30F.

HZ> А уж где не требуется высокая тактовая, то с МСП дсПИКам по потреблению и HZ> близко не стоять.

Там где не нужна относительно высокая производительность dsPIC30F вообще делать нечего, у той же Microchip для этого есть куча других МК различных ценовых категорий.

HZ>>> а в нише тех, кто более ровня, он до многих недотягивает так HZ>>> же по основным показателям, таким как производительность да и HZ>>> периферийные навороты. Hапример, TMS320F2810 по производительности HZ>>> имеет dsPIC без вопросов в разы (!),

AG>> При впятеро больше частоте?

HZ> Hасколько я понял, дсПИК имеет тактовую 120 МГц и она делится HZ> вчетверо, образуя машинный цикл? Вот это действительно атрибут ПИКа.

Давай мы раз и на всегда договоримся не толочь эту воду в ступе про 120 МГц у dsPIC30F. У него ядро тактуется 30 МГц максимум, а что там происходит внутри и что на что делится, это его внутреннее дело. Частота x4 нигде в dsPIC30F не присутствует даже в периферии (в отличие от тех же PIC18 у которых ей тактуется UART, или ШИМ) и её даже нельзя подать снаружи (по крайней мере именно 120 МГц).

HZ> Разница в том, что ТМС не делит эту частоту, а с помощью конвейера HZ> стремится использовать каждый такт. Отсюда и производительность

Глубокий конвейер штука коварная. Он может обеспечить высочайшую пиковую производительность, но он же и здорово тормозит при переходах и ожиданиях завершения предыдущих команд.

AG>> Скорее всего так, во всяком случае на вычислительных задачах.

HZ> Да уж всяко. :) Особенно, если учесть, что он 32-х разрядный.

Но 32-разрядные вычисления не вполне типичная задача для МК. По мне и

16-разрядность dsPIC30F в отрыве от адресной арифметики вещь далеко не первой необходимости, а в 32-разрядной арифметике в МК в отрыве от ЦОС-применений смысла не вижу вообще. Зато бросается в глаза очень бедная функциональность при работе с 8-разрядными данными в TMS320F2810.

AG>> Hаверное это отличный DSP (я в этом слабо разбираюсь), AG>> но это не очень хороший универсальный МК.

HZ> А вот батоны по ЦОС считают его, как раз, посредственным DSP в HZ> сравнении с тем же C55xx или блэкфином, а как МК он котируется. Сама ТИ HZ> (на семинаре) заявляла, что управляющий (МКшный) код на нем не хуже, чем HZ> на таком стройном МК, как АРМ7 (там приводилась какая-то ссылка на некий HZ> тест на эффективность МКшного кода, на котором АРМы и проверяют. Точнее HZ> не скажу, давно это было, а я тогда особенно внимания на такие вещи не HZ> обращал). Hо сравнивая архитектурные фичи с традиционно МКшными, могу HZ> сказать, что такие заявления не лишены оснований - 6 штук широких шин, HZ> богатые средства косвенной адресации со смещениями, пре- и HZ> постинкрементом, адресация памяти за один цикл - все это рулит.

Там не всё так идеально. Скажем конвейер не позволит за 1 цикл в соседних командах записать, а потом прочитать что-то из памяти. Придётся ждать дополнительно 3 цикла. Такие же проблемы встречаются и при некоторых операциях с регистрами. В адресации, разочаровывают слишком скромные возможности прямой адресации и двухадресных операций память-память.

AG>> Огромный конвейер делает из переходов муки,

HZ> Да нет там никаких мук! Уже не более, чем на дсПИКе - ты забываешь, HZ> что одноцикловость дсПИКа базируется на четырех циклах тактовой. Реально HZ> условные переходы у Ф28 бывают 4/2 цикла, 4/4, самый длинный - 7/4.

Давай разберёмся что там к чему. 4/2 это переходы по содержимому регистров. Переходы по флажкам обязаны дожидаться завершения предыдущих команд, поэтому имеем жёстко удлинённый 7/4. И наконец "быстрые" варианты условных переходов заранее производящие выборку команд в конвейер по обеим веткам.

Причём всё выглядит так, только если код выполняется из ОЗУ, или при тактовой не более 25 МГц. В случае работы с Flash при пересечении границы страницы из

128 слов мы имеем дополнительный wait-state в 5 циклов при 150 МГц. Это означает увеличение перехода 4/2 до 9/2, перехода 7/4 до 12/4, а перехода 4/4, как я понимаю, аж до 14/14 (нужно ведь выбирать обе ветки, а это чистой воды "Random access" выполненный дважды).

Выглядит это весьма грустно. 30 MIPS dsPIC30F может выполнить 15 млн. переходов любого вида из любого состояния, 150 MIPS TMS320F2810 в лучшем случае 37,5 млн. (4), в среднем 21,4 (7), а в худшем 10,7 (14).

AG>> у него не слишком быстрый доступ к портам

HZ> Поскольку порты у него замаплены на память, к которой доступ HZ> осуществляется за один такт, то я бы так не говорил. Единственный момент HZ> - из-за конвейера запись в порт происходит не непосредственно в цикле HZ> обращения к нему, а с задержкой в два или три цикла (точнее не помню). HZ> Если взять Ф28 и дсПИК при одинаковой тактовой 120 МГц (больше дсПИК, HZ> вроде, не может), то время обращения к порту у первого будет не хуже уж HZ> точно.

Основная масса периферии лежит во фреймах 1 и 2 для которых фиксированно определены 2 цикла ожидания как раз при чтении. Потом не нужно забывать, что прямая адресация основной массы команд это всего 64 слова, а значит в большинстве случаев обращение к порту сопровождается префиксной командой загрузки DP. Т.е. скажем установка бита составит не менее 3 циклов, а скорее всего 4, причём если этот же порт понадобится следующей команде, ей придётся ждать ещё 3 дополнительных цикла.

AG>> и повышенные накладные расходы на обработку прерываний, AG>> запреты/разрешения

HZ> Из накладных я бы отнес только сброс конвейера, что влечет за собой 8 HZ> циклов, пока он полностью за заполнится. Это два дсПИКовых цикла. HZ> Остальное - полезные действия по частичному сохранению контекста, которое HZ> он делает несколькими 32-разрядными (!) копированиями.

В TMS320F2810 мы имеем прямые накладные расходы в виде 16 циклов на вход и выход из прерываний. Автоматическое сохранение 8-ми регистров это конечно хорошо, но если нужно было сохранить лишь 1, зачем ждать лишние циклы?

Но важнее другое -- это довольно большая и трудновычислимая задержка прерывания. Во-первых, нужно завершить весь конвейер, а это может потянуть циклов на 10 (достоверно я это выяснить не смог, TI крайне скупо описывает процесс выполнения прерываний), нужно сделать выборки вектора и страница обработчика, а это, если они не в ОЗУ, потребует по 5 дополнительных wait-state'ов.

Далее, насколько я понял, нормальной приоритетной системы у 2810 нет, нужно явно разрешать прерывания в обработчике, а значит часть оверхеда низкоприоритетного обработчика будет суммироваться с оверхедом высокоприоритетного. Ну и наконец непрерываемость REPEAT'а может растянуть задержку, на насколько сотен циклов, а как я понял именно REPEAT позволяет достигнуть максимум производительности различных MAC'ов.

dsPIC30F из любого положения через 4 цикла после запроса начинает выполнять обработчик (максимум 5, но это очень редкая ситуация и её нетрудно избежать, если необходимо), при этом сохранён STATUS. Приоритеты сделаны по честному через STATUS. Возврат -- 3 цикла, итого весь оверхед 7...8 циклов. На каждое дополнительное сохранение/восстановление + 2 цикла. Очень гибкий и предсказуемый механизм, какой и нужен для МК.

...

AG>> Я не изучал конкретно 28x, но ранее примерялся к 24x и сравнение с ним AG>> dsPIC30F было подавляющим (в те самые разы при равной частоте). Я AG>> понимаю, что 28x это не 24x, что у него многие многоцикловые команды AG>> 24x стали одноцикловыми, но ведь есть и обратные примеры (прежде всего AG>> переходы). При этом, факт, он не делает ничего быстрее чем dsPIC30F,

HZ> ??? А работа с памятью (а значит и с портами)? Если пересчитывать на HZ> тактовую (что и имеет значение на деле, т.к. именно тактовая и определяет HZ> соотношение производительность/потребление), а не на машинные циклы, то HZ> Ф28 почти во всем быстрее!

Иногда он может отстать даже по абсолютным показателям. Например, при последовательном выполнении операций над отдельными линиями порта в лучшем случае изменение состояния будет происходить раз в 6 циклов, т.е. 25 млн./с, а dsPIC30F может это делать 30 млн./с. При одинаковой тактовой между ними уже будет целая пропасть.

...

AG>> но многое делает медленнее

HZ> Hапример, что при одинаковой тактовой (в 120 МГц)?

При одинаковой -- 30 МГц.

...

...

HZ>>> сотен мА (при меньшей скорости, ессно, потребление пропорционально HZ>>> меньше).

AG>> Мои глаза мне говорят, что всё не так радужно. Во-первых, 2810 это AG>> 128-ногий монстр с шагом выводов 0,4 мм (ещё та прелесть!),

HZ> По мне что шаг 0.5, что 0.4 - один хрен мелко. А размер маленький, HZ> это хорошо.

Ну нет. Даже переход от 0,65 к 0,5 уже крайне неприятен для ручного монтажа, связываться же с 0,4 у меня вообще не никакого желания. А маленькие корпуса это 6-миллиметровые 28-ногие MLF, ну максимум 8-миллиметровые 44-ногие.

AG>> Во-вторых, с потреблением у 2810, мягко говоря, дела обстоят по хуже чем AG>> ты тут нарисовал. При том, что ядро питается очень низким напряжением AG>> (1,9 В) _суммарное_ типовое потребление при 150 МГц немногим меньше 300 AG>> мА (по графику что-то около 280 мА).

HZ> Да, там приведено максимальное потребление, когда ядро маслает на HZ> полной скорости с использованием своего 32-разрядного умножителя, когда HZ> периферия работает также на максимальной скорости (все ШИМы, которых там HZ> аж 12 штук, выдают по 100 кГц, когда оба УАРТа и КАH непрерывно передают

100 кГц для полутора десятков линий 150 МГц МК это на уровне 1% потребления. Скорее всего там немалое "статическое" потребление и если частоту, снизить скажем до 1 кГц потребление заметно не изменится. Радикальный способ -- полное отключение модуля.

HZ> и принимают, когда включен АЦП (у которого тоже не каких-то 100 HZ> киловыборок, а аж 12.5 мега), а то еще 40 мА).

Потребление АЦП практически не изменяется с ростом тактовой частоты, значит это потребление аналоговых узлов. Получается за работу на необходимых мне

500...1000 кГц я должен всегда "платить" 40 мА?

HZ> Периферия ввода-вывода, работающая на полной скорости, дает еще 10-20 мА. HZ> Hу, и флешь, когда она HZ> включена (когда программа исполняется из нее или пишет в нее), жрет еще HZ> около 40 мА. Кстати, в ряде случаев можно код скопировать в ОЗУ, которого HZ> там немало, и работать из него. Это даст экономию в эти 40 мА и HZ> увеличение производительности в полтора раза (при максимальной скорости).

HZ> Интересно знать, при каких условиях Микрочип дает значения HZ> потребления? Что-то мне подсказывает, что это далеко не на полной HZ> загрузке всех своих составных частей.

Собственно информации о реальной загрузке 2810 для приведённых условий у нас тоже нет, может там ядро 70% времени стоит в ожидании Flash? Уровень загрузки периферии (кроме ШИМов) тоже никак не отражён.

AG>> При тактовой частоте 30 МГц потребление по графику более 100 мА (около AG>> 115 мА),

HZ> Ядро при 30 МГц потребляет 50 мА, остальная добавка - это, в HZ> основном, потребление аналоговой части (АЦП), ну, и, как уже сказано, HZ> периферия маслает на полной скорости.

HZ> Кроме того, если уж говорить про энергопотребление, то надо не ток HZ> считать, а мощность. А 150mА * 5V = 750 mW дсПИКа против (считаю по HZ> самому максимуму, включая все - и ввод/вывод, и флешь, и аналог) HZ> 1.9V*195mА + 3.3V*15mA + 3.3V*40mA + 3.3V*40mA = 684 mW. Т.е. при питании HZ> от батареи с учетом КПД преобразователей где-то под 750 мВт и выйдет.

(КПД больше 90% для преобразователей 3 В -> 1,9 В при выходной мощности 400 мВт? Это нужно очень постараться...)

Я рассчитываю на 90 мВт при 3,3 В и 20 MIPS на dsPIC30F2010. Практическим минимумом для 2810 можно считать 400 мВт.

...

AG>> (по моим прикидкам производительность 30 МГц 2810 на характерных AG>> для универсального МК задачах вряд ли будет больше чем у 20 МГц AG>> dsPIC30F). Для 30 МГц dsPIC30F2010 и питании 5 В, разрыв, конечно, AG>> будет меньше, но всё равно стоимость производительности в пересчёте на AG>> ток будет вдвое меньше.

HZ> А не надо его гонять на низких тактовых, у него при понижении HZ> тактовой понижение потребления непропорциональное. Поэтому 30 МИПСовый HZ> (120 МГц) дсПИК надо сравнивать с 120 МГц Ф28. Если брать кристалл со HZ> сравнимыми характеристиками, то потребление у них будет похожим, а вот по HZ> производительности разница составит в разы даже не на ЦОС операциях.

Как не считай потребление 20 MIPS dsPIC30F2010 и любого реального варианта тактирования 2810 не будут соизмеримы. Если же я не буду снижать производительность МК до достаточного уровня, выгадывая в потребляемой мощности, то задача не будет решена: батарейка CR123A от которой питается мой прибор через несколько минут постоянного потребления 750 мВт, просто взорвётся.

HZ> Вообще, тут следует сказать следующее: оба девайса не попадают в HZ> разряд мелкопотребляющих, и если нет возможности широко использовать HZ> режимы микропотребления, то оба почти не годятся в приборы с батарейным HZ> питанием - тут младшие (АВРы/ПИКи/МСПшники) рулят.

Я не вижу никаких причин не позволяющих мне широко использовать режимы микропотребления у dsPIC30F.

HZ> А раз так, и питание HZ> неавтономное, то большой разницы 100-150 или 200 мА нет, и на первый план HZ> выходят другие факторы вроде цены, требуемой производительности, HZ> соответствия периферии, габаритов, сложности разработки и проч.

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

...

HZ> Мое мнение: Ф28 в значительной мере накрывает старшую часть семейства HZ> дсПИКов и по цене, и по потреблению, и по производительности. У него при HZ> необходимости можно использовать внешнюю память - шина для этого имеется. HZ> А у дсПИКов можно снаружи память прикрутить?

HZ> У младших ситуация намного лучше, но тоже не все радужно. В их нише HZ> есть, например, АДшные ADMCF, которые вполне соответствуют им по МИПсам HZ> (а уж МИПСы-то у них что надо - все до одного одноцикловые).

При работе из Flash? Никаких шансов, он не может делать больше одной выборки за цикл из Flash. А значит, да здравствуют простои, прощай одноцикловые переходы... Всё видимое быстродействие кода AD21xx базируется на исполнение кода из скоростного ОЗУ. Разве что AD станет делать под Flash полноразмерную подкладку из ОЗУ, но сколько это будет стоить...

HZ> Хотя АД не HZ> толкает это семейство как МК - позиционирует исключительно, как для HZ> Motion Control. А зря, имхо. Из них можно было бы сделать весьма машинку, HZ> уж не хуже дсПИКов точно! И по корпусам оно соответствует младшим HZ> дсПИКам.

Разглядывание несвязанного с DSP кода ("Software UART" из "Using the ADSP-2100 Family Volume 2") позволяет усомниться в данном утверждении даже без учёта замедления при работе с Flash. Особо впечатляют 3-командные декременты или сдвиги переменных. Бросается в глаза полное отсутствие поддержки 8-разрядных операций.

HZ> Кроме того, есть, к примеру, у Сигнала на однотактовом 51-м ядре HZ> линейка процессоров с очень приличной периферией и производительностью - HZ> уж по маханию ножками дсПИКам за ними не угнаться.

Ну если на нём зациклить команду CPL, то да, он обгонит dsPIC30F. Но уже в простейшем цикле выдачи N периодов частоты он отстанет. И чем больше будет усложняться цикл, чем больше в нём будет проверок и различных (простейших) манипуляций данными тем больше будет отставание. А если вспомнить сколь скромны возможности 51-го ядра в адресации, можно сказать, что на задачах, для которых обычно выбирают МК с 8 КБ ОЗУ и 128 КБ Flash, неизбежны активные манипуляции банками или указателями и отставание станет очень большим.

HZ> И в остальном (если не HZ> учитывать, как ты хочешь, ЦОС фичи) они выглядят привлекательнее - и по HZ> потреблению, и по цене, хотя и не дешевые.

По-моему, 25 мА при 2,7 В и 50 МГц для C8051F120 не говорит в пользу последнего при сравнении с тем же 2010 при 20 МГц и 3,3 В. Цена насколько я знаю тоже не кажется привлекательной.

HZ> У дсПИКов есть одно существенное преимущество - он проще значительно, HZ> его проще освоить, проще использовать. Кому это критично, тот HZ> потенциальный их пользователь.

Почему бы и нет. Фактор, кстати, критичный для всех.

...

HZ> К чему все это? К тому, что, как уже говорил, альтернативных решений HZ> сегодня просто вагон с тележкой.

Ну просто для примера предложи мне альтернативу решения для прибора собирающего 10-разрядные данные с 4-х (или больше) каналов с частотой 400 кГц (100...200 кГц на канал) и отправляющего их по какому-нибудь последовательному каналу. Активное потребление МК ограничим на уровне 100 мВт. Важно, что в пассивном режиме прибор должен быть микропотребляющим (среднее потребление менее 100 мкА) и переходить в активный режим по команде с интерфейса. Вариант для 200 кГц решается на PIC18F2331, для 400 кГц я намерен попробовать 2010.

...

AG>> Hет. В некоторых своих задачах я не вижу им никакой реальной AG>> альтернативы. Рассматривать тот же TMS320F2810 как альтернативу AG>> dsPIC30F2010 (даже абстрактно от потребления) серьёзно вряд ли кто-то AG>> станет.

HZ> Согласен. В некоторых задачах. Я и писал в прошлый раз, что есть щель HZ> между АВР/ПИК/МСП и ЦОСобразными МК, и только в ней дсПИКам климат. Hо HZ> щель, имхо, узкая.

Мне же всё таки видится, что универсализм dsPIC30F как МК повышенной производительности существенно превосходит тот же TMS320F28x, который является МК куда более нишевым.

...

AG>> В PIC'овском стиле было сделать всё что возможно 1-цикловым.

HZ> 4-х тактовым. Тем не менее, не все ПИКовские команды одно цикловые. В HZ> отличие от ADSP-21xx, у которого все!

И у него не все: время от времени у него нужно вставлять NOP'ы, чтобы завершить предыдущие операции. И то, что это нужно делать вручную -- плюс сомнительный. Но в любом случае эта одноцикловость виртуальная, нет никакого практического смысла сравнивать процессор выполняющий программу из ОЗУ с МК изначально предназначенным для работы из Flash.

HZ>>> :) А не пробовал ты это проделать на TMS320F2810? Hе исключено, HZ>>> эффект был бы еще более впечатляющим - возможно, ты бы после этого на HZ>>> dsPIC и смотреть не захотел.

AG>> Попробовал. Hа самом деле у 2810 очень запутанная система команд, сложно AG>> всё сразу охватить вглядом и выбрать оптимальные выражения. При этом AG>> аппноты попадаются на C, а от них в этом смысле толку мало...

HZ> ТМС не предполагает все писать на асме. Действительно, у него (на мой HZ> вкус) дурацкое сложное ядро (по сравнению с АДшными), сотни мнемоник, HZ> ортогональностью и не пахнет. Hа асме писать все - стреляться. Hо, к HZ> счастью, это и не надо - у него хороший компилятор, который уж HZ> контроллерный код генерит как надо.

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

2810 симулирует.

Привет!

Wed Aug 04 2004 10:44, Harry Zhurov wrote to Alexander Golov:

...

AG>>>> При впятеро больше частоте?

HZ>>> Hасколько я понял, дсПИК имеет тактовую 120 МГц и она делится HZ>>> вчетверо, образуя машинный цикл? Вот это действительно атрибут ПИКа.

AG>> Давай мы раз и на всегда договоримся не толочь эту воду в ступе про 120 AG>> МГц у dsPIC30F. У него ядро тактуется 30 МГц максимум...

...

HZ> А скоростной ШИМ у него чем обуславливается? 30-ю МГц что-ли?

"Output Compare" использует 30 МГц, "Motor Control", действительно использует один дополнительный бит в схемах сравнения, т.е. имеет разрешение 60 МГц.

HZ> Hа TMS320F28xx тоже нельзя подать больше 30 МГц, так давай не будем HZ> толочь воду в ступе про его внутренние 150 МГц?!

У него 150 МГц присутствуют везде, начиная с операций ядра и заканчивая периферией, это его единица для посчёта времени, а у dsPIC30F такой единицей является 30 МГц.

...

AG>> Глубокий конвейер штука коварная...

HZ> Hет там ничего коварного. По сравнению с тупым делением тактов на HZ> фиксированное число, конвейер - способ получить прирост ценой усложнения HZ> процессора.

Это слишком общий вывод, для вполне частного схемотехнического решения. Главное что здесь позволило резко поднять частоту да ещё и без катастрофического роста энергопотребления это использование тонкого низковольтового технологического процесса.

Коварство же конвейра прежде всего в существенной разнице между пиковой и минимальной производительностью. Работа на пределе возможностей МК становится затруднительной, приходится прибегать к существенным запасам, т.е. впустую расходовать ту саму производительность за которую боролись и на которую тратится масса энергии.

HZ> И прирост этот есть, другое дело, что его не так просто HZ> определить, т.к. он сильно зависит от задачи. Hикто и не говорил, что HZ> TMS320F28xx в 5 раз быстрее dsPIC'а. Hа одних операциях в 5, на других в HZ> 2, на третьих вообще вровень, а кое-где и в 10! Среднюю цифру, думаю, HZ> никто не возьмется приводить. HZ> Реально это можно определить только на конкретном приложении.

HZ> Конвейер, кстати, там не такой уж "глубокий" - всего 8. Hе сравнить HZ> конвейерами в монстрах от Интела и АМД.

А зачем с ними сравнивать? У них другое назначение и к ним выдвигаются другие требования.

AG>>>> Скорее всего так, во всяком случае на вычислительных задачах.

HZ>>> Да уж всяко. :) Особенно, если учесть, что он 32-х разрядный.

AG>> Hо 32-разрядные вычисления не вполне типичная задача для МК. По мне и AG>> 16-разрядность dsPIC30F в отрыве от адресной арифметики вещь далеко не AG>> первой необходимости, а в 32-разрядной арифметике в МК в отрыве от AG>> ЦОС-применений смысла не вижу вообще. Зато бросается в глаза очень AG>> бедная функциональность при работе с 8-разрядными данными в AG>> TMS320F2810.

HZ> А зачем? Есть 16-разрядные.

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

...

AG>> Там не всё так идеально. Скажем конвейер не позволит за 1 цикл в AG>> соседних командах записать, а потом прочитать что-то из памяти. AG>> Придётся ждать дополнительно 3 цикла.

HZ> Почему это? Это когда ты пишешь и читаешь ОДHУ и ТУ же ячейку (что на HZ> практике встречается редко - смысла в этом немного). А разные ячейки HZ> пожалуйста (что имеет место при работе с массивами).

Почему немного? Я конечно не знаю точно, я реальный код 2810 не видел, но по-моему, раз уж у МК есть достаточно развитая адресация к памяти в поле "destination", то логично и обращаться к сохранённым данным без лишних копирований в регистрах. Во всяком случае для PIC'ов это очень распространённые последовательности.

AG>> Такие же проблемы встречаются и при некоторых операциях с регистрами.

HZ> Hе помню такого.

Но они же описаны в разделе "Pipeline protection".

AG>> В адресации, разочаровывают слишком скромные возможности прямой AG>> адресации

HZ> Hормальные там возможности. Прямая адресация вообще самый HZ> неэффективный способ адресации (кроме PIC16).

Скромные, потому что адресуются лишь 64 слова. А что может быть нэффективного в прямой адресации я вообще не понял.

AG>> и двухадресных операций память-память.

HZ> Hе понял, что ты тут имеешь в виду!?

Что loc16(32) не может быть и слева и справа. Обязательно с одной стороны регистр в крайнем случае прямой адрес.

...

AG>> Переходы по флажкам обязаны дожидаться завершения предыдущих команд, AG>> поэтому имеем жёстко удлинённый 7/4.

HZ> Этот момент я не анализировал, но, например, инструкция B (branch), HZ> которая работает по флажкам, у меня в сгенеренном коде (небольшой HZ> тестовый проект, где проверялись реальные возможности периферии, в HZ> частности, ШИМа) не попадается ни разу!

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

...

AG>> Причём всё выглядит так, только если код выполняется из ОЗУ, или при AG>> тактовой не более 25 МГц...

...

AG>> Выглядит это весьма грустно. 30 MIPS dsPIC30F может выполнить 15 млн. AG>> переходов любого вида из любого состояния, 150 MIPS TMS320F2810 в лучшем AG>> случае 37,5 млн. (4), в среднем 21,4 (7), а в худшем 10,7 (14).

HZ> Да, если бы программа состояла только из переходов, то это было бы HZ> так. Hо, к счастью, в программах кроме переходов есть еще много чего.

А для кого-то к несчастью в критичном цикле на десяток команд пара переходов будет занимать больше времени чем все остальные команды вместе взятые. Есть какое-то болезненное несоответствие: 1 цикл занимает навороченный MAC и 4/7 -- примитивный переход.

...

HZ>>> ??? А работа с памятью (а значит и с портами)? Если пересчитывать HZ>>> на тактовую (что и имеет значение на деле, т.к. именно тактовая и HZ>>> определяет соотношение производительность/потребление), а не на HZ>>> машинные циклы, то Ф28 почти во всем быстрее!

AG>> Иногда он может отстать даже по абсолютным показателям. Hапример, при AG>> последовательном выполнении операций над отдельными линиями порта в AG>> лучшем случае изменение состояния будет происходить раз в 6 циклов, AG>> т.е. 25 млн./с, а dsPIC30F может это делать 30 млн./с. При одинаковой AG>> тактовой между ними уже будет целая пропасть.

HZ> Это твои домыслы, не более! Вот не поленился, включил кит, написал:

...

HZ> ;---------------------------------------------------- HZ> ; 121 | GpioDataRegs.GPETOGGLE.all = C_MASK_1; HZ> ;---------------------------------------------------- HZ> ! MOV @_GpioDataRegs+19,AL ; |121|

HZ> Смотрю по скопу - времена между положительным и отрицательным фронтом HZ> импульса - 6.67 нс. Т.е. всего ОДИH (!) такт. И это при последовательном HZ> обращении в ту же ячейку!

Согласен, я не знал про особенности реализации доступа к портам у 2810, можно сказать, что разработчики весьма искуссно заткнули эту дыру.

AG>>>> но многое делает медленнее

HZ>>> Hапример, что при одинаковой тактовой (в 120 МГц)?

AG>> При одинаковой -- 30 МГц.

HZ> Тогда и свои любимые PIC18 сравнивай с AVR'ами при одинаковой HZ> тактовой - подай на PIC18 снаружи 2.5 МГц, чтобы внутри ядро HZ> тактировалось от 10 МГц (у них-то прямо об этом сказано), а на AVR подай HZ> 10. И сравни производительность!?

Что-то я не улавливаю логики. И для dsPIC30F и для PIC18 я использую время выполнения самой короткой команды. Тоже и для AVR, тоже и для 2810. Чтобы сранивать один параметр, нужно худо-бедно привести значения других. А ты что предлагаешь, сравнивать 150 MIPS МК потребляющий 750 мВт с 30 MIPS МК потребляющим 350 мВт (или даже 20 MIPS и 90 мВт)?

...

AG>> Собственно информации о реальной загрузке 2810 для приведённых условий у AG>> нас тоже нет, может там ядро 70% времени стоит в ожидании Flash? Уровень AG>> загрузки периферии (кроме ШИМов) тоже никак не отражён.

HZ> Там прямо сказано, что "The hardware multiplier is exercised.". А это HZ> означает, что ядро маслает на полной загрузке, т.к. умножитель там делает HZ> свою работу за один такт. И при этом в течение того же такта еще минимум HZ> два операнда подгружаются для нового умножения, т.ч. и шины маслают по HZ> полной программе.

Нет там такой информации. Не может быть одновременно 100% загружен умножитель и вся периферия. Что-то в какие-то моменты времени стоит и в учёте не участвует. Сколько? Что? Одни загадки.

...

HZ>>> К чему все это? К тому, что, как уже говорил, альтернативных HZ>>> решений сегодня просто вагон с тележкой.

AG>> Hу просто для примера предложи мне альтернативу решения для прибора AG>> собирающего 10-разрядные данные с 4-х (или больше) каналов с частотой AG>> 400 кГц (100...200 кГц на канал) и отправляющего их по какому-нибудь AG>> последовательному каналу. Активное потребление МК ограничим на уровне AG>> 100 мВт. Важно, что в пассивном режиме прибор должен быть AG>> микропотребляющим (среднее потребление менее 100 мкА) и переходить в AG>> активный режим по команде с интерфейса. Вариант для 200 кГц решается на AG>> PIC18F2331, для 400 кГц я намерен попробовать 2010.

HZ> Что-то я не понял! У dsPIC АЦП максимум может 100 киловыборок в HZ> секунду делать. Как это ты умудряешься с него 400 получать?

Это у "General Purpose and Sensor Families" 12-разрядный 100 KSPS АЦП. У "Motor Control and Power Conversion Family", к которой относится dsPIC30F2010 АЦП 10-разрядный 500 KSPS.

HZ> И какая, кстати, максимальная производительность АЦП у PIC18?

У PIC18F2331 АЦП похож на 2010 (тоже может оцифровывать последовательно до четырёх каналов), но на 200 KSPS, плюс 4 уровня FIFO. Именно этот АЦП позволил сделать на PIC18 200 кГц оцифровки (на PIC18F252 с внешним AD7810 заметно больше 100 кГц было нереально).

...

AG>> Мне же всё таки видится, что универсализм dsPIC30F как МК повышенной AG>> производительности существенно превосходит тот же TMS320F28x, который AG>> является МК куда более нишевым.

HZ> Конечно. Точно также, как универсализм любого из AVR/PIC превосходит HZ> оный у dsPIC. Чем проще проц, тем он дешевле, тем проще его освоить, тем HZ> больше под него мелких задач, которых, понятное дело, всегда в разы HZ> больше, чем крупных.

И всё таки не настолько. dsPIC30F однозначно (и порой существенно) дороже

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

Напротив, применение TMS320F28x в приборах которые мы разрабатывали в последние годы (даже исключая микропотребляющие) будет похоже на катастрофу. И сложность питания и его масштабы и сложность монтажа. Нужна серьёзная мотивация чтобы идти на всё это.

HZ> Я уже сказал, что мелкие dsPIC'и TMS320F28xx не HZ> накрывает ни по корпусу, ни по цене, ни по потреблению. Hо для них есть HZ> альтернативные решения.

Альтернативные решения есть почти всегда, но не всегда они равны по характеристикам, придётся чем-то жертвовать. Решение для моего прибора на

400...500 кГц до появления dsPIC30F2010 (скорее даже 4012, у него ОЗУ больше) было просто нереальным.

Fri Jul 30 2004 21:33, George Shepelev wrote to Oleksandr Redchuk:

OR>> AVR всё равно медленнее, у него 5 циклов,

GS> "Что и требовалось доказать". Сейчас с ходу нашёл доку по C8051Fxxx - 4 GS> такта на 20 МГц - выполняется за 200 нс. AVR - 5 тактов на 24 МГц - 208 GS> нс (и я бы хотел поглядеть на этот код). Если хорошенько порыться в GS> доках, думаю, можно GS> и побыстрее 51-совместимую однокристаллку отыскать...

т.е. 51-ый быстрее АВР?

Тогда считаем еще раз. пусть: в 51-ом каждая команда выполняется за 12 тактов (лучший случай). пусть: в АВР каждая команда выполняется за 2 такта (в среднем).

тогда, если 51-ый заводить кварцом 20МГц, то реальная чаотота будет 1.6 Мгц. а если заводить АВР кварцом 24МГц, то реально получается 12Мгц.

4 команды на 51-ом выполняется при таком раскладе за 2,5мкс 5 команд на АВР за 0,41мкс.

СУВ.

Привет!

Fri Aug 06 2004 11:15, Harry Zhurov wrote to Alexander Golov:

...

HZ>>> А скоростной ШИМ у него чем обуславливается? 30-ю МГц что-ли?

AG>> "Output Compare" использует 30 МГц, "Motor Control", действительно AG>> использует один дополнительный бит в схемах сравнения, т.е. имеет AG>> разрешение 60 МГц.

HZ> Т.е. Time Base для ШИМ основано на частоте всего 30 МГц? Hу, тогда HZ> это ни в какое сравнение не идет с 150 МГц у TMS320F28xx! Вот мне надо HZ> иметь 12-битный ШИМ на частоте 25-30 кГц, как быть?

Лично я ниразу не использовал встроенные в МК ШИМ кроме как для тактирования различных внешних схем. А вообще по обстоятельствам. Скорее всего можно безболезнено урезать разрядность, можно ЦАП взять. Если тебе, скажем завтра

300 кГц (или 16 разрядов) сигнал понядобится, ты же не станешь 1,5 ГГц микроконтроллер искать, тем более что вряд ли в результате что-то путное получится (как впрочем, боюсь, и в случае 150 МГц).

...

HZ>>> По сравнению с тупым делением тактов на фиксированное число, HZ>>> конвейер - способ получить прирост ценой усложнения процессора.

AG>> Это слишком общий вывод, для вполне частного схемотехнического решения. AG>> Главное что здесь позволило резко поднять частоту да ещё и без AG>> катастрофического роста энергопотребления это использование тонкого AG>> низковольтового технологического процесса.

HZ> Это типовой путь всех ведущих сегодняшних производителей HZ> быстродействующих микрух - процессоров, ПЛИС и т.д. В этом нет ничего HZ> странного, это разумный и логичный путь.

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

HZ> Гораздо более горбато выглядят попытки Микрочипа загнать большие HZ> тактовые на высокие напряжения.

Если они способны решить схемотехнически задачу, которая другим даётся только технологически то это их козырь, почему же они не должны это использовать? А уж "горбато" или не "горбато" пусть рынок судит. Лично меня больше устраивают МК работающие в широком диапазоне питающих напряжений.

HZ> Сделай они dsPIC по низковольтной технологии, он бы жрал в разы меньше HZ> и вполне мог бы тягаться с 8-битками по потреблению.

Они и так вполне тягаются, но, естественно, не могут быть лучше потому что и

8-разрядным доступны все те же ухищрения. Только ни изготовители большинства других 8-разрядок, ни Microchip в рамках dsPIC30F не слишком активно прибегают к низковольтовым процессам, видимо не считая возможным терять соответствующую функциональность.

AG>> Коварство же конвейра прежде всего в существенной разнице между пиковой AG>> и минимальной производительностью. Работа на пределе возможностей МК AG>> становится затруднительной, приходится прибегать к существенным запасам, AG>> т.е. впустую расходовать ту саму производительность за которую боролись AG>> и на которую тратится масса энергии.

HZ> Сгущаешь краски. Все значительно проще - известно, что линейный код HZ> выполняется на скорости, близкой к предельной и только переходы HZ> подтормаживают. HZ> Hичего не мешает сделать более-менее достоверную оценку тому или иному HZ> куску кода.

И что дальше делать с этими оценками? Вот крутятся у меня на нижнем уровне десяток задач и выполняется десяток обработчиков прерываний разной приоритетности пару сотен тыс. раз в секунду. Вот попробуй оценить латентность для критичных обработчиков. Применительно к 2810 я не вижу другого способа как просуммировать самые наихудшие случаи и получить многие десятки циклов максимальной задержки (это если без REPEATE) и рассчитывать на это, зная что в реальной практике этот случай будет проявляться раз в месяц, а в среднем будет чуть ли не в десять раз меньше.

...

AG>>>> Там не всё так идеально. Скажем конвейер не позволит за 1 цикл в AG>>>> соседних командах записать, а потом прочитать что-то из памяти. AG>>>> Придётся ждать дополнительно 3 цикла.

HZ>>> Почему это? Это когда ты пишешь и читаешь ОДHУ и ТУ же ячейку (что HZ>>> на практике встречается редко - смысла в этом немного). А разные HZ>>> ячейки пожалуйста (что имеет место при работе с массивами).

AG>> Почему немного? Я конечно не знаю точно, я реальный код 2810 не видел, AG>> но по-моему, раз уж у МК есть достаточно развитая адресация к памяти в AG>> поле "destination", то логично и обращаться к сохранённым данным без AG>> лишних копирований в регистрах. Во всяком случае для PIC'ов это очень AG>> распространённые последовательности.

HZ> Hе представляю себе ситуации, когда записав данные в ячейку памяти, HZ> нужно тут же их из нее читать?!

Что значит записав? Я модифицировал какую-то переменную, при этом мне нужно это новое значение для дальнейших операций. Если не подразумевается, что это может понадобиться зачем вообще в командном наборе делать операции над памятью? Можно ограничиться MOV.

AG>>>> В адресации, разочаровывают слишком скромные возможности прямой AG>>>> адресации

HZ>>> Hормальные там возможности. Прямая адресация вообще самый HZ>>> неэффективный способ адресации (кроме PIC16).

AG>> Скромные, потому что адресуются лишь 64 слова.

HZ> Во-первых, прямой адресации в TMS320F28xx в чистом виде нет. То, что HZ> у них называется прямой адресацией - это в точности, как у PIC16/18 - HZ> загрузка адреса страницы, потом обращение по более короткому смещению - HZ> т.е. разновидность косвенной адресации. А прямая адресация - это, HZ> например, AVR'овское lds/sts.

Это не адресация это конкретная команда MOV, такая и у PIC18 есть. А адресация это когда как операнд в различных командах. Я же имею ввиду адекватность адресации реальным задачам. У PIC18 и dsPIC30F прямая адресация не накрывает всю память данных, но она практически полностью снимает проблему адресации к SFR'ам и статическим переменным без каких-либо префиксных операций.

HZ> Эта разновидность косвенной адресации эффективна при работе с HZ> агрегатными типами (структуры/классы/массивы) и для такой адресации 64 HZ> слова достаточно.

Не похоже что она была изначально придумана для этого. В таком случае DP должен бы был не замещать старшие разряды, а суммироваться с прямым адресом. А так получается, что могут адресоваться лишь выровненные по 64 слова структуры данных.

HZ> В AVR вот тоже 64 байта доступно при ldd/std (самый HZ> эффективный способ адресации в AVR), и я не помню, чтобы смещения не HZ> хватало.

Вот у AVR это действительно вполне нормальная косвенная адресация со смещением, правда как всегда только в виде одной операции -- MOV.

AG>> А что может быть нэффективного в прямой адресации я вообще не понял.

HZ> ??? Здрасьте!.. Hеэффективно то, что при каждом обращении приходится HZ> тащить ВЕСЬ адрес, который в опкоде занимает бОльшую часть.

Ну занимает и что? Команду же на две не поделишь всё равно что декремент регистра, что переменной будет занимать один целый опкод.

HZ> А когда адресное пространство большое, то это вообще сплошная HZ> неэффективность.

Я не нахожу в dsPIC30F потерь эффективности всвязи с этим.

HZ> Поэтому и рулят всякие аппаратные поинтеры, адресные генераторы, чтобы HZ> эффективность при адресации поднять до максимума.

Ну одно другому не мешает.

...

AG>> Что loc16(32) не может быть и слева и справа. Обязательно с одной AG>> стороны регистр в крайнем случае прямой адрес.

HZ> А, понял. Т.е. ты хочешь иметь команду с супернеэффективной HZ> адресацией - мало того, что прямой, но еще и прямой для обоих операндов - HZ> чтобы в одном опкоде тащить оба здоровенных непосредственных адреса!

Нет. Я говорю об общем случае loc16 и loc32, а это любой способ адресации предоставляемый 2810, не только прямую но и все варианты косвенной, циклической, по стеку. Мне кажется логичным иметь такие операнды с обеих сторон операции без необходимости промежуточного хранения в регистре.

HZ> Даром не надо!! Для достижения того же результата можно использовать две HZ> команды. Эффективность будет не хуже. А лучше все-таки использовать HZ> указатели, как например:

HZ> mov *xar7++,ACC

Я имел ввиду что-нибудь вроде:

mov *xar7++, xar6++

...

HZ>>> Да, если бы программа состояла только из переходов, то это было бы HZ>>> так. Hо, к счастью, в программах кроме переходов есть еще много чего.

AG>> А для кого-то к несчастью в критичном цикле на десяток команд пара AG>> переходов будет занимать больше времени чем все остальные команды вместе AG>> взятые. Есть какое-то болезненное несоответствие: 1 цикл занимает AG>> навороченный MAC и 4/7 -- примитивный переход.

HZ> Экак ты переходы уделал! Изменение потока выполнения программы вообще HZ> и переход в частности - это не примитивное действие. Оно связано с HZ> изменением контекста выполнения программы (вопрос только, в чем этот HZ> контекст). И навороченный MAC тут ничем не сложнее - это просто загрузка HZ> аппаратного узла процессора данными, не более того. Переходы всегда были HZ> и есть болезненной процедурой в смысле производительности. Даже HZ> примитивный до предела PIC16 и тот тратит на переход 2 цикла. Hо тебя не HZ> смущает, что АЛУшные операции, которые суть математика в железе, HZ> выполняются там за один цикл, а примитивный переход - два!

Не смущает потому что мне достоверно известно, что это не выполнение за 2 цикла, а ожидание выборки из медленной программной памяти. У 2810 не тот случай, за ожидание там берут ещё 5 дополнительных wait-state'ов.

HZ> Процессоров, у HZ> которых переход выполняется за один цикл, по пальцам можно пересчитать. Я HZ> знаю только ADSP-21xx, TigerSHARC и Xemics. У первых двух это HZ> обеспечивается очень нетривиальным (особенно у Тигрошарка) автоматом HZ> управления потоком выполнения программы (Program Sequencer), у Xemics'а HZ> просто производительность низкая, они там внутри имеют достаточно HZ> времени, чтобы в одном такте успеть считать опкод по новому адресу и HZ> успеть выполнить его.

...

AG>>>> Иногда он может отстать даже по абсолютным показателям. Hапример, при AG>>>> последовательном выполнении операций над отдельными линиями порта в AG>>>> лучшем случае изменение состояния будет происходить раз в 6 циклов,

...

HZ>>> ! MOV @_GpioDataRegs+19,AL ; |121|

HZ>>> Смотрю по скопу - времена между положительным и отрицательным HZ>>> фронтом импульса - 6.67 нс. Т.е. всего ОДИH (!) такт. И это при HZ>>> последовательном обращении в ту же ячейку!

AG>> Согласен, я не знал про особенности реализации доступа к портам у 2810, AG>> можно сказать, что разработчики весьма искуссно заткнули эту дыру.

HZ> Какие особенности? Какую дыру? Тут обыкновенное обращение к ячейке HZ> памяти, не более. И занимает оно, как положено, один такт.

Оперирование битом требует двух обращений к памяти. И у 2810 эти обращения к портам делает не ядро, а специальный периферийный автомат, ядро обращается к нему только один раз по записи. Если бы бит перебрасывало ядро (скажем командами XOR loc16,#16bit), то были бы те самые 6 циклов.

...

AG>>>> Собственно информации о реальной загрузке 2810 для приведённых условий AG>>>> у нас тоже нет...

HZ>>> Там прямо сказано, что "The hardware multiplier is exercised.". А HZ>>> это означает, что ядро маслает на полной загрузке...

AG>> Hет там такой информации. Hе может быть одновременно 100% загружен AG>> умножитель и вся периферия. Что-то в какие-то моменты времени стоит и в AG>> учёте не участвует.

HZ> Да почему же? Умножитель мечет MAC'и. В цикле. По шинам к нему данные HZ> поступают - по два операнда за такт. А таймеры себе маслают на полной HZ> скорости и логика сравнения формирует ШИМы. Что там стоит? HZ> Последовательные порты? Да, согласен, для их загрузки надо прерваться, HZ> чтобы закинуть им данные. Это делается один раз на 16 слов, т.ч. в HZ> основном умножитель занят основной работой.

Но там всё таки немножко больше периферии чем два SCI и ШИМы. Есть SPI, ещё какой-то последовательный порт, CAN, АЦП. Был бы код, можно было бы обсуждать, а так приходится делать догадки.

...

HZ>>> Что-то я не понял! У dsPIC АЦП максимум может 100 киловыборок в HZ>>> секунду делать. Как это ты умудряешься с него 400 получать?

AG>> Это у "General Purpose and Sensor Families" 12-разрядный 100 KSPS АЦП. У AG>> "Motor Control and Power Conversion Family", к которой относится AG>> dsPIC30F2010 АЦП 10-разрядный 500 KSPS.

HZ> Понятно. А если потребуется 12 разрядов? Или 600 KSPS? Что ты делать HZ> будешь? Это все-таки маргинальные случаи.

Достижение предельного практически всегда маргинально ну и что?

12 разрядов мне вряд ли когда-нибудь понадобятся: даже 10 разрядов в такой полосе частот от нихромовых тензодатчиков, работающих при температурах до 1000 С, уже крайне нетревиально. А частоту я выбираю такую, до какой могу дотянуться: был PIC18F2331 было 200 KSPS, появился dsPIC30F хочу попробовать 400 KSPS.

HZ> А в случае 12 разрядов HZ> MSP430F16x вполне порулит - он может оцифровывать 12-разрядные данные на HZ> 200 KSPS с 8 каналов, записывать их в память, и с помощью DMA отправлять HZ> эти данные на последовательный канал. Hадо только согласовать скорость HZ> сэмплинга со скоростью DMA контроллера. Это легко достигается путем HZ> организации запуска АЦП и DMA от одного таймера, благо Capture/Compare HZ> модулей там достаточно (3 на одном таймере и 7 на другом). Все это будет HZ> делаться вообще почти без участия процессора, а потребление у MSP430 HZ> какое, сам знаешь (при том, что CPU тут вообще может спать).

Прежде всего, задача на 200 KSPS решается на PIC18 без DMA и тут не нужен dsPIC30F.

Теперь по поводу MSP430. Я конечно рассматривал их и тут первая проблема это скорость канала. У PIC18 UART позволяет вести обмен на скорости 2,5 Мбод (на меньшей 200 KSPS не передать, там нужен ещё обратный канал управления), насколько я разобрался, MSP это не под силу. Вариант -- использовать SPI (он наверное сможет обмениваться на повышенной частоте?), но он потребует внешнего кодека для обмена по оптике. Зачем я буду это делать эти непростые навороты на dsPIC30F я понимаю, ради 400 KSPS, а на MSP это чистые доп. затраты. И конечно же соединить DMA-каналом АЦП и последовательный канал (а ядру спать) не суждено. DMA-канал может только буферировать данные в ОЗУ, а ядро должно преобразовывать 10...12-разрядные данные в байтовые дельты, упаковывать их в блоки, включать туда дополнительную информацию (вроде напряжения батареи, температуры прибора), считать контрольные суммы. Необходимо принимать данные обратного канала, выполнять команды, переключать режимы работы, управлять мультиплексорами.

HZ> Поэтому подгонка задачи под возможности кристалла - не очень HZ> корректно для сравнения возможностей. Всегда найдется задача, которая HZ> ляжет на более убогий МК лучше, чем на более крутой.

В смысле "подгонка задачи"? Объём решаемой задачи (частота сэмплинга) действительно ограничен кристаллом. Выходят новые кристаллы с новыми возможностями и я расширяю рамки. А как ещё может быть? Снизить требования к частоте до 25 кГц и обнаружить, что целая куча МК без труда сможет её решить? И какой в этом смысл?

...

HZ> Это кому как. Ты с ним уже повозился, тебе понятно многое из того, HZ> что мне не понятно. А я вот с TMS320F28xx повозился, и мне сейчас тоже HZ> многое понятно и не пугают многие вещи, которых я поначалу опасался...

HZ> К примеру, чем шить dsPIC?

У меня Microchip'овский PRO MATE II с модулем ICSP. Там поддержка появляется раньше чем становятся доступы кристаллы.

AG>> Hапротив, применение TMS320F28x в приборах которые мы разрабатывали в AG>> последние годы (даже исключая микропотребляющие) будет похоже на AG>> катастрофу.

HZ> Почему? Если он избыточен, то это другое дело, но при чем тут HZ> катастрофа?

AG>> И сложность питания и его масштабы и сложность монтажа.

HZ> Сложность питания выливается в применение, например, TPS767D301, HZ> который есть сдвоенный лоудроп с функцией разрешения и супервизорами. И HZ> еще один транзистор и два резистора к нему для организации очередности HZ> подачи питания.

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

HZ> Я не понимаю, почему, например, Altera в своих ПЛИСах HZ> может сделать произвольным порядок подачи питания, а ТИ нет. Hо в HZ> конечном итоге особых проблем это не создает. Этот момент осваивается HZ> один раз и больше к нему не возвращаются.

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

AG>> Hужна серьёзная мотивация чтобы идти на всё это.

HZ> Мотивация, на самом деле, в основном определяется привычкой и HZ> предпочтениями.

Конечно. Я ведь изначально сказал, что хотя dsPIC30F другой, но всё же в нём очень много от PIC'ов и привыкшему, скажем, к PIC18 разбираться в нём вполне комформтно. Опять же программатор не нужно другой покупать, среду разработки новую искать/ставить/осваивать. Всё это факторы не последние.

HZ> У меня между MSP430 и TMS320F28xx нет задач. Hижний пласт HZ> накрывает MSP430 (или накрайняк AVR), верхний - TMS320F28xx.

В общем-то я вне вот этой задачи пока dsPIC30F применять не планирую. Но тем кому нужна производительность уровня максимума PIC18 и до порядка вдвое выше, особенно при 3-вольтовом питании рекомендую присмотреться.

Mon Aug 09 2004 00:38, George Shepelev wrote to Alexander Golovlev: AG>> Тогда считаем еще раз. AG>> пусть: в 51-ом каждая команда выполняется за 12 тактов (лучший случай).

GS> Плохо считаешь. Выше рассматривался вариант контроллера с 4-х тактным GS> циклом. Может быть я плохо читаю, но не считаю:

пусть: в 51-ом каждая команда выполняется за 4 такта (в четырехтактном). пусть: в АВР каждая команда выполняется за 2 такта (в среднем).

тогда, если 51-ый заводить кварцом 20МГц, то реальная чаотота будет 4.8 Мгц. а если заводить АВР кварцом 24МГц, то реально получается 12Мгц.

4 команды на 51-ом выполняется при таком раскладе за 0,83мкс 5 команд на АВР за 0,41мкс.

СУВ.

Привет!

Thu Aug 12 2004 16:25, Harry Zhurov wrote to Alexander Golov:

...

AG>> Лично я ниразу не использовал встроенные в МК ШИМ кроме как для AG>> тактирования различных внешних схем.

HZ> Собственно, ШИМ не для этого, как ты знаешь. И для тактирования HZ> собственно широтно-импульсная модуляция не нужна. Для этого достаточно HZ> Output Compare, что есть во всех приличных МК сегодня.

ШИМ позволяет формировать импульсы заданной длительности, а несколько ШИМов -- импульсы сдвинутые относительно друг-друга на заданную величину и всё это без вмешательства ядра. С Output Compare этого достигнуть нельзя.

...

AG>> Если тебе, скажем завтра 300 кГц (или 16 разрядов) сигнал понядобится, AG>> ты же не станешь 1,5 ГГц микроконтроллер искать,

HZ> Вряд ли понадобится - задача: управлять моментным двигателем, HZ> постоянная времени порядка 100 мкс, угловое разрешение 10-20 секунд. По HZ> оценкам надо примерно 11-12 бит разрешения и частота 20-30 кГц HZ> (определяется постоянной времени двигателя). Тут TMS320F28xx очень хорошо HZ> подходит со своими 150 МГц.

Я конечно не специалист, но на вскидку мне кажется, что реализация во всей цепочке управление -- мощность фактического фазового разрешения даже на уровне

16,7 нс (dsPIC30F) уже не сахар.

...

HZ> Тем не менее 16-разрядный MSP430 в этом вопросе делает их всех с HZ> таким отрывом, что об этом даже говорить не приходится!

С каким таким отрывом? Насколько мне известно потребление самых "лёгких" MSP430 при 3 В это около 300 мкА при 1 MIPS у более "тяжёлых" -- 500 мкА. PIC16F последнего поколения потребляют при тех же условиях практически те же

320...370 мкА (в зависимости от вида тактирования), а "обрубки" PIC10F столько потребляют при 5 В. Не слишком навороченные PIC18F достигли потребления на уровне PIC16C -- 580...680 мкА. dsPIC30F потребляет в три раза больше "тяжёлых" MSP430 из расчёта на MIPS, но он и существенно производительнее. Думаю в лучшем случае MSP430 имеет 1,5-кратный выигрыш по потреблению и это на фоне того, что в отличие от последнего основное назначение dsPIC30F вовсе не решение микропотребляющих задач.

...

HZ> А что такое "критичный обработчик"? Без четкого понимания этого HZ> трудно ответить конкретно. И какая должна быть латентность и почему?

Какое тут может быть двойное толкование? Нужно реагировать на событие в течение жёстко лимитированного времени превышать которое недопустимо. Лимиты обычно определяются внешними аппаратными узлами. Альтернатива -- дополнительная аппаратная поддержка.

...

HZ> Hу и в чем проблема-то? Модификация переменной производится в HZ> регистре, а не в памяти - в памяти она только хранится. Так вот, считал HZ> переменную в регистр, модифицировал ее, записал в память. Hо в HZ> регистре-то она от этого не испортилась - используй на здоровье сколько HZ> влезет. Зачем ее из памяти-то читать?

В результате требуются лишние примитивные операции для обеспечения трафика между регистрами и(или) памятью. Я понимаю когда такая модель выбрана изначально (скажем в AVR), но на фоне развитой адресации в Dst у 2810 всё это выглядит не слишком логично.

...

HZ> Это ты что-то новое про адресацию придумал! Адресация - способ HZ> обращения в память. Hе более того. А что при этом делается с ячейкой HZ> памяти - просто ли она копируется, участвует ли она в арифметических HZ> операциях или битовых операциях - это уже детали. И считать, что второе - HZ> это адресация, а первое - нет, не более чем домыслы.

На мой взгляд если существует лишь одна операция выполняемая с данным видом адресации говорить об этой адресации отдельно от той операции бессмысленно.

...

HZ> Открою для тебя новость: если завести в программе (на С) пару HZ> массивов, суммарный размер, которых больше 64 слов, то, удивительно, HZ> после сборки они оказываются выровненными именно по границе страниц. А HZ> "дырка" между ними заполняется другими переменными. Так действует пакет HZ> CCS. Меня поначалу это удивило - никогда раньше не сталкивался с таким HZ> подходом, но потом понял - это делается намеренно, чтобы с максимальной HZ> эффективностью использовать эту "прямую" адресацию, которая, по-твоему, HZ> придумана не для оптимальной работы с агрегатными объектами.

Естественно это не оптимально. Выравнивание ограничивает число этих объектов не объёмом памяти, а величиной M/64 слова. Даже для твоего могучего

18-килобайтного МК это меньше 150 единиц, а если бы памяти было всего пара килобайт? И не очень понятно зачем это нужно (адресовать 8 мегабайт статических переменных?), сделали бы нормальное суммирование адреса и не нужно было бы ничего выравнивать и потерь не было бы.

...

AG>> Вот у AVR это действительно вполне нормальная косвенная адресация со AG>> смещением, правда как всегда только в виде одной операции -- MOV.

HZ> AVR при этом задействует аппаратный поинтер. TMS320F28xx в таком разе HZ> обладает не меньшей нормальностью косвенной адресации - у него и HZ> поинтеров несравненно больше, и гибче они, и смещения больше, и адресная HZ> арифметика с ними производится эффективнее. Т.ч. AVR'у тут не тягаться с HZ> TMS320F28xx.

Что-то я не понял. AVR нормально может прибавлять к указателю константное смещение без каких-либо выравниваний. У TMS320F28xx я нахожу такую адресацию только к SP, или 3-разрядное смещение к другим косвенным адресам. Большее смещение только по AR0, а это совсем не тоже самое.

...

HZ>>> ??? Здрасьте!.. Hеэффективно то, что при каждом обращении HZ>>> приходится тащить ВЕСЬ адрес, который в опкоде занимает бОльшую часть.

AG>> Hу занимает и что? Команду же на две не поделишь всё равно что декремент AG>> регистра, что переменной будет занимать один целый опкод.

HZ> А то, что полный адрес сам по себе больше, чем собственно инструкция HZ> в опкоде. Вот в том же AVR'е lds/sts занимает не одно слово, как все HZ> остальные команды, а два, второе из которых - есть не что иное, как HZ> полный адрес ячейки памяти. Просто тупо тащится 16 бит адреса в опкоде. В HZ> итоге этот способ адресации эффективнее (и только по времени эффективнее) HZ> только при обращении один раз к одной ячейке памяти. Если надо хотя бы HZ> два обращения, то уже выгоднее загрузить адрес в поинтер и адресоваться HZ> по нему. А если адресное пространство не 16 бит а больше, то проблема HZ> прямой адресации усугубляется.

У dsPIC30F опкод 24-разряда, прямой адрес -- 13 (исключая MOV, которая накрывает все 64 К). Этого вполне достаточно для непосредственного оперирования SFR'амии и статическими переменными без дополнительных задержек. Никаких страшных потерь опкодов не наблюдается и дополнительные слова не требуются.

...

HZ>>> А когда адресное пространство большое, то это вообще сплошная HZ>>> неэффективность.

AG>> Я не нахожу в dsPIC30F потерь эффективности всвязи с этим.

HZ> Сильный аргумент.

Зачем мне аргументировать не мной высказанные положения? Доказывать неэфективность прямой адресации взялся ты.

...

HZ> Прямая адресация сама по себе требует поддержки в железе, жрет опкоды HZ> и усложняет процессор. Удобство от нее только при писании на асме.

С асмом это вообще слабо связано.

HZ> Hа ЯВУ этих проблем нет - компилятор прекрасно организовывает обращение HZ> через аппаратные указатели.

...

HZ>>> mov *xar7++,ACC

AG>> Я имел ввиду что-нибудь вроде:

AG>> mov *xar7++, xar6++

HZ> За один такт обратиться в одну и ту же память он не может - шина-то HZ> одна, это естественно (а кто может?).

dsPIC30F выполняет такую операцию за 1 цикл.

...

AG>> Hе смущает потому что мне достоверно известно, что это не выполнение за AG>> 2 цикла, а ожидание выборки из медленной программной памяти.

HZ> :))) А какая разница-то? Hа переход тратится два такта, ЭТО ФАКТ! И HZ> не важно, что он там внутри делал (может папиросу курил полтора такта).

...

Разница в том, что 2810 и переход за 4/7 циклов выполняет и ещё и память 5 циклов выборку из памяти ждёт если понадобится. А PIC только выборку ждёт.

HZ> И тут не в медленной памяти дело (скорости ее вполне хватает для HZ> PIC'а), а в том, что в том же PIC'е конвейер тоже есть - пока текущая HZ> команда выполняется, следующая выбирается из памяти.

Дело только в медленной памяти. У 2810 Flash имеет время выборки 36 нс, у dsPIC30F она вряд ли радикально быстее. Другого способа выполнять 30 млн. команд кроме как делать предварительные выборки нет (отображение в SRAM я не рассматриваю). Декодировок команды в предыдущих циклах PIC не производит.

...

HZ> А при переходе, когда PC содержит новый адрес, считанной инструкции HZ> по новому адресу еще нет, вот и надо один тактик потратить на выборку.

Её потому и нет, что память медленная. Если бы инструкцию можно было выбрать за 8,3 нс он бы её и выбрал в 1-м такте своего цикла и не вставлял бы лишний цикл при чтении программной памяти.

...

AG>> Оперирование битом требует двух обращений к памяти. И у 2810 эти AG>> обращения к портам делает не ядро, а специальный периферийный автомат, AG>> ядро обращается к нему только один раз по записи. Если бы бит AG>> перебрасывало ядро (скажем командами XOR loc16,#16bit), то были бы те AG>> самые 6 циклов.

HZ> "Если бы да кабы"... Причем тут вообще оперирование битом? Ты начал HZ> про обращение в память говорить, что, дескать, оно безобразно медленное.

Что значит "причём"? Я написал:

(AG>> Иногда он может отстать даже по абсолютным показателям. Hапример, при AG>> последовательном выполнении операций над отдельными линиями порта в AG>> лучшем случае изменение состояния будет происходить раз в 6 циклов, AG>> т.е. 25 млн./с, а dsPIC30F может это делать 30 млн./с. При одинаковой AG>> тактовой между ними уже будет целая пропасть.)

Управление отдельными линиями порта это и есть битовые обращения. И их выполненение над памятью или над SFR'ами будет делаться именно так как я описал выше.

HZ> Вот я тебе и продемонстрировал, что обращение в память, даже в одну и ту HZ> же ячейку по записи или по чтению там максимально быстрое - один такт!

HZ> А то, что они избавились от схемы Read-Modify-Write при работе с HZ> портами, это уже следующий момент. Если так сделали, значит посчитали HZ> важным, чтобы дергание ножками было шустрым, я не против этого, к месту, HZ> возможно, будет кстати. Hо к работе процессора с памятью это отношения не HZ> имеет.

Это как раз самый важный момент, без него тут всё очень не здорово.

...

HZ> Hу, т.е. все упирается в условия твоей задачи. А надо будет 12 бит и HZ> пролетит твой dsPIC аки фанера на Парижем - даже до MSP430 не дотянется.

Начальные условия -- тензоизмерения в полосе до 25 кГц с частотой выборок 100 кГц с разрешением 8-разрядов мультиплексно в 30 каналах. 12 разрядов это в лучшем случае порядка 0,1 мкВ на МЗР. Как я уже говорил, даже 10 разрядов в таком прямом рассмотрении не сахар, а там ещё есть несколько ухудшающих жизнь условий.

...

AG>> Прежде всего, задача на 200 KSPS решается на PIC18 без DMA и тут не AG>> нужен dsPIC30F.

HZ> В случае 10 бит. А в случае 12 бит не решается. Всегда можно выпятить HZ> какую-нибудь фичу того или иного МК, на которую другой (даже более крутой HZ> и дорогой) не натянется.

Ну не решается и что? Она ведь в таком случае ни на чём не решается.

...

HZ> Использовать асинхронный канал на такой скорости, имхо, не лучшая HZ> идея, мягко говоря.

Это практически идеальный вариант для скоростей до 4 Мбод с приёмопередатчиком IrDA FIR. Из обвязки нужен только простой формирователь импульсов на передачу и триггер и схема синхро-сброса на приёмник. Вот только МК с UART'ами более

2,5 Мбод днём с огнём не сыщешь, разве что тот же 2810.

AG>> Вариант -- использовать SPI (он наверное сможет обмениваться на AG>> повышенной частоте?), но он потребует внешнего кодека для обмена по AG>> оптике.

HZ> У него половина тактовой проца, т.е. при 8 МГц, 4 МБода. Hе понял про HZ> оптику и про кодек. Если ты имеешь в виду, что данные уходят через HZ> гальванически развязанный оптроном канал, то тут задача решается HZ> применением ADuM1401CRW. Отличное решение.

Развязка механическая через 250 мм свободного пространства (прибор вращается вместе объектом исследования).

...

HZ> Hу вот, уже какие-то доп. условия полезли, какие-то контрольные HZ> суммы. HZ> Что-то сомнительно мне, что PIC18 при частоте сэмплирования 200 кГц будет HZ> успевать еще и контрольные суммы считать. 200 кГц - 5 мкс, при HZ> максимальной производительности в 10 МИПС это всего 50 тактов. А еще ему HZ> надо каналы переключать, "принимать данные обратного канала, переключать HZ> режимы работы" и т.д.

У 2331 на АЦП FIFO на 4 отсчёта, прерывания он получает каждые 200 циклов. Обработчик считает время и буферирует отсчёты. Когда данных наберётся полный фрейм, его отправку (с формированием суммы и т.п.) и приём встречной информации осуществляет другая задача, она же формирует из фреймов блоки, выполняет и другие действия в основном в промежутках между формированием блоков.

...

HZ> Таким образом, МК может автоматически в цикле оцифровывать данные и HZ> пересылать их из Conversion Memory в регистр данных SPI порта по байтам HZ> (активность DMA должна быть, конечно, в два раза выше, чем АЦП, т.к. HZ> пересылка ведется по половинке слова, а АЦП кладет сразу целое слово), HZ> откуда они будут отправляться хоть на скорости 4 МБода. Запуск и АЦП, и HZ> ПДП, как я уже говорил, легко организовать с помощью таймера даже в таком HZ> режиме. ПДП использует ту же шину данных, что и проц, поэтому во время HZ> пересылке по каналу ПДП проц останавливается на 2 такта. Все остальное HZ> время CPU свободен для твоих нужд - может перестраивать очередь HZ> оцифровки, может обрабатывать данные из обратного канала и т.д. И даже HZ> при полной активности его потребление не сравнится даже с PIC18, не HZ> говоря уже о dsPIC'ах.

Для того, что ты тут описал вообще никакой МК не нужен, АЦП с SPI пруд-пруди, даже с мастерным есть. Добавить счётчик перебирающий каналы и вперёд. Вот только смысла в этом нет.

...

HZ> Странные какие-то требования. Обычно если требуется что-то, то это HZ> надо выполнить, как требуется, а не настолько, насколько позволяют HZ> возможности кристалла. Если набортный АЦП МК не тянет, надо ставить HZ> внешний, а не ограничивать частоту, чтобы это можно было сделать на HZ> PIC'е.

Обычно требуется улучшить качество эксперимента и конца этим пожеланиям не будет никогда. И если пределы улучшения на данный момент диктуются доступной элементной базой (и далеко не только МК), то что уж тут поделаешь?

AG>> Снизить требования к частоте до 25 кГц и обнаружить, что целая куча МК AG>> без труда сможет её решить? И какой в этом смысл?

HZ> Ага, зато у тебя выходит большой смысл снизить частоту так, чтобы HZ> конкретный чип из семейства 18-х PIC'ов смог это сделать, дабы HZ> продемонстрировать его преимущество над всеми остальными! HZ> Hет у него преимущества даже над MSP430.

Не улавливаю логики. 2331 обеспечивает 200 KSPS без сколь-либо сложных внешних довесков. Ближайший конкурент (ATmega на 20 МГц) требует внешнего АЦП и логики мультиплексирования, кроме того будет крайне перегружен по запросам на прерывание. MSP430 требует внешнего кодека для синхронного интерфейса (который ещё не понятно как сделать) и вряд ли обеспечит управление трафиком 200 КБ/с. При всём этом данный этап пройден, я обсуждаю следующий на 400 KSPS, на котором из упоминавшихся только 2810 обеспечивает функциональное решение (возможно он может обеспечить его и на 800 KSPS), к сожалению не физическое.

HZ>>> К примеру, чем шить dsPIC?

AG>> У меня Microchip'овский PRO MATE II с модулем ICSP. Там поддержка AG>> появляется раньше чем становятся доступы кристаллы.

HZ> А скока стОит это чудо? А есть ли внутрисхемная отладка?

Нет, это просто программатор, причём дорогой (под $1000). А внутрисхемная отладка это, видимо ICD 2, но я этой штукой никогда не пользовался.

...

HZ> Во-вторых, на Altera свет клином не сошелся - есть еще, например, HZ> Xilinx, у которого есть очень хорошее семейство CPLD CoolRunner...

Это уже интересно. Например, тот же кодек для обмена по оптике через SPI сделать.