Спасибо за ответ.

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

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

Upd. Насколько я понял, нужно в Makefile в параметрах линкера определить новую секцию, используя

где 0x81 указывает на расположение секции в EEPROM, а xxxx - её начальный адрес.
Затем в самом коде указываем что-нибудь типа

после чего при компиляции создастся файл .eep.

еще раз: вам не надо заботиться об адресах размещения данных в памяти, это за вас сделают компилятор и линкер, и "немного отступив" не потребуется, все и так не будет накладываться.

Я так понимаю "пара значений" пишется напрямую через функции eeprom_write_* или регистры сразу? Так сделайте их тоже EEMEM и пишите через eeprom_write_* / eeprom_update_* по адресам указателей EEMEM. Так компилятор сам раскидает всё как надо и не придется заморачиваться с доп. секцией.
В общем случае лучше не смешивать доступ по адресам EEMEM указателей и свою прямую адресацию. Уж что-то одно использовать надо, чтобы не возникло "наложения".

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

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

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

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

Подробнее>>

Что конкретно интересует?

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

интересуют ваши лайфхаки, наработки, заметки по компилятору для WinAVR
тоесть информация такого вида как я привел в посте выше

вы решили заняться экстремальным программированием на 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 это макрос, а компилятор так думать не будет

ну, вот как-то так...

если будут конкретные вопросы - постараюсь ответить. а вот так, абстрактно "о своих наработках" спрашивать не надо, т.к. я не понимаю, о чем говорить...

ARV, не совсем по теме. Я как то смотрел ваш плейер световых эффектов... Заради чего все эти извращения с компоновщиком?

основной мотив моих телодвижений - упростить процесс разработки для себя любимого.
например, где обычно делают инициализацию периферии и/или локальных переменных? как правило, это делают в некоей init-функции, вызываемой в числе первых из main. я же уже лет 10, пожалуй, делаю это в секции .init7 (или других аналогичных), помещая нужный код в каждом модуле по мере необходимости. поэтому у меня, например, вполне рабочий такой код: то есть в main - только то, что в main нужно делать, а остальное - там, где оно логично.

точно по той же причине я сделал "изврат" с линкером. поясняю.

можно ли в Си создать массив функций? да.
можно ли описать эти функции в 100 отдельных исходных файлах? да
удобно ли это в работе? нет
почему это не удобно? да потому, что в Си нужно собрать объявления всех функций в заголовочном файле, чтобы потом поместить их (вручную!) в инициализацию массива. когда в процессе разработки появляются новые идеи, такая "ручная" работа становится утомительной.

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

в частности, если мне захочется пополнить мой плейер поддержкой новой команды, мне нужно будет:
1. создать новый исходник, где реализовать обработчик этой команды (при помощи макроса, помещающего этот обработчик в нужную секцию)
2. всё.
ни один другой исходник или заголовочный файл корректировки не потребует.

разве это не удобно?

Ну да, наверняка это удобно. Для вас. В данном конкретном случае. А как это вписывается в совместимость c другими компиляторами? В чём тогда фишка Си? Я пишу на высокоуровневом языке для чего? Для того что бы переносить код на другие платформы и архитектуры, верно? На кой же мне ещё изгаляться с фишками каждого конкретного линкера? Заради того, что вам чуть-чуть удобнее? Как то это странненько, согласитесь?

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

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

Да ни какой не миф! На кой тогда он нужен этот Си - высокоуровневый язык? Придерживайтесь правил, отделяйте физику от логики, всего то! Неуж то мне вам это нужно объяснять? Это ж как отче наш должно быть!

ну так у меня все так и есть! логика в макросах, а макросы можно править под платформу/компилятор. скрипт линкера тоже. или вы хотите сказать, что, например, под ARM без работы со скриптом линкера можно что-то "портабельное" собрать запросто? вот и вся ваша переносимость...

я ж вас не заставляю пользоваться моими приёмами! хотите обеспечивать мнимую переносимость - корячьтесь с ручной правкой кучи файлов и массивов, я ж не против. а мне на аспект переносимости плевать, поскольку я работаю для себя любимого

Ага. Вот и получается что с вашими "приёмами" людям приходится не только с логикой разбираться, но ещё и с вашими линкерскими выебонами, не так ли? Ну да, конечно, вы крут! Офигенно крут! А-ха-ха! Бурные, ннесмолкающие, аплодисменты... Ужос!

ну, если вы работаете с ARM-ами, вы тоже должны со скриптами линкера ковыряться... и не только с ними! вы так же возмущены нехорошим поведением разработчиков софта под ARM?

не понимаю вашего неистовства... ну не нравится - и не применяйте. чего кипятиться-то?

Нет. Вы вправе делать так, как вам соизволится, какие тут могут быть претензии.
Просто, если вы хотите доносить своё творение в массы, то должны всё же упрощать этот процесс.
Моё мнение. Удачи!

так куда еще упрощать: все проекты, которые я "выношу в массы" имеют готовый makefile для сборки проекта? то есть приняв мою концепцию программирования, вы можете править все исходники по-своему, а потом собрать из них результат! и ковыряться в скрипте линкера вам не потребуется.

чего еще вам не хватает? портировать мой проект для atmega328 на PIC16 все равно не получится, как ни лезь из кожи вон

Если ты великовозрастный дебил, не надо напрягать своей проблемой других.

winavr - ошибка компиляции no rule to make target "***.elf"
подскажите ,как исправить?

Добавлено after 3 hours 34 minutes 7 seconds:


Вроде разобрался,библиотеки с плагинами нужны.

Вот и я об этом. А писали бы "как люди", так и портировалось бы.)