[sensor_ua 0]

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

[DogPawlowa 0]

P.S. А Вы, Уважаемые коллеги, чем заменяете полюбившиеся AVRки? (с какого конкретно камня на какой конкретно перешли, какие проблеммы возникли, как их решали, почему сделали переход, какие плюсы получили от перехода, что потратили, что сэкономили)

Я на STM32 перехожу. LPC попробовал только для LCD.

Поскольку прямого перехода нет, то на остальные вопросы трудно ответить, да и не место здесь сравнивать ARMы.

Короче, правило : В новых разработках AVR не применять.

[ukpyr 0]

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

по потреблению где-то уже были сравнения AVR Pico/PIC/MSP, существенной разницы не обнаружилось.

 

по ценам - действительно почему-то именно на АВР подняли в разы, на другие контроллеры такого не наблюдается.

например в Имраде появился MC9S08QD4VSC по цене Tiny13 - памяти и периферии больше.

на Пики, MSP, C8051 цены всегда были выше АВРов.

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

Изменено 13 июня, 2009 пользователем ukpyr

[Rst7 5]

чтобы установить нужный паттерн требуется несколько циклов

 

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

 

FIOPIN:

Fast Port Pin value register using FIOMASK. The current state

of digital port pins can be read from this register, regardless of

pin direction or alternate function selection (as long as pins are

not configured as an input to ADC). The value read is masked

by ANDing with inverted FIOMASK. Writing to this register

places corresponding values in all bits enabled by zeros in

FIOMASK.

 

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

 

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

[zltigo 2]

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

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

 

 

ну и работа с периферией/прерываниями из софта существенно сложнее.

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

[sensor_ua 0]

просьба к пишущим указывать конкретнее информацию о своих проектах где переход с АВР дал существенные преимущества

Неправильная постановка вопроса. У нас до сих пор выпускаются изделия 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-и-битности ну никак не радуют;)

[DogPawlowa 0]

. Даже тем, кто ни о чем кроме ногодрыгания ни о чем не беспокоится, есть о чем немножко задуматься.

Мягко сказано.

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

 

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

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

[Petka 0]

Но не могу понять почему ни в одном семействе нет нормального управления пинами - все сделано через ж..пу. То частота обновления в несколько раз занижена относительно ядра, то установка в 0 и 1 через разные регистры (чтобы установить нужный паттерн требуется несколько циклов), то странные ограничения возможностей по вводу-выводу/пуллапам/напряжениям и т.д... ну и работа с периферией/прерываниями из софта существенно сложнее.

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

[Rst7 5]

В итоге получил бОльшую скорость, чем на АВРке где 8ми битная шина заведена целиком на один порт и все 8м бит выставлялись одновременно.

 

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

[Petka 0]

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

1) не 60 МГц а 72Мгц.

2) само-собой что мерялся не просто "сферический конь в вакууме" - просто выставление 8 бит на 8 линий, а ещё выставление чтения/записи/стробирования.

Осетра оставьте в покое, пускай растёт =)

[zltigo 2]

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

Не ожидал от Вас :(.

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

 

P.S.

Автор несколько опередил :)

Изменено 13 июня, 2009 пользователем zltigo

[IgorKossak 0]

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

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

[Rst7 5]

Не ожидал от Вас .

 

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

[777777 0]

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

[sensor_ua 0]

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

TI Automotive