В общем получили мы новые приборы от Dynisco (кто не знает серъезная контора, занимается датчиками давления и сопутствующей електроникой http://www.dynisco.com/)
открываем и видем :


рис1


рис2


рис3

Коллеги Ваши мнения ?

Известный выводок 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. Я вообще не представляю для чего внутрисхемный отладчик для подавляющего большинства случаев отладки хоть сколь-нибудь сложных задач.