Дайте тогда ссылку на ваши бенчмарки... Я на сахаре только это нашел




Своими доходами?

Так даже с Вами мне слабо померяться по причине разной оплаты в Киеве и в Первой Столице... Мои $600 в Харькове ни о чем по киевским меркам...

Тут где-то была мерялка (опрос), она показывала к чему можно стремиться..
Но она уже устаревшая..

Кого это интересует, если программа вмещается и работает :-)

Вот во что я не упирался - так это в недостаток оперативки! В пямять программ - да, бывало. Приходилось оптимизировать алгоритмы и структуры программ.
А вот на 8515 - таки раз уперся именно в оперативку, пришлось часть флеша для епрома для редко используемых данных использовать.




Не знаю что утверждает ефайнд, (тем более "ру", нам они в Китае нужны а не в "ру"), а 819е под текущие проекты мы брали по 0.8, сейчас меняем их на 690-й, пока количеств анебольше - берем по 1.20, потом обещают по той же цене что и 819-е.
Но количества не тысяча а существенно больше.

тут они
имхо пора сделать религиозные подфорумы : Микроконтроллерные войны , С vs ASM .... во как )

Всё не нашол, вот только что. Но там ещё было.
http://caxapa.ru/68211.html?todo=full

А ФИР лежит в разделе Беньччморки. Для унсигнед операндов. Там, правда, его на пару-тройку тактов ускорить можно. Но с арифметикой супротив АВРа ПИКу(16,18, поф) ловить нечего - пролёт в разы. И чем длиннее арифметика, тем разов больше. Особенно, если умножение и операнды знаковые.

Дык, свой, согласованный и утвержденный тест будем делать или нет?

Когда-то, один мой знакомый "эмбеддед дизайнер", на вопрос "какие МК ты больше любишь?", ответил что он их все одинаково ненавидит

Ваша войнушка и меня раззадорила(:-). Посмотрел бенчмарки в пустыне. Перво-наперво, надо сказать, сравниваются разные компиляторы на разном железе.

Самый простой тест требует переноса содержимого 64-байтного массива A[64] сначала в массив B[64], а затем из массива B[64] в массив C[64]. Решил попробовать написать свой код на ассемблере для нескольких процов, вот что получилось

Код

процессор    частота    сахара-бенчмарк ассемблер
атмега       (20 МГц)     5300 тактов      900
pic18f242    (10 МГц)     3321 такт        650
pic18f242    (10 МГц)     8652 такта       650
tms320f2812 (150 МГц)      762 такта        40

То есть, если писать на ассемблере, то очевидно, что на данном тесте pic18 на 30% быстрее, чем атмега.

Для интересующихся ниже приведены фрагменты программ

;Фрагмент для атмеги

Код

movblk:  ld     temp,x+ ;2
         st     y+,temp ;2
         dec    counter ;1
         brne   movblk  ;2/1

;Пересылка одного байта выполняется за 7 тактов

;Фрагмент для пика

Код

movblk   movf   postinc0;1
         movwf  postinc1;1
         decfsz counter  ;1/2/3
         goto   movblk  ;2

;Пересылка одного байта выполняется за 5 тактов

А если вот так:

Код

movblk   movff   postinc0,postinc1;2
         decfsz contin  ;1/2/3
         goto   movblk  ;2
contin

Хотя сути это не меняет, но позволяет исключить рабочий регистр W.

Чето я не пойму. Этот пост:



и этот:



Оба ваши... Как понимать?



10 МГц у пичка подразумевает 40 (из-за PLL)?

Ну да не суть. Обычно задача копирования массивов не стоит (а если стоит, то имеет смысл пересмотреть алгоритм).

По поводу теста - я уже предложил простенькую функцию (CRC16), но ее отвергли, без особых аргументов...

Так не пойдёт, в этой команде нельзя применять косвенную адресацию. Так, как вы написали, вы просто N раз копируете из адреса postinc0 в ячейку по адресу postinc1.

GM & Прохожий.

Господа, давайте разберемся уж до конца:

Выдержка из даташита на PIC18F4450

