насколько я понял много занимает либа таймеров?

У тебя дофига занимают функции стдлиба - работы с арифметикой с плавающей точкой всякие принтфы. Уверен, что в "просто дерганье ногой" они нужны ? -))

----------
7010 474 306 0 100 0 Library Totals
26 0 1 0 4 0 (incl. Padding)

да и с переферией работа чтото очень жирная

620 40 0 0 0 0 stm32f10x_gpio.o
188 18 0 0 0 0 stm32f10x_pwr.o
732 52 0 20 0 0 stm32f10x_rcc.o
272 28 0 0 0 0 stm32f10x_rtc.o
2670 84 0 0 0 0 stm32f10x_tim.o
816 20 0 0 0 0 stm32f10x_usart.o
296 28 0 20 0 0 system_stm32f10x.o


у меня IAR из stellarisware насосал только
driverlib.a: [4]
cpu.o 16
ethernet.o 288
flash.o 176
gpio.o 276
interrupt.o 124
sysctl.o 908
systick.o 40
uart.o 176
----------
Total: 2 004

У тебя компил то релизовый, не дебаг ?

Если говорить о Cortex-M (а речь идёт именно о нём, а не о Cortex-A или -R), то самого главного "признака АРМа" в нём как раз и нет: эти процессоры не поддерживают "родную" систему команд ARM, а используют исключительно Thumb-2, которая впервые появилась в версии ARMv4T (ядра ARM7 с буквой T).

Признаки какого арма ? АРМы - это отнюдь не только app-процессоры для установки winCE/linux'а.
ARM7TDMI поддерживал и Thumb, и нативный режим, а что толку ? На кортексах Thumb2 оставили, т.к. шустрее и компактнее нативного кода получилось для микроконтрллерных применений.

конечно не этовот...не комильфо..но принтф не столько занимает много....вот разве инициализация таймеров....походу он компилит в выход ВСЁ что только попало в либу!!! даже если я не вызывал этих функций....
при разных настройках оптимизации получается или 15600 кода или двадцать КИЛОВ!!! это чтото уж чересчур....

ну а по поводу периферии..ну так я инициализирую питание бекап домена, инициализирую РТЦ, инициализирую ugbj? инициализирую прерывания, инициализирую частоты, инициализирую таймера, ну и уарт....
мож кая-то директива прагмовская есть не включать неюзанные коды в прошивку?

насчет Arm против Avr на арм.ком хорошая страничка есть

http://www.arm.com/products/processors/ ... tex-m0.php

по тестам размер кода в 2 раза МЕНЬШЕ авра, с умножением и так было понятно, что получится.

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

Кстати говоря, вся эта история с развитием АРМов фактически показала ошибочность изначальной концепции RISC-процессоров: использование только простых инструкций фиксированной длины в противовес "медленным и сложным" CISC'ам. Хотя само название АРМ прямо говорит, что это РИСК-архитектура, на сегодняшний день от этой концепции почти ничего не осталось. Система команд постоянно разбухала и усложнялась, ну а с появлением Тумбы-2 отказались от предпоследней особенности РИСКа -- кодирования любой команды фиксированным числом разрядов (родные АРМовские команды занимают всегда 32 бита, что часто избыточно -- вот и лишний расход памяти; команды Тумбы всегда занимают 16 бит -- а это сильно ограничивает гибкость; в итоге пришли к тому, что в Тумбе-2 применяется переменная длина команды -- 16 или 32-разряда). Последним признаком РИСК-архитектуры в АРМах остаётся только их неспособность выполнять операции регистр-память (и тем более память-память): сначала изволь всё нужное загрузить в регистры.

