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

Вот стоим на распутье: ресурсов 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-х битного процессора восьмибитный, с соответствующим оверхедом.

Вообще, не должен, но делает. Т.к. в системе команд ARM команда LDRB автоматически расширяет число до 32 бит.

А если бы не расширяла - легче было бы? Сделайте ++ с переменной типа unsigned char, и в листинге получите примерно такую картину:

И так во всем.

Для примера сложение двух 32-битных чисел на 8-битном uC.
Требуется:
- 4 сложения
- 6 сложений переносов
- SWAPы, т.к. регистров не хватает.

Расширять то она расширяет. Только компилятор обязан при, например, выполнении char a=b+2 и b=254 обеспечить 0 в а, а не 256 (если тупо расширить), вот отсюда он и генерит сбросы старших битов. А если еще и signed char, то вообще мраки начинаются...

Это я тоже заметил. Просто компиляторы пока недостаточно умные. Дело в том, какую логическую и арифметическую операцию не делай в 32-битном регистре со значимыми только 8-ми битами, результат будет правильный если отбросить старшие биты только под конец. А если учесть что STRB сама отбрасывает эти лишние биты, то я в недоумении.

Только при смешивании байта и большей байта переменной требуется сбросить лишние биты, ИМХО.

Деление только нельзя. Однако аппаратной команды деления в АРМе нет. И со сдвигами надо быть осторожным. А больше я никаких подводных камней не вижу.

Да тоже самое что и unsigned char, просто сдвиг другой для unsigned используется пара LSL/LSR а для signed LSL/ASR.

Вообще что бы код хорошо работал и на ARM и на AVR, я все локальные переменные объявляю uint_fast8_t, и все операции с переменными которые в памяти делаю через временные локальные объявленные как uint_fast8_t. Тогда все нормально загрузка идет через LDRB, а промежуточные операции все 32 битные (на ARM)
Тут главное помнить что uint_fast8_t может быть больше 8 бит....
примерно так

Да, собственно, никакого. Просто поделился впечатлением.

Реальное шаманство. А всего-то надо было в первой строке исправить тип переменной с char на int.

Тестировал LPC2132 (без внешней шины) на предмет помехоустойчивости. С помощью искроподжигателя газа (применяющегося в котельных) так и не смог подвесить проц. Даже когда искра (мощная) происходила в 3 см от процессора. Плата простая двухсторонняя.

Ага и получить код занимающий в 2 раза больше места и работающий в 2 раза медленнее на АВР

Ну уже писали же, что нужно предопределять типы, удобные для процессора на котором компилится проект. Их исправить-то несколько секунд надо. И больше не шаманить.

А у меня дивайс управляет электромагнитными защелками через реле. Если диод не поставить - гарантированно виснет. Причем внутренний вачдог бывает не помогает. Но это несомненно проблема конструкции.

если переопределить типы тогда это отразится на требуемом размере памяти (для арм). Не зря в стандарте С99 есть все эти типы.

Тестировал свое устройство на помехоустойчивость.. Электрошокером в 2-3 см искру пускал. Все работало отлично. Проц 2142