All single-word instructions are executed in a single
instruction cycle, unless a conditional test is true or the
program counter is changed as a result of the instruction.
In these cases, the execution takes two instruction
cycles with the additional instruction cycle(s) executed
as a NOP.
The double-word instructions execute in two instruction
cycles.
One instruction cycle consists of four oscillator periods.
Thus, for an oscillator frequency of 4 MHz, the normal
instruction execution time is 1 μs.

Теперь давайте приведем к общему знаменателю машинные циклы, обзовем их CYC.
На одинаковой частоте CYCavr = 1/4 * CYCpic
С учетом, что PIC18 работает на 10-12Mhz, а Mega - 16-20Mhz,

CYCavr = 12/20 * 1/4 CYCpic

12/20/4 = 0.15 - это соотношение одного микрочиповского цикла, к AVR'овскому. (Тобиш коэффициент который показывает насколько "быстрее" выполняется одна инструкция на PIC в сравнении с AVR).

Ну а далее смотрим на результат тестов:

5 машинных циклов на микрочипе делим на коеффициент 0.15

получаем

5/0.15 = 33.33 машинных цикла AVR

33.33 AVRовских такта на PIC, против 7 на AVR.

33.33/7 = ~5
На простеньком тесте, PIC уделали в пять раз.

Вывод - по производительности PIC18 фтопку.
Banchmark'и сахары - туда же (особливо если для тестов там использовался IAR 2.2).

Насчёт противостояния ПИКов и AVRок я заметил следующую закономерность. Когда готовил свой дипломный проект у меня был доступ к дипломам прошлых лет. В старых дипломах львиная доля проектов была выполнена на ПИКах, гораздо меньше MCS-51. В новых работах за последние несколько лет практически сплошняком идут AVRки. О чём это говорит, подрастает новое поколение которое прийдя на предприятия будет закладывать в свои устройства уже AVR. И это уже просходит, просматривая вакансии нередко можно встретить требование опыта работы с AVR, ПИКи практически не встречаются. На предприятии где я работаю, для управления силовыми схемами используются исключительно AVR, они же входят в состав изделий поставляемых на АвтоВАЗ.

Это говорит о том, что если 8bit AVR в своей массе уже добрались до студенческих "работ", то надо смотреть что нужо использовать в реальной работе вместо них . Шутка, конечно, но с большой долей истины.

Вывод неверный, потому как внутренняя частота внутри PIC18F может быть умножена на 4 за счет внутреннего PLL. PICи с USB (типа 18F4550) брать в расчет не будем. Итого 10 Мгц *4(это PLL)/4(число циклов в команде)=10мгц. Т.е. минимальное время выполнения команды в PIC18 составляет 100 нс против 50 нс в AVR. Далее, подсчитав число циклов в варианте для AVR получаем 7*50=350 нс. Для варианта с PIC имеем 100*5=500 нс. Берем соотношение 500/350=1.43. Вывод: для этого конкретного примера AVR оказался быстрее PIC в 1.43 раза.
Преимущество незначительное, ели учесть все неудобства, связанные с эксплуатацией AVRов.

Не, так плохо. Под рукой описание на PIC18F2240, буду опираться на него, думаю в PIC18F4450 похожее положение дел. Давайте положим свои предпочтения в карман и рассмотрим по справедливости. (Сам я предпочитаю иметь дело с авр, мне нравится система команд, хотя и не без недостатков).

1) Потреблениие прямо пропорционально тактовой частоте, на которой работает ядро (системная частота процессора). Так что лучше сравнивать в машинных циклах (МЦ). Ну посудите сами, вы на МК PIC18F2240 подаёте 10 МГц, а они там умножаются на 4, получается 40, но одна команда выполняется за 4 периода частоты 40, т.е. системная частота равна 10. Вывод - сравнение только МЦ.

2) По производительности. Для атмеловского фрагмента время исполнения 900/20=45мкс, для пика - 650/10=65 мкс. Времена выполнения одного порядка, никакого выигрыша по производительности в 5 раз нету и в помине.

3) Давайте скажем по справедливости, что на данном тесте пик обходит авр по машинным циклам. Представьте себе, что завтра микрочипы сделают системную частоту 20 Мгц. Ну и кто будет в проигрыше?

