Работа eeprom в AVR.

[coredumped]

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

чтобы не было кирдыку вместо eeprom_write_xxxxx надо использовать eeprom_update_xxxxx. последняя функция перед тем. как что-то писать в ячейку, проверяет, не то же самое там записано? и, если то же самое, то запись не делает - это сильно увеличивает ресурс записей, хотя на 100% и не снимает проблему...

А это уже интересно! Не нужно отдельно проверять разницу информации. Но всёже запутался в полученной информации, вернее недопонимаю. Хожу гдето рядом....
Всёже опишите пожалуйста на моём примере. Я ещё слаб в программировании.
Спасибо.

На практике, я обычно завожу переменную-флаг, которая сигнализирует о том, что есть что сохранять в епром, те о том, что данные изменились. И потом, в процедуре сохранения уже принимается решение писать - не писать. Можете использовать update_..., это уже дело вкуса. В любом случае, логически нужно постараться избегать лишних (не нужных) операций записи в епром.

[ARV]

А это уже интересно! Не нужно отдельно проверять разницу информации. Но всёже запутался в полученной информации, вернее недопонимаю. Хожу гдето рядом....
Всёже опишите пожалуйста на моём примере. Я ещё слаб в программировании.
Спасибо.

ну, можно например свести все eeprom-данные в структуру:

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

typedef struct{
   int coefficient;
   long init_value;
   // и так далее
} stored_data;

EEMEM stored_data e_config;

stored_data config;

int main(void){
   // загружаем конфиг из EEPROM
   eeprom_read_block(&config, &e_config, sizeof(stored_data));
   // далее делаем свои черные дела
   // в том числе ИЗМЕНЯЕМ поля config
   // после каждого изменения сохраняем обратно в EEPROM
   eeprom_update_block(&e_config, &config, sizeof(stored_data));
   // при этом реально будут записаны только те поля, которые на самом деле изменили свое значение, а не все подряд
   // то есть не все ячейки будут расходовать свой ресурс.
}

если изменение данных происходит от действий человека - проблем нет никаких: скорее всего, девайс скорее сломается или устареет, чем человек сделает 100 тысяч изменений настроек поэтому задумываться о ресурсе не нужно вообще.

[YS]

Это сейчас умный GCC warning кинет и скомпилит, а в старые времена, пока return ченить не поставишь, хрен оно скомпилится, я это хорошо помню, посему и леплю ретурны "на автомате".

Ну, я из нового поколения, и таких древностей не помню. Первое, что мои руки пишут на автомате -

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

#include <avr/io.h>

void main(void)
{

  while (1);
}

AVR-GCC говорит на это warning: return type of 'main' is not 'int'. Но мне как-то пофиг, ибо я за здравый смысл.

[king-live]

Спасибо! Попробую затолкать всё в структуру. Хотя работать буду всеголишь с 2мя переменными, которые нужно сохранять в eeprom. И на счёт "переменной-флаг" тоже идея хорошая. Попробую.

[sdsrem]

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

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

[avreal]

AVR-GCC говорит на это warning: return type of 'main' is not 'int'. Но мне как-то пофиг, ибо я за здравый смысл.

-Wno-main есть достаточно убедительной просьбой не ворчать.
В С++ это не катит, зато в С++ по стандарту нормально написать

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

int main()
{
    for(;;) {}
}

Так как именно для main() происходит автоматическая подстановка return 0; при отсутствии возврата от щедрот программиста. В том числе если там не for(;;) {}, а реальный возврат.

[avreal]

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

Может он уже в коме. Т.е. при данных напряжении питания и температуре ещё пишет (хотя надо попробовать записать туда другие данные), а при -20 и другом напряжении питания уже фигушки. А контроллер из другой партии еще три дня назад и при тех же условиях перестал бы писаться (то, что кто-то пил-курил и прожил 90 лет -- еще не означает, что я дотнул бы и до 40, если бы пил/курил).

[md5sum]

