STM32 размер программы

DISCLAIMER: все ниже описанное носит субъективный характер и не претендует на точность
Не я один наверное слышал, что по размерам код для ARM вылазит сильно больше чем для восьмибитников, особенно если делать все через функции стандартных библиотек. Вот собрал два примера один для Atmega128 другой для STM32F100RBT6 (Discovery) везде оптимизация -O2, чтобы посмотреть разницу. Подробности далее.
Примеры не просто поморгать светодиодиком, а мои любимые усарты с модубасом. Как говорится почувствуйте разницу. Не хочу пока вдаваться в большие подробности, что да как т.к. опыта пока маловато, но разница почти в 2 раза в пользу AVR меня лично информирует, что на STM32 надо брать флэш пожирнее раза в два по сравнению с AVR. Но как оказалось не все так плохо и не все так хорошо CooСox выдал на оптимизации -O3… код размером больше на 20% чем на -O2 и если посмотреть в папке проекта в папки Debug/bin то там еще лежат файлы без отладочной информации (release тобишь) .bin и .hex для прошивки программатором. Файл .bin получился размером 4896 байт (против 3190 байт для AVR) что не так плохо.



повиднее:



Кокос

   [cc] 10 total files to be compiled.
       [cc] "C:/CooCox/CoIDE\gcc\Sourcery G++ Lite\bin\arm-none-eabi-gcc" -mcpu=cortex-m3 -mthumb -Wall -ffunction-sections -O2 -g3 -c -DSTM32F10X_MD_VL -DUSE_STDPERIPH_DRIVER -D__ASSEMBLY__ -DSTM32F100RB -IC:\CooCox\CoIDE\workspace\discovery_modbus\cmsis -IC:\CooCox\CoIDE\workspace\discovery_modbus\cmsis_boot -IC:\CooCox\CoIDE\workspace\discovery_modbus\stm_lib\inc -IC:\CooCox\CoIDE\workspace\discovery_modbus\stm_lib -IC:\CooCox\CoIDE\workspace\discovery_modbus C:\CooCox\CoIDE\workspace\discovery_modbus\stm_lib\src\stm32f10x_tim.c C:\CooCox\CoIDE\workspace\discovery_modbus\cmsis_boot\startup\startup_stm32f10x_md_vl.c C:\CooCox\CoIDE\workspace\discovery_modbus\cmsis\core_cm3.c C:\CooCox\CoIDE\workspace\discovery_modbus\cmsis_boot\system_stm32f10x.c C:\CooCox\CoIDE\workspace\discovery_modbus\stm_lib\src\stm32f10x_gpio.c C:\CooCox\CoIDE\workspace\discovery_modbus\main.c C:\CooCox\CoIDE\workspace\discovery_modbus\modbus_slave.c C:\CooCox\CoIDE\workspace\discovery_modbus\stm_lib\src\stm32f10x_rcc.c C:\CooCox\CoIDE\workspace\discovery_modbus\stm_lib\src\stm32f10x_usart.c C:\CooCox\CoIDE\workspace\discovery_modbus\stm_lib\src\misc.c
       [cc] Starting link
       [cc] "C:/CooCox/CoIDE\gcc\Sourcery G++ Lite\bin\arm-none-eabi-gcc" -O2 -nostartfiles -Wl,-Map=discovery_modbus.map -mcpu=cortex-m3 -mthumb -LC:\CooCox\CoIDE\workspace\discovery_modbus -Wl,--gc-sections -Wl,-TC:\CooCox\CoIDE\workspace\discovery_modbus\link.ld -g -o discovery_modbus.elf ..\obj\stm32f10x_tim.o ..\obj\startup_stm32f10x_md_vl.o ..\obj\core_cm3.o ..\obj\system_stm32f10x.o ..\obj\stm32f10x_gpio.o ..\obj\main.o ..\obj\modbus_slave.o ..\obj\stm32f10x_rcc.o ..\obj\stm32f10x_usart.o ..\obj\misc.o
Program Size:
      text	   data	    bss	    dec	    hex	filename
      4876	     20	   1804	   6700	   1a2c	discovery_modbus.elf


AVR Studio

