Сделал достаточно много проектов на AVR - достаточно сбалансированная "прямоугольная" линейка. Но также сделал немало проектов на C51(classic), PIC16/18, C8051F, MSP430F, ну и несколько на LPC2xxx. И в каждом случае были как объективные, так и субъективные причины выбора типа камня. Сейчас AVR переходит (если уже не перешёл), как в своё время уже перешёл C51, в разряд антиквариата. Хотя бывают причины, заставляющие их применять - как AVR, так и даже C51. Но они по большей мере либо экономические, либо организационные. Потому как у AVR по сравнению с C8051F, MSP430F, PIC24, ARM в одних нишах чисто технических преимуществ практически нет. Разве что где-то в узких задачах "короткоствольного" 5 В ногодрыганья. C8051F по скорострельности уделывает, MSP430F по потреблению, PIC24 за счёт "фичастости" и разрядности (особенно приятной ценой за ту же фичастость), ARM-ы в нише выше 7$ просто отправляют фичи AVR в мусорку. По объективным причинам из AVR пока применяю ATmega88/ATmega16/2560, по субъективным - ATmega162/128/2561. С 2560 история вышла интересная - цена камня в девайсе не является определяющей, но из ARM-ов к сожалению по имевшемуся ограничению на пиковый ток потребления 3 года назад ничего не подошло. Очень хотелось поставить LPC2378, который применяю в других проектах, но DS писал TBD и прочие невкусности (оказалось не зря боялся). Сегодня бы туда же поставил STM32 по-жирнее.
Так что стараюсь применять AVR только там, где это экономически (или иногда технически) оправдано.

А после того, как стал сам и программироать МК, разница ещё более ощутима. Когда не нужно проставлять костылики атомарности для работы с длинными переменными (например софтварными таймерами) и стесняться вольно оперировать указателями (списки, очереди, инумераторы, вызов функций по указателю) не опасаясь за нехватку ОЗУ и быстродействие, когда пара килобайт на sprintf не замечается, когда не нужно писать __flash/progchar в типе формального параметра при передаче строки, когда не стесняешься делать short FIFO для UART-ов по каких-нибудь 256 слов, когда 17 кБ ПЗУ на меню не вызывает ужаса из-за ожидаемой нехватки места... возвращаться обратно ой как невкусно.

Я на STM32 перехожу. LPC попробовал только для LCD.
Поскольку прямого перехода нет, то на остальные вопросы трудно ответить, да и не место здесь сравнивать ARMы.
Короче, правило : В новых разработках AVR не применять.

тогда просьба к пишущим указывать конкретнее информацию о своих проектах где переход с АВР дал существенные преимущества, или хотя бы направление деятельности, чтобы была какая-то точка отсчета где АВРам место, а где не место...
по потреблению где-то уже были сравнения AVR Pico/PIC/MSP, существенной разницы не обнаружилось.

по ценам - действительно почему-то именно на АВР подняли в разы, на другие контроллеры такого не наблюдается.
например в Имраде появился MC9S08QD4VSC по цене Tiny13 - памяти и периферии больше.
на Пики, MSP, C8051 цены всегда были выше АВРов.
АРМы - да, цены и возможности привлекательные. Но не могу понять почему ни в одном семействе нет нормального управления пинами - все сделано через ж..пу. То частота обновления в несколько раз занижена относительно ядра, то установка в 0 и 1 через разные регистры (чтобы установить нужный паттерн требуется несколько циклов), то странные ограничения возможностей по вводу-выводу/пуллапам/напряжениям и т.д... ну и работа с периферией/прерываниями из софта существенно сложнее.

Сообщение отредактировал ukpyr - Jun 13 2009, 11:19

Я может пропустил чего, но ман на LPC23xx гласит:



В SAM7 - аналогично (регистр PIO_ODSR описан в таблице как Read-Only, но есть примечание про то, когда он доступен на запись, так вот примечание и надо курить)

За остальных - не скажу, но видимо так же.

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



