Сохранение структуры в EEPROM AVR?

[Kalibry]

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

Код: Выделить всё

typedef struct {
    unsigned char  Name_1;
    unsigned char  Name_2; //И таких еще 10 :)
} Prog_Struct;

А потом так:

Код: Выделить всё

Prog_Struct eePrg[4] __attribute__((section(".eeprom")));

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

Код: Выделить всё

eeprom_read_block(&psPrg, &eePrg[ucPrg_Nam], sizeof(psPrg)); //psPrg - такая же структура, но для работы

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

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

[YS]

Вариант с заполнить при первом запуске не подходит.

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

[Kalibry]

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

Код: Выделить всё

Prog_Struct eePrg[2] __attribute__((section(".eeprom"))) = {
    {..., ..., ...},
    {..., ..., ...},
};

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

[YS]

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

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

[Kalibry]

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

[Мастер Ломастер]

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

Код: Выделить всё

Prog_Struct eePrg[2] __attribute__((section(".eeprom"))) = {
    {..., ..., ...},
    {..., ..., ...},
};

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

Код: Выделить всё

EEMEM Prog_Struct eePrg[2] = {
    {..., ..., ...},
    {..., ..., ...},
};

ну и само собой, надо не забыть прошить МК сгенерированным файлом для EEPROM

[Леонид Иванович]

Вариант с заполнить при первом запуске не подходит.

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

[BerZerK-ku]

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

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

[asteroid7]

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

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

[urry]

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

[asteroid7]

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

[Леонид Иванович]

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

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

Такое годится, наверное, только для домашних поделок.

Наоборот.

[BerZerK-ku]

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

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

[Леонид Иванович]

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

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

[BerZerK-ku]

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

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

[Мастер Ломастер]

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

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

впрочем,

нет смысла Вас переубеждать.

:)))

[BerZerK-ku]

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

[Jack_A]

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

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

[YS]

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

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

миллионные-миллиардные убытки.

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

[BerZerK-ku]

Значение по умолчанию суть безопасное значение.

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

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

Лучше пусть устройство работает не так эффективно

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

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

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