4) Вот тут предлагали посчитать crc на одном и другом проце, давайте посмотрим, кто там будет впереди?

Я лично склоняюсь все к тем же 24-м PICам, потому как 18-е уже надоели. Слишком много неудобств. AVR - не вариант.
Хотя почти все японские фирмы (OMRON, например) в своих промышленных покидухах применяют в основном NEC в различных вариантах в зависимости от назначания покидухи.
Хотелось бы узнать мнение уважаемого коллектива. Если не PIC18 и не AVR, то что?

Ок прощу прощения что не учел PLL.


Преимущество довольно значительное, если взять во внимание простоту теста.

Еще, помоему код получился неравнозначным.
Халтурка-с



этот код копирует counter байт из x в y






А этот что делает?

postinc0, postinc1 - адреса намертво вшиваемые в тело команд.


Безусловно, ведь PIC в данном тесте не выполняет того функционала который делает AVR. Результат кода (который выиграл по маш. циклам) будет отличаться от того, который проиграл.
Давайте вначале подправим тест?


Что будет завтра - это уже другой вопрос..
Завтра может Atmel PLL засунет и запустит ядро на 40Mhz или 80..

По остальным пунктам, думаю ответил выше.

Найдутся и "фанаты" MSP430. Я, например, его использовал довольно много, но как-то "душа не лежит". PIC24 по первому впечатлению на него похож... Думаю, не надо делать из конкретного микроконтроллера (или семейства) культа. Фанатичная привязанность ограничивает кругозор в ущерб результату. Подбирать надо по задаче, а не задачу под контроллер...

Как раз преимущества по машинным циклам нет, наоборот. У меня на вход TMS320F2808 подаётся 20 МГц, но внутри они умножаются на 10 и делятся на 2, какую частоту мне брать для определения производительности? 20, 100 или 200 МГц?

Не, это вы халтурно относитесь к пику(:-). Регистр POSTINCn это аналог регистра INDFn, только с постинкрементом.

На си примерно так будет *(postinc1)++ =*(postinc0)++

А почему тогда не ARM?


Понял ;>


Частоту ядра конечно. В вашем случае - 100.
Для PIC'а если с 4xPLL'ом - 40Mhz, но приводить к какому-то эталону все равно надо. Приводят к MIPS'aм, и в ДШ на PIC должно быть написано - ядро PIC на 40Mhz имеет производительность 10MIPS.

Опять же неправда Ваша. PostincХ - это ссылка на виртуальный системный регистр с аналогичным именем, означающая что исполнительный адрес берется из пары FSRXH:FSRXL и после выполнения команды к этому делу будет прибавлена 1. Следовательно в указанном случае пересылка осуществляется следующим образом:
Байт данных, расположенный по адресу FSR0H:FSR0L перешлется в ячейку по адресу FSR1H:FSR1L, затем регистровые пары FSR0H:FSR0L и FSR1H:FSR1L будут инкрементированы. И все это дело повторится изначальное (при входе в цикл) counter раз.

Сильно зависит от задачи. Я долго работал с TMS320C5402, клял эти проклятые пайплайновые конфликты, потом перешёл на TMS320F2808..12. Ну, скажу я вам, небо и земля. И управление легко делать, подрыгать ногами, и ДПФ быстро, 16*16 умножает за такт, 32*32 за два такта, и периферии до чёрта: CAN, SPI, I2C, ADC 12.5 Мвыборок/с. Почти мечта(:-). Сейчас новые представители семейства появились, так там есть модуль плавающей точки...

Буквально. Как Тузик порвёт сковородку, так ПИК порвёт АВРа в арифметике. ;О)

Прохожему: На сахаре, в беньчморках лежит ФИР, писаный мной на АСМе. С тактами. Можете написать аналогичное на ПИКе и посчитать. Во сколько раз медленнее оно будет. Да и здесь, в АВРовой ветке, есть то-же самое, только знаковая арифметика.

По поводу пересылок: пересылка массива памяти, сама по себе, никому не нужна. Нахрен пересылать массив из одного места в другое, если работать можно сразу в том месте? Ну да ланна, это на любителя. ;О)


