Доброго времени суток!
Пишу программу в студии под мегу 16 и возник вопрос.
Делаю так:


А потом так:


Идея в том, чтобы в EEPROM был массив структур с параметрами для работы устройства и обращаясь по номеру вытаскивать нужную:


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

Подскажите, как выйти из положения? Как их зашить их в EEPROM уже заполненными?

Почему? Напишите код, который заполняет их, скомпилируйте. Компилятор сгенерирует HEX для eeprom. Зашейте его, а код при желании измените обратно.

На соседней ветке подсказали красивое решение:


Вопрос снят, спасибо за совет.

Ну так да, я это и имел в виду. Т.е., вопрос был о форме записи?

Рад, что все решилось.

Да, именно в эту мелочь я и не мог въехать, бывает

решение не красивое, а самое обычное. однако, вместо __attribute__((section(".eeprom"))) разумнее использовать макрос EEMEM:ну и само собой, надо не забыть прошить МК сгенерированным файлом для EEPROM

Как раз это самый правильный вариант. Каждый раз при запуске программа должна проверять контрольную сумму EEPROM (или хотя бы сигнатуру) и записывать в EEPROM значения по умолчанию, если содержимое испорчено. Так Вы увеличите живучесть устройств и исключите лишние действия при прошивке.

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

"Странное утверждение."
Утверждение не странное. Это грамотное решение.
Создаются две одинаковые структуры. Первая дефолтная во flash, вторая, с которой работает программа, в eeprom. При старте и определении "битой" рабочей структуре происходит тупое копирование из дефолтной.

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

у меня епром прописывается в 3 местах и каждое закрывается контрольной суммой.
В случае, если кс не бьет в 3 местах, происходит запись дефолтных значений.

Не хилое резервирование.
Наверное выдерживает 4-ую степень жесткости при смене eeprom параметров.

Испорченное значение EEPROM ведёт еще к более неправильной работе, чем дефолтное. Даже может привести к катастрофическим последствиям.



Наоборот.

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

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

"Хоть как-то функционировать" ?! Зачем тогда нужны все эти настройки, если и так сойдет?

кормушка для рыбок в аквариуме: настроили на кормление раз в сутки, EEPROM глюкнула. в вашем случае (остановиться и подавать сигналы тревоги) рыбы останутся голодными до приезда хозяина из отпуска (т.е. подохнут), в случае, описанного Леонидом Ивановичем - кормушка "перенастроится" на кормление по умолчанию (допустим, 2 раза в сутки) - за месяц аквариум немного позеленеет, но рыбы, скорее всего, выживут.

впрочем, :)))

Хм... а чего тут переубеждать? я вроде и сам согласен что такой метод имеет право на жизнь, для домашних поделок или настроек касающихся пользовательского интерфейса. Но обходится так с параметрами участвующими в основных алгоритмах работы это уже бред.
А если у вас устройство релейной защиты? и например в МТЗ выставится "значение по умолчанию", в итоге получите миллионные-миллиардные убытки.

Правы оба, хоть так не бывает
Если слетела EEPROM, то нужно
- загрузить дефолтные настройки, но при этом :
- сообщить "куда следует", что настройки запорчены.
И та же МТЗ пусть лучше отключит не при 10А, а при 20, чем не отключит вообще. И у оператора будет мигать красная лампочка НАСТРОЙКИ ПОФИРЯЧИЛИСЬ.

Значения по умолчанию суть безопасные значения. Лучше пусть устройство работает не так эффективно, как могло бы, но ничего не круша вокруг, чем работает непонятно как (и потенциально опасно) с глючными параметрами.



В серьезных случаях на это пофиг. Главное - безопасность и предсказуемость.

Это как? Металл перегреют/недогреют? устройство внезапно начнет работать на другой частоте? детектор пальчиков будет пропускать только своего создателя?

Если человек пишет , что "Вариант с заполнить при первом запуске не подходит.". Значит у него есть на это основания.

Угу. Так считает начальство выводя бригаду укладывать асфальт в дождь.

Для безопасности/предсказуемости используют как-раз резервирование, если не аппаратуры, то хотя бы параметров.