Ну а возвращаясь к Кортеху-М... В общем-то, использование более компактной кодировки в микроконтроллерах однозначно оправданнее. Флэш-память по сравнению с ОЗУ -- вещь медленная, поэтому вполне возможна ситуация, что алгоритмически (т.е. по числу необходимых инструкций для решения задачи) более медленная, но более компактная система команд (Тумба) на практике будет работать быстрей, чем алгоритмически более быстрая, но неэкономная в плане памяти (АРМ). Если не изменяет память, у АТМЕЛовских АРМв4 (AT91SAM7...) частота выборки из флэш-памяти была раза в два меньше, чем максимальная частота собственно процессорного ядра, причём за каждый такт из флэша выбиралось всего одно слово -- т.е. одна команда АРМ или же Тумбы. Если я прав, то получается, что эти процессоры почти за одно и то же время выполняли либо одну команду АРМ, либо две Тумбы, что, понятное дело, выгоднее. Так что ориентация именно на расширенную Тумбу в Кортехах-М вполне закономерно и оправданно. В микропроцессорах ситуация сложней. Программы там гоняют из ОЗУ, а не из флэш-памяти; кроме того, у них обычно достаточно приличный объём кэша. Тем не менее, расход этого самого кэша на громоздкую систему команд АРМ существенно выше, чем на Тумбу, поэтому не факт, что программа на АРМе будет однозначно быстрей, чем на Тумбе. Думается, тут очень сильно зависит от эффективности транслятора (ну или умений программиста, если программа пишется на ассемблере): сумеет ли он воспользоваться всей гибкостью системы команд АРМ.

Что касается сравнения АРМа и АВР8, то с технической точки зрения первый безусловно выгодней и по скорости, и по памяти. Например, простой, но часто встречающийся на практике случай: сложение или вычитание 32-разрядных целых чисел. На АВР8 в общем случае для этого потребуется 16 команд (8 загрузок из памяти, 4 сложения/вычитания, 4 записи в память), которые займут 32 байта. На АРМе -- 4 команды (2 загрузки, одно сложение/вычитание и одна запись), 16 байт. На Тумбе -- те же 4 команды, но уже 8 байт. Если рассматривать 16-разрядное сложение/вычитание, то у АВР8 число команд сократится вдвое (8 команд, 16 байт), у АРМа останется тем же самым -- 4 команды и 16/8 байт, что как минимум не хуже по памяти и уж точно лучше по скорости.

У АВР8 больше регистров (32 против реально 13 у АРМа -- ещё 3 имеют специальное назначение; у Тумбы и вовсе свободно можно использовать только , но у АРМа они в 4 раза "толще", что при сколько-нибудь сложных расчётах безусловно предпочтительней. Кроме того, АРМовские регистры универсальнее (так, в АВР8 результат умножения всегда кладётся в R0:R1; для чтения-записи с автоинкрементом или автодекрементом можно использовать только три пары из шести последних регистров, ну и т.д.; у АРМа все 13 регистров равноправны).

В общем, получается, что программа под АРМ должна занимать меньше памяти и работать существенно быстрей. Почему на практике так получается далеко не всегда, надо разбираться. Возможно, компилятор и компоновщик тащат в выполняемый файл всё подряд, а не только то, что нужно. Может также быть, что под АВР8 используется компилятор Си, а вот АРМ -- Си++, и последний порождает кучу ненужной в данном случае фигни для ООП, обработки исключений и т.д. и т.п. В общем, надо тщательно разбираться в параметрах трансляторов и компоновщиков, а заодно изучить код, который получен в результате: по крайней мере, станет понятно, что же именно столько места сожрало. Наконец, стоит помнить, что подготовка АРМа к работе намного сложней (куча периферии, ПЛЛ и т.д. и т.п.) -- а это тоже память. Так что, думается, наиболее правильный подход -- сравнение размера именно "целевых" функций, которые, собственно, и выполняют полезную работу. В тестовых задачах их объём может быть невелик по сравнению с инициализационным кодом, вот и создаётся впечатление, что АРМ менее эффективен по памяти. Но если задача крупная, то вся эта инициализация будет занимать лишь небольшой размер по сравнению с объёмом в целом -- и там можно увидеть реальную картину.

avr , имей совесть !!! В Элитане сей кит 483 рубля...
http://www.elitan.ru/price/index.php?se ... +Discovery

Топикстартеру могу сказать только одно : атмел - это диагноз , ни в коем случае не слазьте с них, если уж вы начали сравнивать их с arm .

спасиб за разьяснения..впринципе я как-то так и предполагал что ну не может математика так много занимать..попробую перетащить всё в иар с нуля накалякать....посмотрим что там...толи этот мой кейл чтото не то лепит толи я ему чтото не то говорю ..как-то вот неделю его колупаю и никак не могу разобраться с его настройками...в иаре настроек просто туча...посмотрим

Да, запустил я Keil, оказывается был он у меня.
То, что мне показалось, что по гибкости настроек близок к IAR - это я, мягко говоря, погорячился -))))
Keil какой то для новичков чтоли. Настроек минимум, мастеров максимум.
Тот же мастер подкинул мне шаблонный стартап в котором таблица прерывания забитая хенделрами практически на все возможные прерывания, которые при компиле видимо всасываются из библиотек при том, что ты эту периферию и соотв. обработку прерываний от них вообще пользовать не собираешься.
Если попользоваться мастером и руками не почистить, возможно там пустая прога пол флеша займет, если МК простенький.