Ну согласитесь, сравниватьТМС320 с ПИКо-АВРами некорректно. И не только из-за ТМСовой крутизны. ПИКо-АВРы требуют вокруг себя меньше обвязки, меньше жрут, меньше занимают места. Стоят дешевле. Из этого и исходить. Лёгкое ядро, оно всегда себе дырочку найдёт. ;О)

Вот одна страничка в которой утверждается что начинка ericsson а1018 на базе авр :
http://www.hackcanada.com/blackcrawl/cell/texts/charger.pdf

правда чип вроде бы кастом.

Известный выводок T39/R520 и остальные из того ряда - тоже AVR (в смысле, ядро AVR, периферия другая).

GM, давайте чуть чуть усложним задачку.
Пусть есть два 64 байтных массива A[64] и B[64],
а в массив С[64] будем писать типа С[i] = A[i] (&, | или ^) B[i];
И оценим скорость на пике и авр как в машинных циклах, так и реальное время
выполнение на максимальной частоте кристала.

Кстати задачка не высосана из пальца а вполне реально необходимая при
обслуживании Modbus.

P.S. Кстати, эта задачка также хороша для религиозной
войны IAR vs WinAVR

Здесь вопрос достаточно сложный. Из первого знакомства с ARM вынес следующее:
1. Дорогая среда разработки (EWARM от IAR).
2. Отсутствие хорошего бесплатного компилятора С (сам не пробовал, но отзывы о GCC не очень лестные).
3. Дорогостоящее оборудование для отладки.
4. Излишне сложная система команд (привычка начинать знакомство с Ассемблера).
Прошу учесть, что это мое личное мнение, не претендующее на абсолютную истинность.

Лукавите

Одного поля ягода с так называемым WinAVR, который, как я понимаю, 'устраивает'.

-Для любительско/халявных вариантов Wiggler дорогостоящ ?
-клоны профессиональных стоят одинаково - в пределах десятков долларов.
-оригинальные - несколько сотен для любого из контроллеров.

Привычка на данном историческом этапе 'дурная' - ARM контроллер при сопоставимых ценах с AVR девайс другой весовой категории. С ASM начинать не надо. Бегло просматривать результат компиляции, изредка писать пару десятков команд безусловно надо, но плотно изучать и начинать писать вполне достаточно в процессе работы и постфактум.

Всё что я пишу ниже, мой взгляд на данную тему.


Так это "ВСЁ", уважаемый, два из моих 5 пунктов. А третий (производительность на СИ) вы переврали, в чём вас тут же и уличили.


Это совершенно неверный вывод. Видимо вы не работали по другому. Либо не интересовались исследованиями в данной области. Для 90% вычислений будет достаточно регистров РОН имеющихся у AVR. Загрузка и выгрузка применяется крайне редко. Если не верите, то проанализируйте любую программу на AVR. Причём компилятор Си от IAR прекрасно этим пользуется.


За Pic говорить не буду, но контекст x51 это всего 8 регистров.А рабочих - 8. Никто не мешает в AVR распределить регистры тем же способом. Вообще переключение контекста не понадобится!!! То есть данный постулат - откровенный бред. (по x51)


По стоимости и доставабельности AVR и вообще Atmel в России и СНГ - вне конкуренции. Здесь они просто молодцы. В других странах судя по отчётам motorolla лидирует.


На момент перехода на AVR, я лично, не читал ни одной рекламной статьи. Более того существовало не более 10 кристаллов. За минусом 1200(12МГц) все остальные работали до 8МГц. На сайте Atmel - писали "повышения тактовой частоты в будущем не планируется". Я перешёл только из-за того, что писал на АСМе и даже слепому, вопреки вашему утверждению, видно что архитектура на голову выше. Выбрал я их поиском. Оценивал очень разные (К примеру PIC и Scenic). Читал сразу даташит. Что касается "виртуальных комманд", то это широко распространнённая практика ещё с исторических времён. И впервые её использовали сами программисты. На 8080 вместо CLR A использовали xor a,a. Не вижу здесь злого умысла. Очень удобно. Не каждый знает эти "фокусы", но если есть соответствующая мнемоника, то лучше использовать tst a, чем or a,a , как мы это делали на 8080.