avr-gcc  -mmcu=atmega128 -Wall -gdwarf-2      -DF_CPU=16000000UL -O2 -fsigned-char -fpack-struct -MD -MP -MT controller.o -MF dep/controller.o.d  -c  ../controller.c
avr-gcc -mmcu=atmega128 -Wl,-Map=controller3.map controller.o modbus_slave.o usart.o    -lm  -o controller3.elf
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  controller3.elf controller3.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex controller3.elf controller3.eep || exit 0
avr-objdump -h -S controller3.elf > controller3.lss

AVR Memory Usage
----------------
Device: atmega128

Program:    3190 bytes (2.4% Full)
(.text + .data + .bootloader)

Data:        782 bytes (19.1% Full)
(.data + .bss + .noinit)


зы Пардон что не вовремя нажал опубликовать

  • 0
  • 25 августа 2011, 15:42
  • GYUR22

Комментарии (55)

RSS свернуть / развернуть
а картинку надо обязательно в микроскоп разглядывать?
Вопросы:
-компилятор для AVR? для STM?
-уровни оптимизации?
-debug или release?
-как и какие линкуются библиотеки к STM?

далеко не так все просто
0
Мой соколиный глаз видит -O0 по крайней мере в последней строке. Так что да — опции компиляции в студию.
0
плюс я более чем уверен, что это Debug версия с включенными в объектник отладочным символами. Пострипать их и будет раза в 2 меньше
0
Размер прошивки от дебажной информации в объектнике не зависит.
0
пардон не ту картинку прибил там 2раза щас дополню
0
Хм… Атмега 8-битная, Кортекс — 32-х. Лично я не вижу здесь несоответствия. ИМХО так и должно быть.
0
это с чего? все зависит от задачи, и очень тяжело адекватно сравнить их.
0
Ну, мне казалось что в 32-битных каждая инструкция «больше весит». Хотя у меня опыта в этом не было.
0
Да, не ща более или менее нормально.
Да и аврка хоть и восьми битная, но большинство инструкций имеют размер 16 бит. В то же время армы имеют набор инструкций размером в 16-бит. Т.е. можно сказать что не имеет значения арм или авр ;)
0
У 32-х битников шина адреса-то потолще поди будет. А указатели тоже хранить надо и их может быть много.
0
У кортексов смешанный 16/32 бит набор же. Ну и адреса тоже, кстати. Если где-то юзаются константы длиннее байта — их тоже надо хранить. Ну и библиотеки свою долю возьмут при их использовании, но это уже не в счет, т.к. с ними программы уже не одинаковые и эксперимент некорректен. И еще сказывается большая сложность периферии.
Если интересует именно плотность кода — лучше проверять на алгоритмах, без всякой инициализации, библиотек и работы с железом.
0
Не так все просто. В кортексах система команд Thumb2, а она очень плотна, так что сильно результат вырастать не должен (если в нем нет большого количества констант и инициализованных массивов — на что намекает размер секции .bss).
0
я не претендую на объективность информации, просто меня мучил этот вопрос и я попытался получить ответ
ps массивов нигде нет оптимизация я писал одинаковая.
0
тогда уж выдели только флешку, а не общий объем.
0
это флешка кокос ram не показывает пока…
0
ziblog.ru/wp-content/uploads/2011/01/e814fc868e88.gif
и оптимизацию можно -Os
0
а можно проектик для стм на мыло? попробую собрать, гляну что получится.
0
we.easyelectronics.ru/attachments/get/227
это он — тока оптимизацию проверьте
0
Чет у меня получилось, вот так
думаю можно сильно сократить используя макросы для работы с IO вместо библиотечных функций, и будет лучше чем на авр :)

— text data bss dec hex filename
3568 20 980 4568 11d8 target/target.elf
0
так и уменя тоже почти так вышло «Файл .bin получился размером 4896 байт (против 3190 байт для AVR) „
0
но аврке я думаю ножками дергаешь не функциями :)
0
Когда я игрался с стм32, правда под кейлом, то на максимальной оптимизации он вызовы библиотечных функций по дерганью ножек всегда инлайнил.
0
Тогда я не понимаю размера секции .bss — там хранятся только статические переменные и величины, что надо инициализовать нулями. Вы все же покажите полные командные строки компиляции — не обязательно скриншотом — можно и текстом :).
0
В Release скомпилируйте оба проекта
0
я написал в конце размера релиза для кокоса а для авр это релиз
0
релиз и пострипаный дебаг это не одно и то же. У GCC более стони разных ключей, влияющих на работу оптимизатора и лично мне неизвестно, какие из них применяются в Debug, а какие в Release в данном конкретном случае
0
у AVR студии нет как таковых опций debug /release — выкинул опцию dwarf ничего не изменилось

