вы решили заняться экстремальным программированием на AVR?
последние годы я озабочен не размером итогового кода, а тем, насколько красиво и просто решаются мои задачи, поэтому все эти лайфхаки постепенно теряются за неактуальностью.
кое-что вспомнить могу.
для проектов, состоящих из множества исходников, можно поэкспериментировать с опцией
-flto (использовать и при компиляции, и при линковке). иногда это даёт очень хороший эффект, правда, эффект этот разный от версии к версии
avr-gcc
в дополнение к ранее описанной опции
-ffunction-sections можно применять и
-fdata-sections, при не очень аккуратном кодинге позволит избавиться от незадействованных (но описанных в коде) переменных, т.е. позволит сэкономить ОЗУ
в качестве универсального совета по "тюнингу" кода могу рекомендовать чтение раздела из документации avr-gcc, посвященной опциям оптимизации. там описаны все флаги-переключатели и их эффекты. стандартные опции
-Ox по сути являются упрощенным вариантом одновременного включения-отключения множества отдельных флагов оптимизатора (в документации они перечислены). так вот, не всегда стандартный набор этих флагов для режима
-Os будет давать минимальный объем прошивки. можно, читая документацию, пробовать в включать "нестандартные" для этого режима флаги, или отключать "стандартные". комбинаций - миллиард, но иной раз удаётся подобрать наиболее удачную...
ну например, по умолчанию
-Os отключает "разворачивание" циклов, т.е. "невидимо" устанавливает опцию
-fno-unroll-loops. это даёт хороший результат для "длинных" циклов, но итоговый код для, например, обнуления 2 или 3 байтов подряд будет больше, чем если бы этой опции не было. если в вашем коде много циклов с малым количеством итераций, а их тело состоит из одного-двух операторов, есть вероятность, что без этого флага код будет меньше. поэтому в дополнение к
-Os вы просто добавляете
-funroll-loops (т.е. без
no-), и смотрите на результат.
-f - это опция изменения состояния флага компилятора, за ним без пробела следует наименование устанавливаемого флага. если же флаг нужно сбросить, перед его наименованием нужно добавить
no-. количество таких установок одного и того же флага может быть сколько угодно большим, но действовать будет самая последняя. т.е. в случае
-fno-unroll-loops -funroll-loops будет
включен флаг "разворачивания циклов".
для моих проектов наибольший эффект давали именно опции управления циклами, инлайнингом функций (и для циклов и для функций там есть флаги, устанавливающие "вес" для срабатывания опции, так вот, меняя этот вес можно добиваться минимума размера прошивки), а так же опции, управляющие поведением целочисленных вычислений. есть там флаг (к сожалению, подзабыл, как он называется), управляющий тем, чтобы числа
int и
long помещались при вычислениях в регистры, следующие "подряд" (пересказываю по памяти, и могу несколько исказить истину). так вот, включение этой опции для "маломерных" МК иной раз позволяет впихнуть невпихуемое...
последние версии
avr-gcc сильно отличаются от той версии, для которой я писал процитированное вами... и я не уверен, что советы будут актуальными для свежатинки.
из "лайфхаков", позволяющих упростить собственно кодинг (не выиграть в размере, а выиграть в красоте и понятности исходника, что лично для меня стало более важным), порекомендую обратить взгляд на новые "префиксы" для "переменных" в flash-памяти (то есть констант, находящихся в памяти программ)
__flash и
__xmem (появились с версии avr-gcc 4.x.x). с их помощью можно избавиться от функций
pgm_read_xxxx и работать с такими переменными и массивами напрямую через указатели, как и для обычного ОЗУ.
поскольку я работаю в
Eclipse, который не может корректно распарсить "переменные" с такими префиксами, и поэтому не подсвечивает их (в т.ч. помечает эти строки "некорректными" при автоконтроле синтаксиса), то для
Eclipse есть отдельный лайфхак, устраняющий ту проблему.
надо зайти в настройки проекта
Preprocessor Include Paths, Macros etc:
и там в разделе
CDT User Setting Entries добавить определение
пустого макроса
__flash (и
__xmem, если нужно):
поле этого парсер
Eclipse будет думать, что
__flash это макрос, а компилятор так думать не будет
ну, вот как-то так...
если будут конкретные вопросы - постараюсь ответить. а вот так, абстрактно "о своих наработках" спрашивать не надо, т.к. я не понимаю, о чем говорить...
