Сохранение структуры в 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 · Сообщение YS » Вс сен 18, 2011 17:07:40

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

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

Реклама

Kalibry

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

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

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

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

YS · Сообщение YS » Вс сен 18, 2011 17:33:03

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

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

Реклама

Kalibry

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

Реклама

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

Kalibry писал(а):На соседней ветке подсказали красивое решение:
Код: Выделить всё
Prog_Struct eePrg[2] __attribute__((section(".eeprom"))) = {
    {..., ..., ...},
    {..., ..., ...},
};

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

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

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

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

Реклама

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

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

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

BerZerK-ku

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

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

asteroid7

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

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

urry

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

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

asteroid7

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

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

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

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

BerZerK-ku писал(а):Такое годится, наверное, только для домашних поделок.

Наоборот.

BerZerK-ku

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

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

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

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

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

BerZerK-ku

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

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

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

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

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

впрочем,

Ничегонеработает писал(а):нет смысла Вас переубеждать.

BerZerK-ku

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

Jack_A

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

Правы оба, хоть так не бывает

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

YS · Сообщение YS » Пн сен 19, 2011 19:07:23

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

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

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

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

BerZerK-ku

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

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

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

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

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

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

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