зы ни разу на авр не пользовался отладчиком на арме фиг без него чего либо кроме моргания вышло бы…
0
зы ни разу на авр не пользовался отладчиком на арме фиг без него чего либо кроме моргания вышло бы…
Ой ли? Скорее это из-за того, что на AVR проще по старинке отлаживать, чем через тормозной жтаг. А на STM32 доступна нормальная отладка, и естественно начинаешь ей пользоваться везде, в том числе и тем, где на АВр просто потупил бы в код.
Опять же, а симулятором на авр ты пользовался? Это тоже отладчик.
0
нет и симулятором (с целью отладки) тоже не пользовался — была куча примеров и аналитическое тупление.
зы пользовался только протеусом штобы чтонито не паять а побыстрому глянуть моргает нужная нога или нет
0
Ну видимо или задачи простые были или пользоваться дебагом неудобно было. А с дискавери это как на ПК — жмакнул Download&Run и отлаживайся в своей удовольствие.
0
Не совсем так. Просто на авр все достаточно просто заводилось — ну то чем я пользовался и почти все примеры у меня заработали сразу — их много было по инету и можно было выбрать. А у стм32 пока всетаки экоситема пока еще не такая широкая.
0
А я писал с нуля и с отладкой поплясал. Поюзать успел и тупление в код, и тупление в асм, и говносимулятор микропаскаля, и жтаг. Сделал пару выводов:
1) Микропаскаль дрянь
2) Жтаг — редкий тормоз
0
я тоже сравнивал стм дискавери и атмегу 8-мь :)
и по скорости в флоатинг поинт
и по размеру кода
арм в два раза более надутый код генерит… особенно инициализация библиотечная…
а скорость… как Вы думаете во сколько раз больше или меньше?
в полтора раз апри той же частоте… другое дело что дискаверю запросто на 52 мегагерца можно газануть… а мегу на 20-ти не всегда запустиш
radiokot.ru/forum/viewtopic.php?f=20&t=50361 — тема с моим сравнением
clawham.hopto.org/DriveD/PubD/66/MVI_8188.AVI 500 метров видик для наглядности
0
я читал ваши посты вот решил сам учудить
0
Я с другой ветки.
Так в чем было дело с I2C?
У меня почему-то не заводится I2C на stm32f105 для внешней EEPROM. — такая же фигня — виснет контроллер.
0
ответил в теме
0
имхо сравнение некорректное — вычислять float на AVR это мазохизм. 99% вычислительных задач на АВР можно свести к целочисленной арифметике (даже Фурье и т.п.).
0
Смотря какие вы задачи выполняете на МК.Вы же понимаете что мигать светодиодом на ARM «дороже» чем на AVR или тех же x51.Ну и как было сказано выше код инструкции у АВР и АРМ отличаются по объему. На одну инструкцию АРМ может приходится 2 и более инструкции АВР. Чет- странное получилось что код на АВР меньше чем на АРМ. Поправьте если не прав.
0
  • avatar
  • Zov
  • 25 августа 2011, 17:21
я ещё переписал тот код теста на авр под иаром и на арм под иаром… тоесть по идее одинаковые компиляторы… а разницы нет… кодвижн меньше кушает оперативки и больше флеши программ а иар немного экономит флеш программную но тратит капец как стэк… ну не суть важна… скорость у арма в синусах и флотингпоинтах в полтора раза больше при той же частоте… при этом код в 2-3 раза больше + функции инициализации библиотечные нужно юхать с опаской…
0
>> CooСox выдал на оптимизации -O3… код размером больше на 20% чем на -O2

