Механизм записи и увеличение ресурса EEPROM у МК

[Dmitry Dubrovenko]

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

[maglev]

Сколько раз уже спрашивали...
Изнашивается конкретный адрес, при стирании все биты(?), при записи - биты, в которые пишется "0".

[GP1]

...
Изнашивается конкретный адрес...

Ну это спорный вопрос, поскольку память имеет страничную организацию...

[maglev]

Страничную организацию имеет flash-память, и для нее правила другие. EEPROM-же страниц не имеет, это одно из основных отличий от flash с т.з. пользователя.

[Dmitry Dubrovenko]

maglev, тенкс!
Только поясните, правильно ли я понял, что с "изнашиванием", память перестаёт стираться (т.е. все биты выставляться в "1"), и при записи, нестёртые биты остаются в исходном состоянии, а те, которые программируются (в которые записывается "0"), программируются нормально?

[maglev]

Память перестает стираться (стирание это запись "1"), дохлый бит остается в нуле.
Но я-бы не рассчитывал на эти тонкости, т.к. заявленный ресурс она отрабатывает гарантированно во всем диапазоне температур и напряжений, а испорченные ячейки могут повести себя непредсказуемо. Охладишь или нагреешь - возможна спонтанная регенерация, потом опять вывалится.

[Dmitry Dubrovenko]

Память перестает стираться (стирание это запись "1"), дохлый бит остается в нуле.

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

[DX168B]

Тогда Вам EEPROM хватит на всю жизнь.

[maglev]

алгоритм проверки записи, и, при ошибке, смены адреса ячейки.

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

[Engineer_Keen]

А какова вероятность, что новые данные не равны уже записанным? Или там случайное число 0-255? А то можно перед записью проверять, вдруг и записывать ничего не нужно, тогда еще немного ресурс сэкономится.

[Dmitry Dubrovenko]

Этот момент надежно поймать нельзя.

Почему же?
Если верификация записи не проходит, вот и "момент".

Правильнее писать каждый раз в новые адреса, размазывая (гарантированный) ресурс на количество используемых ячеек

Так бы оно, возможно, и было, но ведь адрес ячейки надо тоже куда-то записывать.

А то можно перед записью проверять, вдруг и записывать ничего не нужно

Это - само-собой, разумеется.

[Neekeetos]

Этот момент надежно поймать нельзя.

Почему же?
Если верификация записи не проходит, вот и "момент".

Тебе правильно сказали что записывать в одну и туже ячейку ожидая что она даст сбой записи это не оптимальный вариант, по той например причине что ячейка с выработанным ресурсом может нормально записаться но например считаться неверно позже. Грубо говоря не все ошибки при записи и чтении можно отследить.
Я когда делал такую вещь использовал распределение записи. В епромке ресурс тратится при любом изменении состояния битов, так что есть вариант записывать (не стирая) например одну и туже ячейку несколько раз подряд (8 на самом деле) обнуляя биты по очереди получая для одной ячейки тот же ресурс при 8кратном увеличении количества физических записей, при этом ты можешь использовать содержимое такой ячейки как указатель. Сама схема такая, выбираешь сколько тебе нужно ячеек, разбиваешь их на две группы - указатель и данные. Указателей в 8 раз меньше чем данных. Потом при записи ты последовательно обнуляешь биты в указателях, записывая в соотв ячейку данных новые. Ресурс увеличивается пропорционально количеству ячеек под данные. Те при использовании 9 байт = 1байт указатель и 8 байт данные, ресурс будет в 8 раз больше. Количество ячеек можно рассчитать. Ресурс среднего епрома 1 миллион перезаписей, это примерно 11 дней можно записывать новые данные в одну ячейку раз в секунду. Если требуется к примеру ресурс в 5 лет то 5 лет *365 дней/ 11 дней = 165 ячеек данных + 165/8 ~ 20байт указателей. Естественно все эти расчеты будут другими если частота записи отличается от раза в секунду.

[AndyKorg]

Простите, что влезаю. Но ведь запись в EEPROM в основном используется для спасения каких-то данных на случай пропадания питания. Может и тут такой случай и достаточно поставить конденсатор на питание МК и как то отслеживать наличие напряжения питания и в случае чего писать в EEPROM, а не периодически.
Конечно возможно, что конденсатор некуда поставить или ног не хватает для отслеживания питания. В этом случае конечно "такраканы пассуют".

[Jack_A]

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

Не обязательно. Может быть, ведется журнал событий. Если держать его в ОЗУ, а в момент пропадания питания переписывать в EEPROM, то простого конденсатора по питанию явно недостаточно - это не умозрительно, сам на этом деле долго ломал бошку. Нужен автомат питания, который четко отследит момент, начиная с которого энергии хватит только на записать в EEPROM. И если в процессе записи питание восстановилось, тем не менее закончить запись. А если не восстановилось, во избежание автколебательного процесса по питанию включить все допустимые нагрузки, и как Титаник, уйти на дно с включенной илюминацией - сбросить энергию из накопительных конденсаторов. И тут еще возникает проблема работы при длительном провале питания ( например, рядом двигун мощный раскручивается ). Проблема, конечно, не из разряда неразрешимых, но в пол-пинка не делается.
Вот вариант с указателями (Neekeetos) мне нравится - красиво.

