AVR признали !, C переходом в рассуждения о контроллерах Опции

[ozzy]

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


рис1


рис2


рис3

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

[oran-be]

Как по мне АВРы - это как виндоза с точки зрения сравнения ее с полетом на "Кукурузнике" - тошнит, а выйти некуда.
Что по нынешним временам есть в ней хорошее - это то, что их везде, как грязи, и дешево, и халявный С компилятор. ВСЕ.
По производительности PIC18 имеет АВР по полной, несмотря на в 2 раза меньшее значение MIPS. Загрузка-выгрузка все сводит на нет. Уже не говоря про обработку прерываний. АВРы на этом тормозят ваще. PIC18 и 51-е умеют переключать контекст. А 51 по нынешним временам есть Силиконовские - они имеют АВР по MIPS конкретно. И Микрочипсы заваяли новые PIC18, которые по стоимости вставляют АВРы.
Зато АВРы можно считать первым ядром, которое раскрутили не за счет его достоинства, а за счет маркетингово правильно составленных технических возможностей и документации. Одни только виртуальные ассемблерные команды чего стоят, не говоря уже о раздутой донельзя производительности. В итоге на этой маркетинговой раскрутке Атмелы воспитали, можно сказать с пеленок, целое поколение МК программеров, в которых маркетинговые штампы уже записаны на генетическом уровне и которые уже не могут видеть преимущества других ядер.
У АВРов есть еще одна хорошая черта - обилие глюков дает разработчикам повод лишний раз пообщаться(человеческим языком ). АВРы - самая плодотворная тема для общения. "АВР признали!" Удивительно! До появления АТМег8 и 16 среди АВРов вообще не было рабочих контроллеров. Для серьезных применений. Как минимум они имели тенденцию само вытираться.

[SasaVitebsk]

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

Что по нынешним временам есть в ней хорошее - это то, что их везде, как грязи, и дешево, и халявный С компилятор. ВСЕ.

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

По производительности PIC18 имеет АВР по полной, несмотря на в 2 раза меньшее значение MIPS. Загрузка-выгрузка все сводит на нет.

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

Уже не говоря про обработку прерываний. АВРы на этом тормозят ваще. PIC18 и 51-е умеют переключать контекст.

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

А 51 по нынешним временам есть Силиконовские - они имеют АВР по MIPS конкретно. И Микрочипсы заваяли новые PIC18, которые по стоимости вставляют АВРы.

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

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

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

У АВРов есть еще одна хорошая черта - обилие глюков дает разработчикам повод лишний раз пообщаться(человеческим языком ). АВРы - самая плодотворная тема для общения. "АВР признали!" Удивительно! До появления АТМег8 и 16 среди АВРов вообще не было рабочих контроллеров. Для серьезных применений. Как минимум они имели тенденцию само вытираться.

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

Девайс монтируется непосредственно у исполнительных модулей приблизительно на 40...50 Ампер.
Не знаю как AVR, а PIC18F работает достаточно устойчиво вот уже порядка трех лет в нескольких сотнях девайсов.

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

12F683 - ADPCM декодер (ADPCM симметричный, поэтому что кодер, что декодер ...) + I2C программный + wavetable синтез - пожарный извещатель (нужен голос и сирена). На Си, без особого напряга и хитростей, 8 МГц внутренний генератор. ШИМ правда аппаратный, но и программный бы туда влез на раз. [поправил] - не, наверное не влез бы

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


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

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

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

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

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

[zltigo]

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

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