Это точно. Именно по этому надо слезать до конца, раз удалось заглянуть за пределы этого порочного круга.

Прошу ногами сильно не пинать ибо за кейл я серъезно взялся только вчера. Простейший пример мигания светодиодом из встроенной справки. При компиляции выдает объем занимаемой памяти:

Идем в настройки: Project->Options for Target1. Далее тыкаем галку Use MicroLib, снова компилируем:

Видно, что объем кода и занимаемых данных сильно уменьшился. Возможно вам следует тоже попробовать такую опцию.

Далее, идем в файл system_stm32f10x_cl.c, и наблюдаем следующую картину:

У меня есть подозрения, что все эти IF-ы тупо переписываются во флеш-память.

Нуу, если так рассуждать, то да. Все, что кортексы - и M, и А - не "армы".


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


Насколько помню, все АРМ МК что видел имель флешку работающую с вейтстейтами уже после ~35МГц.
Но многие последние жирные ARM7TDMI имели механизмы предвыборки. Классика 128битная шина флеша и 128битный буфер предвыборки. Если код идет последовательно, то никаких задержек.


конвеер там один. сколько б не навыбирали, выполняется всеравно 1 комманда.


АРМ сам рекомендует на кортексах-А пользовать именно Тумб2


А что толку? или на асме писать (да еще в голове эти 32 регистра держать), или на сях редко какой компилятор пользует хоть половину из них


Нет смылса рассуждать, если компиляторы вобще разные разных контор

Тэксь....Ребятушки знавцы...
создал я тут в иаре ту же прогу с теми же либами и т.д.

результат убивает
1) если без оптимизации вообще то код получается 22 килобайта!!! и при этом некоректно работает(на экране появились какие-то посторонние символы...)...частота в прерывании не меряется корректно и т.д. и ооооченнььь медленно работает
2) если включить максимальную оптимизацию на размер - получается 13 килобайт кода и оно всё работает очень красиво НО....скорость 14000 и не выше...при том же кварце системе код просто скопипастил!!!!!!
3) оптимизация максимум сбалансированно - 14300 тыщ вычислений и 15 килобайт кода.... всё работает коректно
4) максимальная скорость....впринципе некоректно работает и в кейле НО...в кейле работает экран и скорость реально 16000 становится....а в иаре вообще не инициализируется экран...не рабоатет прерываание ( лампочка не моргает)....вообще некоректность видать все пустые циклы ожидания повыкидывал....

ИТОГО.....КЕИЛ РУЛИТ!
хоть и срёт файлами - надо просто красиво свои файлы пораскладывать по папкам
НО делает не сильно раздутый код на макс оптимизации и даёт производительность на 6% больше!!!!!!!!!!! правда помоему кушает больше рамы...кстати из тех 1800 байт оперативки - 1000 это стек....впрочем в иаре аналогиично! но там рамы закушано 1200

КЕИЛ на макс оптимизации

15200 проходов по синусу

КЕИЛ на мин оптимизации

141700 проходов



ИАР на макс балансед оптимизации

14300 проходов

ИАР на минимальной оптимизации не работает коректно - два лишних символа на экране - скорость 12000 !!!!
а вот на средней оптимизации нормально работает

результат 13800 проходов по синусу в секунду!!!

Вывод?
- экономим - иар
- скорость Кеил

да ещё одно наблюдение...
у меня машинка старичек...
Soket939 разогнанный до 533 мегагерц DDR рама и проц до 3.2 гигагерц в винраре одно ядро 720 показывает
винт 4хсамс250 Stripe raid 500 мегабайт в секунду чтения/записи

проект в кеиле пересобирается с 47 секунд с нажатия рекомпиле алл до начала загрузки в камень проги секунд и 15-20 секунд по ф7
проект в ИАРЕ делается аж 10 секунд...пересборка полная...и 1-2 секунды по ф7

прошивка таргета везде одинакова

вот и выводы....

я остановлюсь на иаре....мне меньше рамы и большая возможность контроля компилера линковщика и т.д. важнее будет...