Следующий эксперимент, где последовательно заносились значения 0x00 и 0xFF подтвердили догадку, и то епром отработал по-моему 3-х кратную норму, точно не помню.

Что считать нормой? Данные в ДШ - это минимальное кол-во циклов стирания/записи, которое выдержит память. А большее кол-во никем не запрещено

[coredumped]

Следующий эксперимент, где последовательно заносились значения 0x00 и 0xFF подтвердили догадку, и то епром отработал по-моему 3-х кратную норму, точно не помню.

Что считать нормой? Данные в ДШ - это минимальное кол-во циклов стирания/записи, которое выдержит память. А большее кол-во никем не запрещено

Да, конечно. В ДШ значится гарантированное количество циклов записи. Те при самых плохих условиях использования, гарантируется не меньше этого количества операций. Больше есс-но никто не запрещает, но правильный результат уже не гарантируется.

[Eprinter]

А вот интересно...
В CVAVR обращение к переменным в еепром сделано супер просто, никаких наворотов (страничка из книги в прикошаченном файле).
Получается, что CVAVR при компиляции сам подставляет нужные куски кода, или автор не совсем в теме?

[YS]

Получается, что CVAVR при компиляции сам подставляет нужные куски кода

Да. IAR делает так же. Но, ясно, надо иметь в виду, что специфика EEPROM от этого никуда не девается, и присваивать в такую переменную надо с пониманием того, что она не вечна.

[coding]

А 1млн. перезаписываней - это для пространства всей памяти eeprom или для каждого бита отдельно? т.е. если писать только значение по адресу 0х01 до отказа, то после отказа остальная область будет рабочая или крендык?

[foton6]

Доброго времени суток)
Столкнулся с EEPROM и возникла пара вопросов:

//При обьявлении переменной (AtmalStudio 6) выделяются первые "N" бит в зависимости от типа переменной?
И если записать в МК другую программу работающую тоже с EEPROM, то переменная того же типа что была обьявлена в предыдущей программе,
но с другим именем будет иметь значение из прошлой программы?

и если обьявлять так:
uint8_t EEMEM A;
То каждый раз при нажатии "reset", А будет всегда иметь значение записанное до сброса?Не будет ли она обнулятся при каждом новом обьявлении?

[pcb]

А 1млн. перезаписываней - это для пространства всей памяти eeprom или для каждого бита отдельно? т.е. если писать только значение по адресу 0х01 до отказа, то после отказа остальная область будет рабочая или крендык?

Да чо вы раздули. Еепром несколько миллисекунд переписывается. более точно надо дш смотреть.

По теме.

Очень удобно использовать структуры, как, на на примере выше, показали.
Все переменные и коэф за раз при загрузке контроллера подгружаются.

[Финский]

Заявленный фирмой Atmel ресурс EEPROM памяти микроконтроллеров AVR, равный 100 тысячам циклов запись/чтение, относится к ресурсу одного байта памяти, а не к целой странице.

Тест EEPROM памяти AVR микроконтроллера.

[pcb]

антиресный опыт.

Запихнут когда нибудь ферритовую память в процессоры?

[COKPOWEHEU]

Так наоборот, уходят от магнитной записи. Существуют ведь экзотические сейчас микросхемы на ЦМД. С другой стороны в компьютерах иногда заменяют жесткие диски на SSD. Если уж так хочется энергонезависимости - проще организовать резервное питание и режимы сна.

[pcb]

Заблуждаетесь.

[COKPOWEHEU]

Я не говорю что уходят везде и всюду. Все-таки ограниченный ресурс перезаписи - существенный недостаток flash. Как и высокая стоимость на единицу объема. Разумеется, там, где информация должна часто перезаписываться при высокой надежности хранения (сервера например), магнитный диск предпочтительнее. Но такие применения имеют мало отношения к встраиваемым системам. Их особенности - редко изменяемая программа, низкое потребление, сравнительно низкая вычислительная мощность.

[YS]

Запихнут когда нибудь ферритовую память в процессоры?

Уже запихнули, и это решение уже доступно на рынке.