Это нормально, по крайней мере, если у него название опций оптимизатора соответствует gcc-шным. O1, O2, O3 — это оптимизация по скорости, так что ничего странного, в том что код в O3 больше нет, это совершенно закономерно — разворачиваются циклы, инлайнятся функции и тд.
Оптимизация по размеру включается по -Os
0
Оно не то чтоб соответствует, это и есть GCC. Кстати да, что будет если оптимизировать по размеру?
Ну и в принципе, размер компенсируется количеством флеша. Даже на дешевом мк на дискавери — 128к памяти, а атмега128 стоит столько, что я ее вообще как вариант для покупки не рассматриваю.
0
Оптимизация по размеру не всегда дает самый оптимальный по размеру код :) Выставленная по умолчанию О2 более рациональна для применения.
0
А можно подробнее о режимах оптимизации O1, O2, O3?
0
Оптимизация по скорости, первый, второй и третий уровни. ЧТо конкретно на каком включается надо смотреть мануал на GCC. На третьем вроде повышается риск порчи программы оптимизатором. Плюс есть отдельный флажок enable-expensive-optimizations, но что он делает — хз.
Чтобы оптимизировало по размеру — Os. Нинай тока есть ли смысл указывать одновременно -O1 -Os, но где-то я такое видел.
0
Я просто тут в своем проекте под Keil попробовал включить оптимизацию с 0 на 01 и получил разницу:
Program Size: Code=19100 RO-data=924 RW-data=276 ZI-data=988 -режим 00
Program Size: Code=14896 RO-data=924 RW-data=212 ZI-data=964 -режим 01

А если в режиме 00 включаю оптимизацию по Времени то размер кода не меняется
0
Я бы смотрел на это так: При увеличении разрядности с 8 бит до 32 бит, объем увеличился всего в 2 раза!
Вообще рассмотренный вопрос сродни подщету тактов для выполнения кода на конвеерной системе. Да, пощитать конечно можно, то это будет не достоверной величиной, а грубой оценкой. 20% или в 2 раза — не суть важно. Огромное значение имеет используемый оптимизатор. А учитывая что компании «продвигают» кортексы, то можно ожидать то оптимизаторы станут повыше уровнем.

За проведённые же исследования спасибо.
0
И у авр и у стм32 длина команды — 16 бит.
8 и 32 бита — это размер регистров.
0
Ну, во первых, Thumb2 имеет команды переменной длины — 2 или 4 байта. И 4-байтовых у него больше, чем у AVR. Во вторых, константы (особенно адреса) — длиннее соответственно размеру регистра/адресной шины. А так ничего вроде больше особо влиять и не должно — у ARM довольно эффективный набор команд.
На x86_64 программы тоже пухнут по сравнению с x86, хотя средняя длина команд примерно та же.
0
Я имел в виду, что разница в длине команд не в 4 раза:)
0
Дык и в размере кода не в 4. Ну и увеличение разрядности х86 в пару раз (см. выше) раздувает ехе в 1.5-2 раза.
0
Для х86_64 самое проблемное место — оперативная память (винты и так вместительные, потому размер кода пофигу). На использование стека там выходит что то вроде более чем в 2 раза больше кушает. Проблема с резервированием места под регистры связана. А под размер кода что-то даже и не слышал ни от кого жалоб :)
0
А под размер кода что-то даже и не слышал ни от кого жалоб :)
Потому что всем пофигу, ага. Хотя он сказывается, когда дело доходит до таких милых вещей как кэш т т.д. Но я отмечал сам факт увеличения размера программы при изменении битности.
0
Хм… Даже если бы по скорости STM32 и AVR на одной частоте были бы одинаковы я все равно за STM32, так как — цена при очень богатой функционально периферии плюс разрядность для вычислений и много разных доступных средств отладки. А так к примеру STM32F100RB у нас можно купить за 24гр. в то время как ATmega128-16AU стоит 54гр, выбор очевиден :) Для быдло фанатов атмеля которые несмотря не на что остаются православно-верными ATMEGE порекомендую поискать стену.
0
тоже не понимаю всенародной любви к AVR (хотя сам с него начинал). 8 бит уже вчерашний день.
0
у ARM уж больно мелкие корпуса -лутом тяжело платы делать надо уже фоторезистом или заказывать
а это уже несколько другой уровень
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.