По поводу серьёзных применений с вами бессмысленно спорить. Безусловно применение МК вами - серьёзно, а мной - несерьёзно.


На форуме Точки опоры один человек утверждал, что его мега128 управляет станком искрорезки. Установлена в 20см от самой искры и работает прекрасно. Ни единого сбоя. И тоже год или что-то возле этого. Я могу привести пример, подтверждённый документально, что мои изделия в количестве 40 штук поставили на замену днепропетровским. По причине, что мои за неделю тестирования не зависли ни разу, а днепропетровские за два дня повисали практически все. Мои на меге днепропетровские на пике. (Причина - помехи) Но это не повод ругать пики. Это повод ругать программеров и схемотехников.


На меге 8 на 16МГц я вводил/выводил сигнал битовый поток на 32кГц и вводил/выводил байтовый поток на 8кГц. Фактически транскодер ИКМ в АДИКМ и обратно. Попутно делал 12 цифровых фильтров. Естественно "внутри" сигнал был 16-ти битный. Конкуренты на PICе так и не смогли повторить. Их изделие использовало 2 PIC 16 + дополнительную микруху с фильтрами.


И сравнивать производительность надо всётаки именно на СИ. Причина проста. На СИ пишут большенство программистов. Таким образом "кривизна" компилятора как раз имеет значение в конечном устройстве. Так почему я не должен её учитывать при выборе? Отсутствие хорошего компилятора - это серьёзный минус. Отсутствие бесплатного - ещё один. Невозможность использования библиотек, написанных под GNU - третий. Отсутствие портов для популярных ОСей - для некоторых (например zltigo ) - просто смерть данного семейства.




Всётаки задачка высосана из пальца, потому что правильнее всётаки минимум два массива (B и С) формировать одновременно во время приёма B. И лишних пересылок, при этом не будет.

К стати, скажу по секрету, что для обслуживания любой шины, связанной с USART, AVR подходит несколько лучше, чем PIC. Это связано с тем, что в AVR реализован аппаратный контроль четности, а в PIC - нет.
Скажите (действительно интересно), а где при обслуживании MODBUS требуются такие действия?
Что же касается теста, то для PIC будет приблизительно следующее:

Получилось 6 МЦ или 600 нс при частоте кварца 10 МГц и включенном PLL.

Лично я способен и сам оси оптимальные с точки зрения нужной мне функциональности писать, что и проделывал неоднократно . И использовать и модифицировать 'непопулярные' тоже могу. И портировать 'популярные' могу. И без осей могу, но уже последние лет 15-17 это крайне редко делаю - опыт, однако.
Так-что поминать меня всуе не надо

Ну заметно плохих компиляторов уже пожалуй нет - вымерли, динозавры
А бесплатность - пусть лучше будет уверенность с развитии и соответственно в том, что компилятор не станет аутсайдером.
Ибо плата даже за 'дорогой' компилятор вполне сопоставима c месячной зарплатой программиста, даже уже в Российских условиях.

Так я и не сравнивал! Я отвечал г.Прохожему

Нисколько.


Ну Вам виднее. Я лично не пользовался ни тем, ни другим.


Дело в том, что я как бы любитель, поэтому в данном случае речь идет о моих личных материальных средствах. С PIC все ясно. Купил ICD2 за 6000 руб и, в принципе, можешь заниматься любым контроллером от 18-го до 24-го. Можно даже позволить себе и REAL ICE за 16 000 руб.
Это, практически, все затраты, поскольку все остальное официально халявное.


Боязно как-то отдавать все на откуп дядям, написавшим компилятор и компоновщик. Хотя может быть я и не прав.

Неа, не прокатит, если в массиве есть многобайтовые значения, то сначала прием всего
пакета, а только потом операции над данными.
Для многобайтовых значений, в А[] часть байтов многобайтового значения может
поменяться между приемами в B[], соответственно в С[] получим полный бардак.
Но вобще то это совсем другая тема,
я просто предложил чуть усложнить задачку

P.S. Вот интересно, Вы предпочитаете AVR и я то же.
Это что, начало спора IAR vs WinAVR ?