Ага, много сложнее работать, например, с ARM MAC сложнее, нежели дергать пином у AVR. Равно, как и наличиствующий котроллер прерываний, много сложнее "отсутствующего".....

Неправильная постановка вопроса. У нас до сих пор выпускаются изделия 1997/1998 г.р. на C51. При этом они прошли уже по несколько переразводок из-за правки "узких" мест (давно), изменения конструкции и прекращения выпуска некоторых корпусов микросхем. Также нами выпускаются функционально похожие девайсы на MSP430F, на 8051F, на ATmega128 и на ATmega2560. И только в одном случае был переход с пары ATmega128+AT89C51ED2 на C8051F120 (там и 130 подходит, но эти крохи не добивают) - выигрыш по потреблению составил около 15 мА - с 22 мА до 7 мА - это было важно. Причём сначала получили примерно 4 мА на C8051F020, а затем изменились требования и 64КБ уже конкретно не хватило.
Ещё есть девайс - коммуникационный контроллер, который сделан на ATmega128L+4*MAX3100 - 'оказалось, что в наших задачах больше 4-х UART-ов не востребовано, потому это чудо и 3 контроллера дискретного ввода/вывода заменяются на вариант на базе LPC2378 с хорошей прибавкой в производительности и ресурсах (а 32К ОЗУ и 60 МГц тактовая на 4-х UART со 115200 по сравнению с 4К ОЗУ и до 8 МГц у ATmega128L это многого стОит в коммуникационном контроллере) . При этом тупая замена ATmega128L на ATmega2561 выглядит как диверсия - стОит 2561 практически столько, сколько LPC2378, но 2 шт MAX3100 + контроллеры ввода/вывода + груз 8-и-битности ну никак не радуют

Мягко сказано.
Программный ШИМ на STM32 получился на порядок быстрее, хотя 24 дрыгающих ноги оказались в трех портах в малоногом корпусе.

На самом то деле проблема не в ресурсах и возможностях микроконтроллеров, а способностях и профессионализме программистов, и как результат - во времени портирования проектов с одного контроллера на другой.
Что говорить, религиозные войны между ASM и С только пару лет назад стали утихать.

Подключал дисплей по 8ми битной шине. На АРМе каждый бит (из 8ми битной шины) устанавливал индивидуально (дисплей был подключен на пробу не на один порт, а в "разброску"). В итоге получил бОльшую скорость, чем на АВРке где 8ми битная шина заведена целиком на один порт и все 8м бит выставлялись одновременно. А вы говорите ногодрыгательство у АВРок рулит... Больше не рулит. FAST-GPIO в LPC вот что теперь рулит =). Этот пост моя обьективная оценка ногодрыгательства "AVR vs LPC" в моих применениях.

Осетра надо бы урезать. Ну никак 8(записей в порт)*2(такта на запись)=16 тактов на LPC 60МГц не будут быстрее, чем 1(запись в порт)*1(тактов выполняется OUT)=1 такт на AVR 16МГц.

1) не 60 МГц а 72Мгц.
2) само-собой что мерялся не просто "сферический конь в вакууме" - просто выставление 8 бит на 8 линий, а ещё выставление чтения/записи/стробирования.
Осетра оставьте в покое, пускай растёт =)

Не ожидал от Вас .
У LPC, которые "60MHz" всего два порта, посему раскидать можно только на два и записей через FIOPIN максимум две (да-да 15MHz а не 16). Однако если, полагаю, были еще и упраляющие сигналы на 8bit шине данных, которые уже не помещаются в AVRовский порт, но свободно ложатся к арму... А данные подготовить?

P.S.
Автор несколько опередил

Сообщение отредактировал zltigo - Jun 13 2009, 14:38

Всегда когда заводится разговор о медленном ногодрыганьи ARMов у меня создаётся впечатление, что не МК ногами дрыгает, а сам пользователь собирается это делать своими двоими.
Запомните (все критикующие) простую вещь, кусок дрыганья ногами пишется один раз, а контроллер это делать никак не устанет.

Да я сам от себя такого загона не ожидал Прашу пардона...

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

TI Automotive