[alexeyv 0]

to demiurg_spb

1. Во всех ваших примерах надо добавить &eeprom_var1...

Не во всех, а только в последнем - там действительно да, очепятка, сори.

 

2. Лет 10 как никаких проблем с EEPROM нет, да и те, что были, вами лично надуманы. Единственное, что было это:

http://www.nongnu.org/avr-libc/user-manual...prom_corruption

Я и не уточнял возраст этой проблемы. Да, это было давно. Но в свое время я много времени думал почему CPU иногда косячит.

у меня было такое: адрес в EEPROM какой-то из диапазона 0x06...0x0А (не помню), и если по этому адресу записать то ли 0x27, то ли 0x2А (не помню), CPU вставал в ступор. причем зависал только на одном значении.

 

За исключением создания структуры, моя логика работы с EEPROM не отличается от логики других форумчан. Я не понимаю зачем создавать структуру?

 

Кстати, у ТС был вопрос как избавиться от второго файла, а не как работать с EEPROM.

[demiurg_spb 0]

Но в свое время я много времени думал почему CPU иногда косячит.

у меня было такое: адрес в EEPROM какой-то из диапазона 0x06...0x0А (не помню), и если по этому адресу записать то ли 0x27, то ли 0x2А (не помню), CPU вставал в ступор. причем зависал только на одном значении.

Приведите пожалуйста ссылку на ERRATA, где говорится о вашей ситуации.

Удивительно, но я начинал использование AVR с at90s2233 и с тех пор ничего подобного не встречал.

 

За исключением создания структуры, моя логика работы с EEPROM не отличается от логики других форумчан. Я не понимаю зачем создавать структуру?

Я уже об этом писал и объяснил зачем это нужно делать ВСЕГДА. Хотите я вам скину ссылку на avg-gcc 4.X.X, который вдруг стал располагать данные в EEPROM в обратном порядке (формально это не бага, т.к. стандарт ничего против такого поведения не имеет)?

Если же данные поместить в упакованную структуру, то уже ничто не в праве её изменить.

Конечно, если вы не предоставляете доступа к EEPROM данным наружу и не считаете КС содержимого EEPROM можно обойтись и без структуры, только зачем?

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

Ещё один большой плюс структуры - это очень лаконичное её объявление как EXTERN - всего одной строчкой.

 

Кстати, у ТС был вопрос как избавиться от второго файла, а не как работать с EEPROM.

Не зная алфавита сложно начать составлять слова...

[Twin_by 0]

Задаёте значения своим переменным:

EEMEM eeprom_data_t eeprom =
{
    .var1 = 33U,
    .var2 = 333.0f
};

Работаете с ними:

В этом случае будет создан файл *.eep. Я так подозреваю

 

Я уже об этом писал и объяснил зачем это нужно делать ВСЕГДА. Хотите я вам скину ссылку на avg-gcc 4.X.X, который вдруг стал располагать данные в EEPROM в обратном порядке (формально это не бага, т.к. стандарт ничего против такого поведения не имеет)?

Да есть, такое. Когда первый раз с этим столкнулся долго не мог понять что у меня где в eeprom

 

 

[alexeyv 0]

Я уже об этом писал и объяснил зачем это нужно делать ВСЕГДА.

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

 

 

В этом случае будет создан файл *.eep. Я так подозреваю

Так и есть

 

Да есть, такое. Когда первый раз с этим столкнулся долго не мог понять что у меня где в eeprom

поэтому я объявляю адреса EEPROM так:

#define EE_ADR_VAR1       ((void*)0x11)

Всегда знаешь где что лежит, независимо от предпочтений компилятора

[Сергей Борщ 119]

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

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

поэтому я объявляю адреса EEPROM так:

#define EE_ADR_VAR1       ((void*)0x11)

Всегда знаешь где что лежит, независимо от предпочтений компилятора

Взвалить на себя работу линкера? С ненулевой вероятностью положить одни данные поверх других? Нет уж, увольте.