[DX168B]

А я бы так сделал:
Данные держал бы в ОЗУ и в случае отключения питания сохранил бы в EEPROM,
но запитав МК по такой схеме:



Отслеживать питание ногой РХ1 и после всей процедуры отключить МК от батареи, выставив лог. 0 на ноге РХ0
Ногу РХ1 можно настроить как внешнее прерывание по спадающему фронту и в обработчике произвести запись в EEPROM. В конце обработчика выставить ногу РХ0 в лог. 0
Для защиты от кратковременных отключений питания, можно повесить электролит в пару сотен мкф между ногой PX1 и массой, но наверное надо будет устранить утечку заряда из него, поставив в цепи PX1 диод и кондёр этот подключить после него.

[maglev]

Этот момент надежно поймать нельзя.

Почему же?
Если верификация записи не проходит, вот и "момент".

А завтра форточку открыли, или солнышко с утра пригрело, или конденсатор в питателе подсох - вот и не читается.

[Dmitry Dubrovenko]

как то отслеживать наличие напряжения питания

Как уже говорили, довольно сложная аппаратная реализация.
В моём случае, вдобавок, конструкция уже готовая, переделке не подлежит, а надо новую прошивку.

А завтра форточку открыли, или солнышко с утра пригрело, или конденсатор в питателе подсох

Или бульдозером наехали, или кислотой облили...

Вот вариант с указателями (Neekeetos) мне нравится - красиво.

Допустим, теория с побитным изнашиванием верна.
Тогда поясните, что за МК такой, который позволяет запись осуществлять без стирания?


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

[DX168B]

Тогда поясните, что за МК такой, который позволяет запись осуществлять без стирания?

ATTINY26L. Даю полную гарантию, что новые данные можно писать в EEPROM поверх старых, без предварительного стирания. А вот FLASH требует предварительного стирания.
Я уже много проектов сделал с использованием записи в EEPROM.

[Dmitry Dubrovenko]

ATTINY26L

"Покурил" даташит.
Что-то ничего подобного не увидел (как-раз наоборот).
Ткните носом, плиз.

[DX168B]

Вот работающие куски кода для этого МК.

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

.include      "tn26def.inc"
;---------------------------------------------- Назначение имён регистрам
.def          temp0             = R16
.def          temp1             = R17
.def          temp2             = R18
;----------------------------------------------
.cseg
;**********************************************
;* Векторы прерываний                         *
;**********************************************
.org          0x0000
rjmp          RESET
.org          0x0009
rjmp          EEP_RDY
.org    INT_VECTORS_SIZE
;---------------------------------------------- Готовность EEPROM по прерыванию
EEP_RDY:
ldi				temp2,			0x00			;По готовности EEPROM чистим temp2
reti
;---------------------------------------------- Начало программы
RESET:
ldi           temp0,            RamEnd         ;Указатель стека
out           SP,               temp0
;...............
;.....
;---------------------------------------------- Запись "заводского" кода и значений настроек
WRSTD:
ldi				ZL, 			Low(CONFIG_IMAGE*2)
ldi				ZH, 			High(CONFIG_IMAGE*2)
clr				temp1
WRSTD_LOOP:
lpm				temp0, 			Z
rcall			EEWRITE1
adiw			Z, 				0x01
inc				temp1
cpi				temp1, 			50
brmi			WRSTD_LOOP
;-------------------------------
rcall         SUCCESS						  ; Индицируем успешную операцию.
rjmp		  RESET
;---------------------------------------------- Универсальный загрузчик в EEPROM
EEWRITE1:
cli
sbi           EECR,             EERIE
out           EEAR,             temp1
out           EEDR,             temp0
sbi           EECR,             EEMWE
sbi           EECR,             EEWE
ldi           temp2,            0xFF
sei
EEWR2:
cpi           temp2,            0x00
brne          EEWR2
cbi           EECR,             EERIE
ret
;---------------------------------------------- Образ "заводских" настроек
CONFIG_IMAGE:
.db 0x01, 0x02, 0x03, 0x04, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
.db 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
.db 0x05, 0x05, 0x05, 0x05, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
.db 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
.db 0x00, 0xFF, 0xFF, 0xFF, 0x04, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF

Тут копируются байты из массива в EEPROM.
Извратов не пугайтесь. Это маленький отрывок большой программы.
По окончанию процедуры записи стоит вырубить прерывание по готовности EEPROM,
иначе оно Вас зае***т в процессе работы программы. Незнаю, как в других МК, но тут такая мелкая гадость.