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

Не я один наверное слышал, что по размерам код для 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
а картинку надо обязательно в микроскоп разглядывать?
Вопросы:
-компилятор для AVR? для STM?
-уровни оптимизации?
-debug или release?
-как и какие линкуются библиотеки к STM?
далеко не так все просто
Вопросы:
-компилятор для AVR? для STM?
-уровни оптимизации?
-debug или release?
-как и какие линкуются библиотеки к STM?
далеко не так все просто
- marvin_yorke
- 25 августа 2011, 15:51
- ↓
Ну, мне казалось что в 32-битных каждая инструкция «больше весит». Хотя у меня опыта в этом не было.
Да, не ща более или менее нормально.
Да и аврка хоть и восьми битная, но большинство инструкций имеют размер 16 бит. В то же время армы имеют набор инструкций размером в 16-бит. Т.е. можно сказать что не имеет значения арм или авр ;)
Да и аврка хоть и восьми битная, но большинство инструкций имеют размер 16 бит. В то же время армы имеют набор инструкций размером в 16-бит. Т.е. можно сказать что не имеет значения арм или авр ;)
У кортексов смешанный 16/32 бит набор же. Ну и адреса тоже, кстати. Если где-то юзаются константы длиннее байта — их тоже надо хранить. Ну и библиотеки свою долю возьмут при их использовании, но это уже не в счет, т.к. с ними программы уже не одинаковые и эксперимент некорректен. И еще сказывается большая сложность периферии.
Если интересует именно плотность кода — лучше проверять на алгоритмах, без всякой инициализации, библиотек и работы с железом.
Если интересует именно плотность кода — лучше проверять на алгоритмах, без всякой инициализации, библиотек и работы с железом.
Не так все просто. В кортексах система команд Thumb2, а она очень плотна, так что сильно результат вырастать не должен (если в нем нет большого количества констант и инициализованных массивов — на что намекает размер секции .bss).
я не претендую на объективность информации, просто меня мучил этот вопрос и я попытался получить ответ
ps массивов нигде нет оптимизация я писал одинаковая.
ps массивов нигде нет оптимизация я писал одинаковая.
ziblog.ru/wp-content/uploads/2011/01/e814fc868e88.gif
и оптимизацию можно -Os
и оптимизацию можно -Os
релиз и пострипаный дебаг это не одно и то же. У GCC более стони разных ключей, влияющих на работу оптимизатора и лично мне неизвестно, какие из них применяются в Debug, а какие в Release в данном конкретном случае
- marvin_yorke
- 25 августа 2011, 17:00
- ↑
- ↓
у AVR студии нет как таковых опций debug /release — выкинул опцию dwarf ничего не изменилось
зы ни разу на авр не пользовался отладчиком на арме фиг без него чего либо кроме моргания вышло бы…
зы ни разу на авр не пользовался отладчиком на арме фиг без него чего либо кроме моргания вышло бы…
зы ни разу на авр не пользовался отладчиком на арме фиг без него чего либо кроме моргания вышло бы…Ой ли? Скорее это из-за того, что на AVR проще по старинке отлаживать, чем через тормозной жтаг. А на STM32 доступна нормальная отладка, и естественно начинаешь ей пользоваться везде, в том числе и тем, где на АВр просто потупил бы в код.
Опять же, а симулятором на авр ты пользовался? Это тоже отладчик.
нет и симулятором (с целью отладки) тоже не пользовался — была куча примеров и аналитическое тупление.
зы пользовался только протеусом штобы чтонито не паять а побыстрому глянуть моргает нужная нога или нет
зы пользовался только протеусом штобы чтонито не паять а побыстрому глянуть моргает нужная нога или нет
я тоже сравнивал стм дискавери и атмегу 8-мь :)
и по скорости в флоатинг поинт
и по размеру кода
арм в два раза более надутый код генерит… особенно инициализация библиотечная…
а скорость… как Вы думаете во сколько раз больше или меньше?
в полтора раз апри той же частоте… другое дело что дискаверю запросто на 52 мегагерца можно газануть… а мегу на 20-ти не всегда запустиш
radiokot.ru/forum/viewtopic.php?f=20&t=50361 — тема с моим сравнением
clawham.hopto.org/DriveD/PubD/66/MVI_8188.AVI 500 метров видик для наглядности
и по скорости в флоатинг поинт
и по размеру кода
арм в два раза более надутый код генерит… особенно инициализация библиотечная…
а скорость… как Вы думаете во сколько раз больше или меньше?
в полтора раз апри той же частоте… другое дело что дискаверю запросто на 52 мегагерца можно газануть… а мегу на 20-ти не всегда запустиш
radiokot.ru/forum/viewtopic.php?f=20&t=50361 — тема с моим сравнением
clawham.hopto.org/DriveD/PubD/66/MVI_8188.AVI 500 метров видик для наглядности
Смотря какие вы задачи выполняете на МК.Вы же понимаете что мигать светодиодом на ARM «дороже» чем на AVR или тех же x51.Ну и как было сказано выше код инструкции у АВР и АРМ отличаются по объему. На одну инструкцию АРМ может приходится 2 и более инструкции АВР. Чет- странное получилось что код на АВР меньше чем на АРМ. Поправьте если не прав.
я ещё переписал тот код теста на авр под иаром и на арм под иаром… тоесть по идее одинаковые компиляторы… а разницы нет… кодвижн меньше кушает оперативки и больше флеши программ а иар немного экономит флеш программную но тратит капец как стэк… ну не суть важна… скорость у арма в синусах и флотингпоинтах в полтора раза больше при той же частоте… при этом код в 2-3 раза больше + функции инициализации библиотечные нужно юхать с опаской…
>> CooСox выдал на оптимизации -O3… код размером больше на 20% чем на -O2
Это нормально, по крайней мере, если у него название опций оптимизатора соответствует gcc-шным. O1, O2, O3 — это оптимизация по скорости, так что ничего странного, в том что код в O3 больше нет, это совершенно закономерно — разворачиваются циклы, инлайнятся функции и тд.
Оптимизация по размеру включается по -Os
Это нормально, по крайней мере, если у него название опций оптимизатора соответствует gcc-шным. O1, O2, O3 — это оптимизация по скорости, так что ничего странного, в том что код в O3 больше нет, это совершенно закономерно — разворачиваются циклы, инлайнятся функции и тд.
Оптимизация по размеру включается по -Os
Оптимизация по скорости, первый, второй и третий уровни. ЧТо конкретно на каком включается надо смотреть мануал на GCC. На третьем вроде повышается риск порчи программы оптимизатором. Плюс есть отдельный флажок enable-expensive-optimizations, но что он делает — хз.
Чтобы оптимизировало по размеру — Os. Нинай тока есть ли смысл указывать одновременно -O1 -Os, но где-то я такое видел.
Чтобы оптимизировало по размеру — Os. Нинай тока есть ли смысл указывать одновременно -O1 -Os, но где-то я такое видел.
Я просто тут в своем проекте под 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 включаю оптимизацию по Времени то размер кода не меняется
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 включаю оптимизацию по Времени то размер кода не меняется
Я бы смотрел на это так: При увеличении разрядности с 8 бит до 32 бит, объем увеличился всего в 2 раза!
Вообще рассмотренный вопрос сродни подщету тактов для выполнения кода на конвеерной системе. Да, пощитать конечно можно, то это будет не достоверной величиной, а грубой оценкой. 20% или в 2 раза — не суть важно. Огромное значение имеет используемый оптимизатор. А учитывая что компании «продвигают» кортексы, то можно ожидать то оптимизаторы станут повыше уровнем.
За проведённые же исследования спасибо.
Вообще рассмотренный вопрос сродни подщету тактов для выполнения кода на конвеерной системе. Да, пощитать конечно можно, то это будет не достоверной величиной, а грубой оценкой. 20% или в 2 раза — не суть важно. Огромное значение имеет используемый оптимизатор. А учитывая что компании «продвигают» кортексы, то можно ожидать то оптимизаторы станут повыше уровнем.
За проведённые же исследования спасибо.
Ну, во первых, Thumb2 имеет команды переменной длины — 2 или 4 байта. И 4-байтовых у него больше, чем у AVR. Во вторых, константы (особенно адреса) — длиннее соответственно размеру регистра/адресной шины. А так ничего вроде больше особо влиять и не должно — у ARM довольно эффективный набор команд.
На x86_64 программы тоже пухнут по сравнению с x86, хотя средняя длина команд примерно та же.
На x86_64 программы тоже пухнут по сравнению с x86, хотя средняя длина команд примерно та же.
Дык и в размере кода не в 4. Ну и увеличение разрядности х86 в пару раз (см. выше) раздувает ехе в 1.5-2 раза.
Для х86_64 самое проблемное место — оперативная память (винты и так вместительные, потому размер кода пофигу). На использование стека там выходит что то вроде более чем в 2 раза больше кушает. Проблема с резервированием места под регистры связана. А под размер кода что-то даже и не слышал ни от кого жалоб :)
Хм… Даже если бы по скорости STM32 и AVR на одной частоте были бы одинаковы я все равно за STM32, так как — цена при очень богатой функционально периферии плюс разрядность для вычислений и много разных доступных средств отладки. А так к примеру STM32F100RB у нас можно купить за 24гр. в то время как ATmega128-16AU стоит 54гр, выбор очевиден :) Для быдло фанатов атмеля которые несмотря не на что остаются православно-верными ATMEGE порекомендую поискать стену.
тоже не понимаю всенародной любви к AVR (хотя сам с него начинал). 8 бит уже вчерашний день.
- DeusExMachina
- 30 августа 2011, 08:54
- ↑
- ↓
Комментарии (55)
RSS свернуть / развернуть