Изделие массовое, соотношение цена - ресурсы МК критичное.

Вот стоим на распутье: ресурсов ATMEGA не хватает ,присматриваемся к PIC24,LPC21** ждем ATXMEGA.

Кто переводил свои проекты с AVR на ARM какая плотность кода получается при компиляции типовых задач (не "заточенных" под конкретную архитектуру процессора) ?


Скажем для примера возьмем компилятор IAR для AVR и ARM, ARM в THUMB режиме.

Экономить в ARMе на плотности кода примерно то же, что и в AVR на кол-ве регистров. Зачем спрашивается? Начиная с двух долларов ARM уже выгоднее AVRa. Менее 2 долларов при изготовлении устройств в размере не менее 1000 штук AVR может оказаться выгоднее по цене в очень несложных устройствах. А вот при малых партиях - тут уж программист пусть подумает сколько стоит его время и его профессионализм.

ЗЫ. Вопрос поставлен изначально неверно. Даже в самом дешёвом LPC памяти больше, чем в AVR за ту же цену.

e_ol
Переводил 67 кБ прошивку (из них 5 кБ констант) с Mega128 (CVAVR) на AT91SAM7S128 (IAR, Thumb); общий размер уменьшился до 54 кБ. Пример, впрочем, несколько некорректный - второй вариант был переписан под uC/OS-II (+2,4 кБ), поэтому общая структура программы упростилась. Так или иначе, в режиме Thumb код получается заметно плотнее AVR, за счет большей разрядности регистров (арифметика, указатели), гибкой адресации памяти, коротких прологов/эпилогов подпрограмм.

Плотность ещё и от самого кода зависит. Например обращение к полям упакованных структур раздувает код в АRM больше чем в 4 раза.

У меня при переносе кода с AVR на ARM в THUMB режиме полоучилось примерно тот же самый объём(даже для ARM немного меньше получилось ), в ARM режиме процентов на 25 больше.

Компиляторы
avr-gcc 4.2.1 и arm-elf-gcc 4.2.2 соответсвенно. Оптимизация -Os (максимальное сжатие по коду)

З.Ы. Ну естественно так как я побил все дериктивы pack, то размер используемого RAM для ARM также вырос.

Cortex (STM32, Luminary) интересны, если рассматривать эту самую плотность. Сам столкнулся с резким изменением подходов к программированию всвязи с отсутствием довлеющей нехватки ОЗУ. В результате многие задачи стали решаться значительно меньшими затратами как по тексту, так и по реальному объёму кода.

Очень многое завист от назначения и необходимой разрядности данных.
Если хватает 8 битной арифметики и надо дергать ногами. То плотность кода у АВР естественно будет несравнимо выше, а код проще и понятнее. Но вот если надо борабатывать хотя бы 12 битное ацп... на АРМ уже гораздо удобнее будет.

Я проект с LPC2214 переносил на m128. Размер кода к моему удивлению принципиально не снизился. Вот другое дело - avr показался мне устойчивее. На плате стоит хостовый LPC и периферийная мега. При мощных помехах LPC загибается. Спасает только внешний вачдог. АВР ни разу не отказывал. Думаю LPC затактировать от генератора.

Для начала, мне до сих пор не встречалось AVR-овских исходников НЕ ЗАТОЧЕНЫХ под его архитектуру - обилие жестко забитых 8bit переменных - очень нехилая заточка под архитектуру . Даже небольшая подчистка кода под естсественные int дает заметную экономию и размера и быстродействия. Заданный вопрос не нов - поищите в форуме предыдущие ответы, но они будут в том-же ключе. Чем действительно стоит озаботится, так это размером RAM.

Ну не знаю, за других не в ответе. У меня 2 тайпдефа, UREG и REG, соответственно, беззнаковый и знаковый, оптимально лезущий в регистр. Переносится без проблем, никакого оверхеда.

Это для локальных переменных. А для полей структур - там пофиг, по большому счету, что LDR, что LDRB например, только надо за выравниванием следить и особо не извращаться.

Ну если LPC,это поминаемый Вами LPC22xx c внешней шиной на которой висит RAM/ROM и все это по традиции на 2x слойной плате спроектированой без опыта шаманства со скростными девайсами на двуслойных платах, то это совершенно "нормально" . Кроме того,какое отношение Ваша реплика имеет к заданному вопросу?

Правильно. Плюс разрядность упрощает любой мало-мальски вычислительный алгоритм.
Поэтому лично я с 8-битниками, кроме Cygnal - и то только за их хорошие АЦП/ЦАП и скорость - завязал. Время 8-битных AVR прошло. А 32-битный AVR - не факт, что выживет, они c ним скорее всего опоздали.

Я не знаю, что это у Вас (у меня тоже есть bint - и никаких проблем, а int_least.. вообще стандарнты, но Вы их часто видите в AVR исходниках??? ), но настоятельно рекомендую посмотреть, что получается, если на массовые расходные переменные (безразлично регистровыми они станут или нет) накладывать исскусственное ограничение в 8bit (unsigned char) пришедшее с AVR.

Я знаю. Просто ужасно Поэтому за этим слежу в своих исходниках.

А по подробней об этом можно?

Компилятор просто начнет "делать" из 32-х битного процессора восьмибитный, с соответствующим оверхедом.