Есть также Keil, RealView, CrossWorks..
Keil и CrossWorks дружат с gcc тулчейном.


Для PIC'ов насколько я осведомлен тоже не густо в этом плане.
Общепризнанный лучший компилятор от HT и он небесплатный..


Wiggler $10-$15
J-Link клон - сопоставим по цене с ICD2


~40 мнемоник.
даже меньше чем у новых PIC.


нет проблем, просто может быть вас просто дезинформировали.
Загляните в АРМы

Не сообразил ответить сразу, отвечу здесь.

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


За пик г.Прохожий уже ответил, 6 МЦ. У авра, увы, будет 10 МЦ. Так что разрыв увеличивается(:-(.

Так глядишь, с вашей лёгкой руки я стану экспертом по пикам, а я в них не особо петрю, плаваю короче(:-)...

В тестовой программе пересылки быть должны. Естественно, массовые пересылки массивов это зачастую неудачое решение задачи, но и сводить решаемые контроллерами задачи к обработке чисто синхронных потоков явно неправильно - это вообще отмирающаяя область применения контроллеров
общего назначения, ибо с этим много легче справляются дешевеющие FPGA или на худой конец не отстающие от них по динамике цен DSP. То, что для меня является привычно/обычной задачей для небольшого перефирийного контроллера - можете, хотя-бы мельком, глянуть, что из себя представляют телекоммуникационные протоколы. Ну для конкретности пусть будут протоколы 2 уровня семиуровневой модели OSI - LAPD/LAPV5/MTP2/...) Без буферизации и пересылок там никуда. Как впрочем и без 'осей' с их задачами и очередями сообщений и таймерам все это писать чистое извращенное и ненадежное решение.

Вобще-то по стандарту, над любыми данными должны быть реализованы четыре
варианта действий: REP, OR, AND и XOR.
Конечно мало кто это реализует в своих контроллерах, но по стандарту нужно, особенно
если присутствуют железки или софт сторонних производителей.
Не знал что там есть 3 "виртуальных" счетчика.
Тогда да, разницы почти нет, по машинным циклам выигрывает пик, по реальной
скорости авр.
А какой пик ? Интересно глянуть.

Для конкретности - затраты, например J-Link за примерно те-же 250USD или вообще его клон, баксов за 70 и можно заниматься любыми ARMx любых производителей.
Можно, конечно, покруче и подороже - J-Trace. Только зачем? Ядро отлаживать? Я вообще совсем не представляю, каким местом отладчика я буду отлаживать, например, поминаемый ранее LAPD. Я вообще не представляю для чего внутрисхемный отладчик для подавляющего большинства случаев отладки хоть сколь-нибудь сложных задач.

Например, pic18f2220.

Там ещё есть "страшная" команда movff var1,var2. Напрямую пересылает значение из переменной var1 в переменную var2, требует ДВА машинных цикла. У авр аналогом будет пара команд lds/sts, ЧЕТЫРЕ машинных цикла плюс использование РОН.

Дык и я плаваю, мое знакомство с пиками ограничилось знакомством, в
свое время, с каким-то(уже не помню каким) представителем 16 семейства, ну
и вот тут недавно пришлось на PIC10 малюсенькую задачку набросать.

А вот это из даташита на PIC:
All single-word instructions are executed in a single instruction cycle.
........
One instruction cycle consists of four oscillator periods.

в свое время меня отвратило от подробного изучения пик(и был выбран авр).
Чуйствую, в чем-то дурят




Дык все равно паритет по реальной скорости выполнения...
А использование РОН, ну ведь принципиально разные модели процов...

Я тоже нашел RIDE по ссылке от ST. Даже приделал туда GCC. Попробовал тестовую программку. Вроде на вскидку все хорошо. Но, все равно, как-то боязно.


Зато MCC18 бесплатный. Меня лично он полностью устраивает. Код проверялся по ассемблерному листингу. Ничего особо криминального обнаружено не было. А все глюки выгребаются правильным размещением данных. По большому счету, оптимизация кода там и нафиг не нужна.


А корпуса? У большинства ноги через 0.65 мм. Если руки кривые, то прототип изготовить практически невозможно.


Дык, у i 486 тоже как бы 40 мнемоник, зато вариантов... ARM из той же оперы, поскольку создавался как альтернатива.


Может быть Вы и правы. Надо будет поплотнее заняться ARMами. Но лично мне кажется, что и в 24 PICах что-то есть позитивное.


Спасибо за информацию. Вполне вероятно, что придется разориться на обозначенную сумму. Хотя ICD2 у меня уже есть.


А посмотреть, чего там в реальности напринималось в буфер? Или что творится с АЦП?

Тема оказывается актуальная, судя по быстрому росту.
Все же тестирование нужно провести. Полученные результаты будут гораздо объективнее, чем заявления "порвет как тузик". Задача должна быть простая, но все же не в три команды.
Предлагаю такую - вычисляем сумму байт и среднее арифметическое 300 байтного массива. размерность в 300 байт заставит применить честное деление, а не ограничиться сдвигами. Ну и результат суммирования будет иметь возможность превысить 16бит. Т.е. будут и работа с памятью и арифметика.
Итак, в одном углу ринга разминается Мега8. Найдется ли у нее соперник...
Взвешивание (цена ) будет проведено после боя

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

Я заметил одну вещь. Никакое МК ядро не имеет столь фанатично преданных поклонников, как ядро АВР. Причем, повторюсь, в основном это те, кто сразу с него начал, либо те, кто еще не успел присесть на другие ядра. Остальные же, кто реально работает с несколькими типами МК, обычно не испытывают особого восторга от АВР. Что-то хорошо, что-то плохо. То же самое они обычно и говорят про другие типы МК, даже про те, с которых начинали. В чем же причина фанатизма?
Есть идея. Всем приверженцам АВРов собраться и пойти в ветку PICов, или 51-х, или сразу в обе и устроить там, открыв парочку горячих тем. А то там что-то скучновато.

А если честное умножнеме? :О)

