Jump to content

    

Прошивка Flash и EEPROM одним файлом hex или elf

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.

Share this post


Link to post
Share on other sites
Но в свое время я много времени думал почему CPU иногда косячит.

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

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

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

 

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites
Задаёте значения своим переменным:

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

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

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

 

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

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

 

 

Share this post


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

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

 

 

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

Так и есть

 

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

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

#define EE_ADR_VAR1       ((void*)0x11)

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

Share this post


Link to post
Share on other sites
У меня в проекте шесть различных независимых модулей, у каждого от одного до десятка байт конфигурации. Зачем мне их объединять в одну структуру?
Чтобы после очередной смены версии компилятора или положения звезд на небе их расположение в памяти осталось неизменным. И обновление прошивки не приводило к необходимости повторной конфигурации.

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

#define EE_ADR_VAR1       ((void*)0x11)

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

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

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this