ну и исходники проектов -
http://clawham.hopto.org/DriveD/PubD/66/

Тут Вы ошибаетесь. Кортех-А -- натуральный АРМ, поскольку имеет систему команд АРМ, его системную архитектуру и т.д. (другое дело, что сильно расширен, но, тем не менее, совместим).



О чём и речь. Хотя, если на первом плане стоит производительность, то лучше "настоящий" ЦИСК, только не такой, как ИА-32, а нормальный (например, древний VAX-11). Как показал опыт Интела, даже неудачную систему команд (того самого ИА-32) можно быстро декодировать и превращать в последовательность простых операций, причём выполнять несколько команд одновременно, за счёт чего и достигается очень высокая пиковая производительность. Другое дело, что при этом, мягко говоря, страдает энергопотребление, но тут уж надо выбирать, что важней для конкретной задачи.



Кажись, у атмеловских нет такого механизма, но утверждать не буду... Вот у NXP LPC24xx есть, поэтому он на полной скорости может работать (до 72 МГц).



Дело не в конвейере. Представьте, что у этого АРМа используется 32-разрядная флэш-память, способная работать с частотой до 30 МГц, а процессорное ядро может работать до 60 МГц. На частотах до 30 МГц флэш будет успевать выдавать для процессора код команды, а на частотах свыше 30 -- уже нет, нужно вводить такты ожидания. Поскольку каждая команда АРМ имеет длину 32 бита, процессор сможет их исполнять лишь с частотой 30 МГц, даже если сам "заведён" на 60 МГц: флэшка просто не будет успевать ему выдавать команды. Но если он исполняет команды Тумбы, он будет работать на полной частоте, ведь каждое считанное из флэшки 32-разрядное слово будет содержать две команды, на выполнение которых процессору потребуется два такта, в течение которых флэша успеет выдать очередное 32-разрядное слово и т.д. В итоге и получаем, что на системе команд Тумб такой процессор будет работать быстрей, чем на АРМ.



Сам вот всё собираюсь её внимательно посмотреть, но руки не доходят: по работе занят с более древними армами (АРМв4 и АРМв5)...



Ну, прошлую задачу на асме на АВР8 и писал. Си, во-первых, терпеть не могу (сплошной рассадник ошибок), а во-вторых, не влезла б в память, а менять контроллер -- проблема (аппарат в серийном производстве уже был, только функционал всё расползался). Для интереса посмотрел микроПаскаль: компилятор вообще никакой; похоже, изначально он был написан для 8051, и логика работы в лоб содрана на АВРки. Большое число регистров реально не используется, все операции производятся в одном регистре (Р16), ну и т.д...



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

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

Если с разными настройками оптимизации работает/не работает - то это ошибка в коде/таймингах.

например, вот это:

void delay_ms(int Dly)
{
int a=0;
int b=0;
for(a=0;a<Dly;a++)
{
for(b=0;b<450;b++)
{
//c++;
}
}
}

void delay_us(int Dly)
{
int a=0;
for(a=0;a<Dly;a++)
{

}
}

рекомендую посмотреть в асме что получается при компиле с оптимизацией -)))

У меня IAR такие циклы с полной оптимизации по скорости выкидывает даже если внутри не просто декремент а какие нибудь условия которые по его мнению бесполезны(например проверка переменной которая обновляется по приему UART в прерывании, а компилер считает что переменная всегда равна 0 например и не видит как во время цикла она может изменится поэтому и выкидывает) поэтому если этот цикл действительно необходим приходится в него вставлять что нибудь другое, бесполезное с точки зрения программы но не компилятора, для исполнения.

Поэтому Вы совершенно правы, нельзя бездумно пользоваться оптимизацией не разобравшись хотя бы примерно как компилятор ее проводит. Рулят прямые руки и понимание работы компилятора

В вашем случае они пока "не рулят", компилятор всего лишь делает, то что вы ему говорите.
Если ваша переменная обновляется в прерываниях или вы делаете задержку, то просто объявите переменную с volatile и будем вам счастье. Читайте доку...

Не нужно резкостей, не один Вы знаете про volatile, что по Вашему я полный идиот? Переменная так и объявлена, но тем не менее IAR этот цикл выкидывает, точнее даже так проверку которая в цикле он выполняет но только один раз и выходит из цикла.

----------

Эх... зря я ввязался, я неправ, все, Аминь.