Тема на самом деле ниочем. То, что авры ставят куда не лень - известно давно.
Что касается достоинств и недостатков - можно спорить бесконечно, но на самом деле все упирается в то, какая перед вами стоит задача. Я вот например программировал 5 ядер мк - Pic, z80, 8051, avr и arm у всех есть свои области применения, свои плюсы и минусы... но без привязки к конкретной задаче все споры будут спорами ни о чем. Если вы хотите получить самый дешевый микроконтроллер например - то берите вообще holtek - от 37 центов... вот только с его программированием возникнут сложности у неопытного программиста. Если хотите сократить сроки разработки - берите avr - в сети масса готовых решений, взяв из которых куски кода и добавив немного своего можно решить любую задачу (если конечно она вообще реализуема на данном ядре)

Ну, не хочу развивать религиозного фанатизьма, однако, в моём списке PIC отсутсвует.
Присутствуют COP, 48, 51, AVR. Когда-то передо мной стоял выбор между PIC и AVR, решён был в сторону AVR, поскольку в то время за сравнимые деньги можно было купить AVR с FLASH, а PIC только OTP, такой же кристалл PIC с FLASH был на порядок дороже. А поскольку к тому времени я уже изрядно наелся внутрисхемных эмуляторов и эмуляторов ПЗУ, PIC как-то сам собой отвалился.
С тех пор я просто не вижу надобности вводить себе в мозг ещё одну архитектуру.

Что касается пресловутого теста с FIR. Непонятно, почему там PIC24 DSPIC и AVR. Почему нету ARM? Ведь его тоже Atmel делает.

Тема действительно ни о чем! Для каждой задачи можно выбрать свой МК. Не важно какай марки и фирмы изготовителя, главное чтобы он оптимально справлялся с поставленной задачей и программист знал как это реализовать.
А кто с чем работает наверное в большей степени зависит от того, что выбрано в начале. Переход на другой тип МК обусловлен старением архитектуры.
Я, например, начинал с 51 и перешел на AVR из-за цены и объема предоставляемой памяти и переферии. И сейчас перешел на ARM. На PIC переходить не вижу смысла, т.к. для решения текущих задач этой базы вполне достаточно.