Реальное количество циклов записи в EEPROM в AVRах?

[vitaliksv]

Сталкивался ли кто-нибудь с определением реально-возможного количества надёжной и достоверной записи в EEPROM в атмелах? Производители обещают 100 000 циклов. Я так понимаю - это минимум.
Интересно, кто какие использует алгоритмы для записи, если заранее известно, что возможное количество циклов записи может быть больше гарантированного?
Заранее благодарю за ответы!

[Easyrider83]

Есть камушек на убиение? Проведите опыт для мировой научной общественности.

[picavr]

Сталкивался ли кто-нибудь с определением реально-возможного количества надёжной и достоверной записи в EEPROM в атмелах? Производители обещают 100 000 циклов. Я так понимаю - это минимум.
Интересно, кто какие использует алгоритмы для записи, если заранее известно, что возможное количество циклов записи может быть больше гарантированного?
Заранее благодарю за ответы!

ЭТО - ГАРАНТИРОВАННО... всё что больше.. может быть да а может быть и нет... если вас устраивает негарантированая запись ...

ИМХО лучше делать 1 ячейку как указатель адреса на ячейку для сохранения переменной... через 100 000 меняем адрес на след. Количество гарантированых перезаписей увеличивается.

Я вот в PIC16F84 лет 8 назад пробовал, написал цикл:
запись
ожидание окончания записи
проверка после записи,
инкремент
вывод в порт сигнала

получилось в одну ячейку шил около 4,5 милисек.
и оставил работать... и через сутки ОНО работало..
то есть на выходе были импульсы... я больше не стал ждать )))) выключил...
1000/4,5*60*60*24=

Всегда пользую алгоритм записи
запись (одна переменная в 3 ячейки) пауза 8-10 милисек, проверка после записи, если 3 раза не пишет -авария.

Алгоритм считывания - считать 3 ячейки и мажоритарное сравнение, если ошибок нет то всё гут, если есть ошибка котор моно скоректировать, то запуск записи для коррекции, если нельзя - то авария или запись значения по дефолту.

[alexgap]

Стараюсь писать в EEPROM только при пропадании питания. Энергия для записи - остаточная в конденсаторе после выпрямителя БП.

[picavr]

Стараюсь писать в EEPROM только при пропадании питания. Энергия для записи - остаточная в конденсаторе после выпрямителя БП.

Это параметры изменяющиеся в процессе работы и необходимые для восстановления режима работы... А переменные установки.. запись при изменении..

ВАУ!! Бил Гилберт ))) Знакомые всё лица.... CRACKEDSOFT.

[chapa]

я делал так: в первой ячейке хранится адрес ячейки с данными. Туда производится запись, далее чтение и проверка на совпадение, если нет, то в первой ячейке увеличиваем адрес и пишем в следующую ячейку, а предыдущую бросаем. И так до конца EEPROM, а дальше...
Делел так в хитром выключателе света, хранил тупо текущее состояние вкл/выкл для восстановления при пропадании питания. Устройство работало около 10 лет, клацали светом часто, для пробы прочитал значение в первой ячейке, а там так и лежит адрес второй, не сдохла...

Так вот как выглядел Билл Гилберт!!! А я его подругому в детстве представлял... Эдакий монстр, запутавшийся в лентах МК-60.

[Gnider]

ЭТО - ГАРАНТИРОВАННО... всё что больше.. может быть да а может быть и нет... если вас устраивает негарантированая запись ...

ИМХО лучше делать 1 ячейку как указатель адреса на ячейку для сохранения переменной... через 100 000 меняем адрес на след. Количество гарантированых перезаписей увеличивается.

Я вот в PIC16F84 лет 8 назад пробовал, написал цикл:
запись
ожидание окончания записи
проверка после записи,
инкремент
вывод в порт сигнала

получилось в одну ячейку шил около 4,5 милисек.
и оставил работать... и через сутки ОНО работало..
то есть на выходе были импульсы... я больше не стал ждать )))) выключил...
1000/4,5*60*60*24=

Всегда пользую алгоритм записи
запись (одна переменная в 3 ячейки) пауза 8-10 милисек, проверка после записи, если 3 раза не пишет -авария.

Алгоритм считывания - считать 3 ячейки и мажоритарное сравнение, если ошибок нет то всё гут, если есть ошибка котор моно скоректировать, то запуск записи для коррекции, если нельзя - то авария или запись значения по дефолту.

Не совсем корректно. Надо так запись-питаниевыкл-питаниевкл-проверка

[picavr]

Не совсем корректно. Надо так запись-питаниевыкл-питаниевкл-проверка

Не совсем согласен. Я придерживаюсь следующего алгоритма.

1) Те параметры и установки устройства, которые изменяются вручную или автоматом при калибровке, настройке, так же различные счётчики, сохранять только после изменения. Адреса устройств, Ключи Далласа, номера термодатчиков итд.. итд.. итд..

2) А те параметры, которые нужны только для восстановления режима работы устройства после выкл-вкл, нужно сохранять при пропадании питания.

3) А в процессе сохранения: Имеем массив для сохранения (2-3 массива) отдельно для сохранения после выкл и отдельно для сохранения при изменении.
C начала проверяется равно ли записанное ячейки тому что хотим записать, если равно переходим к след ячейке.
Если окончен массив то выключаем процес сохранения.

Если не равно, то запускаем запись в ячейку данных. Через 4-10 милисек (смотрим в даташит МК на время записи EEPROM +20-30%) опять проверяем, если допустим 3 раза не совпадает, то либо сигнализируем аварию либо другие действия.
Это позволяет уменьшить количество параметров для сохранения при выключении и соответственно уменьшить время сохранения, и предотвратить лишние презаписи ячеек, так же контролировать соответствие записаного тому что необходимо записать, ещё в процессе записи.

И перед каждым обращением к EEPROM!!!(чтение или запись) проверяем флаг занятости EEPROM. Если занят, то выход и возврат через время достаточное для записи 1 ячейки.

[Gnider]

Думаешь еепром начинает порться ячейками по 1 байт?

[OneTech]

Есть специальные алгоритмы которые позволяют распределить нагрузку на биты в байте, тем самым повышая ресурс ячейки и незанимая дополнительные ячейки. Этот алгоритм особенно актуален при постоянном сохранении счётчиков событий, используется в абсолютных энкодерах. Предварительно число кодируется в код Грея, сохраняется в ячейку, при считывании - процесс наоборот.

Двоичный код в котором постоянно меняется младший бит:
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111

Код Грея в котором младший бит меняется вдвое реже, значит ресурс ячейки возрастает вдвое:
0000
0001
0011
0010
0110
0111
0101
0100
1100
1101
1111
1110
1010
1011
1001
1000