Увеличение количества циклов записи в EEPROM, как правильно программно? Опции

[smk]

В программе используется переменная "char n". Всякий раз при включении она инкременируется и по достижении определенного значения - обнуляется. Чтение-запись происходит примерно 1 раз в секунду. При количестве циклов 100 000, надолго одной ячейки не хватит. Есть необходимость писать поочередно во все ячейки EEPROM. Как это сделать правильно, при условии что между любыми двумя циклами чтения-записи контроллер отправляется в "powerdown". Кто-то делал подобное? Как это можно сделать вообще, ведь адрес тоже нужно где-то помнить?

Буду крайне признателен за подсказки и примеры!

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

Давно в ru.embedded пробегала такая идея: использовать код Грея, один бит кодировать одной ячейкой eeprom. Получим равномерный износ N ячеек (где N - количество бит в счетчике) и на весь счетчик в N раз больший ресурс. В Вашем случае можно счетчик сделать 4-байтным, тогда размажем его на 4N ячеек, в качестве результата брать младший байт после преобразования из кода Грея в двоичный.

[prottoss]

...

Поищите по форуму (EEPROM или DATAFLASH). Пару-тройку веток с интересующей Вас тематикой обязательно найдете

[CDT]

... Выделяем кусок ЭПРОМ, в котором храним счетчик
... При каждом сохранении в старых ячейках пишем $FF а в новых счетчик
... При чтениии от начала ищем not $FF и тем самымым выходим на запись.

... Таким образом при счетчике в 4 байта и перезаписи с частотой 1 Гц всей памяти хватит на 148 суток. Не густо.

Код

FM25256
256K bit Ferroelectric Nonvolatile RAM
• Organized as 32,768 x 8 bits
• Virtually Unlimited Endurance (10^14 Cycles)
• 10 Year Data Retention
•Very Fast Serial Peripheral Interface - SPI
• Up to 15 MHz Frequency

[mse]

Код

FM25256
• Virtually Unlimited Endurance (10^14 Cycles)

Да, ФРАМ здесь самато. Реально ресурс, коншна, гораздо меньше. На Телесиське проскакивала цыфра 1е9, вырванная с кровью из интимного места техподдержки. Кроме того, у ФРАМ чтение разрушающее. Т.е. его ресурс как ПЗУ сильно ограничен. В отличие от режима ОЗУ или ЕЕПРОМ-флэш. Там наоборот.

[Dog Pawlowa]

В программе используется переменная "char n". Всякий раз при включении она инкременируется и по достижении определенного значения - обнуляется. Чтение-запись происходит примерно 1 раз в секунду. При количестве циклов 100 000, надолго одной ячейки не хватит. Есть необходимость писать поочередно во все ячейки EEPROM. Как это сделать правильно, при условии что между любыми двумя циклами чтения-записи контроллер отправляется в "powerdown". Кто-то делал подобное? Как это можно сделать вообще, ведь адрес тоже нужно где-то помнить?

Буду крайне признателен за подсказки и примеры!

1. Обычно делают так, чтобы данные в EEPROM записывались только при выключении питания. Если питание не батарейное, то нет проблем. Если батарейное... Наверно, тоже возможно - проснуться, проверить напряжение на батарее и, если мало, то сохраниться. Только нужно сделать программнй гистерезис, чтобы не было проблем при питании близком к критическому.

2.

Выделяем кусок ЭПРОМ, в котором храним счетчик
... При каждом сохранении в старых ячейках пишем $FF а в новых счетчик
... При чтениии от начала ищем not $FF и тем самымым выходим на запись.

... Таким образом при счетчике в 4 байта и перезаписи с частотой 1 Гц всей памяти хватит на 148 суток. Не густо.

Это неэффективный путь, так как ресурс ячейки используется не полностью. Нужно писать не char, а int. Тогда младший байт будет перезаписан 65000 раз.
Или комбинировать предложенное использование кода Грея с адресацией.

[Nanobyte]

...Кроме того, у ФРАМ чтение разрушающее. Т.е. его ресурс как ПЗУ сильно ограничен. В отличие от режима ОЗУ или ЕЕПРОМ-флэш. Там наоборот.

Почему это чтение с триггеров разрушающее? И чем отличается режим ПЗУ от ОЗУ?

[mse]

Почему это чтение с триггеров разрушающее? И чем отличается режим ПЗУ от ОЗУ?

Если бы там были триггера, то она бы была золотая. Проскальзывал документ ихний про кол-во считываний без регенераццыи. Давно, правда.
А вот этим и отличается: в ОЗУ пишем-читаем, а из ПЗУ тока читаем.

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

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

Давно, потому и забылось, видать. Принцип там такой: при записи электрическим полем сдвигается атом в кристалле ферроэлектрика. При прохождении атомом энергетического барьера возникает импульс тока. В процессе чтения также прикладывают поле. Если зарегистрирован импульс - значит бит был запрограммирован. Но атом в процессе этого чтения уже занял исходное положение, информация разрушена (отсюда название "разрушающее чтение"). Поэтому считанное значение тут же аппаратно записывается обратно.
FRAM technology basics
Кстати поэтому для этих памятей ограничено (раньше было, во всяком случае) не количество записей, а количество обращений к ячейке. Ибо чтение = стирание + запись.

[WHALE]

имхо,для таких задач RTC с внутренним ОЗУ с батарейкой-самое то.Цена около 2 енотов да и энергоне-
зависимые часы вещь полезная.

[rumit2000]

to Сергей Борщ
не в тему ветки, но про FRAM, не могли бы Вы прояснить, правильно ли я понимаю следующее: в доке на FM25256 (FRAM от Ramtron-а) написано 10^14 cycles, эти циклы складываются из числа записей х 1 + число чтений х2... При максимальной частоте доступа 15 MHz, если мы будем тупо по кругу читать один и тот же байт (я так понимаю это для FRAM хуже чем писать), выходит много лет, что бы ячейку убить.... т.е. память выходит практически вечная (в разумных пределах)... или я что-то не верно себе мыслю?

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

в доке на FM25256 (FRAM от Ramtron-а) написано 10^14 cycles, эти циклы складываются из числа записей х 1 + число чтений х2...

Я так понял что число записей*1 + число чтений *1.

При максимальной частоте доступа 15 MHz, если мы будем тупо по кругу читать один и тот же байт (я так понимаю это для FRAM хуже чем писать), выходит много лет, что бы ячейку убить.... т.е. память выходит практически вечная

Да, они так изначально и заявляли, что число обращений теоретически ограничено, но реально быстрее сдохнет сама микросхема из-за диффузии материала корпуса в кристалл, чем исчерпается ресурс. И что именно поэтому реального ресурса никто не знает - "убить пока не удалось" Насчет "читать хуже чем писать" - мне кажется ей что чтение, что запись - то же яйцо только вид сбоку.

[rumit2000]

Я так понял что число записей*1 + число чтений *1.
Да, они так изначально и заявляли, что число обращений теоретически ограничено, но реально быстрее сдохнет сама микросхема из-за диффузии материала корпуса в кристалл, чем исчерпается ресурс. И что именно поэтому реального ресурса никто не знает - "убить пока не удалось"

Спасибо, а то прочитав про FRAM испугался, что заложился на неё в серии...

[CD_Eater]

rumit2000
В ДШ к последним FRAM-ным м/сх указывается неограниченный срок (то есть, время истощения ресурса при непрерывном чтении превышает время хранения данных при отключенном питании). Однако с нетерпением ждём от mse новостей из интимного места техподдержки (терморектальный криптоанализ, видимо, полезная вещь). Но вот только ходят слухи, что главный бич FRAM-ок - это нестабильность в общем полупроводниковом смысле (от питания/температуры). Любопытно было бы послушать "пострадавших".


Сергей Борщ
Почему при использовании кода Грея будет равномерный износ ячеек? Мне кажется, это не так, потому что в коде Грея младшие биты меняются гораздо чаще старших, в этом он ничем не отличается от двоичного кода. Это легко проверить, вспомнив формулу перевода двоичного кода в код Грея (там просто XOR соседних битов). Код Грея не даёт других преимуществ кроме "атомарности" операции, что само по себе часто бывает полезным.

Сообщение отредактировал CD_Eater - Mar 21 2007, 16:23

[rumit2000]

Но вот только ходят слухи, что главный бич FRAM-ок - это нестабильность в общем полупроводниковом смысле (от питания/температуры). Любопытно было бы послушать "пострадавших".

скоро будет год как в серии (в том числе в уличных исполнениях) работает... вроде проблем не было "тьфу-тьфу-тьфу..." Хотя конечно год совершенно не показатель... Зато вот атмеловская память AT25256 побилась в ходе тестов..... при обещаных 100.000, чесно выдержала около 250.000 циклов записи а потом благополучно перестала воспринимать запись в ячейку...

[Rst7]

Почему при использовании кода Грея будет равномерный износ ячеек? Мне кажется, это не так, потому что в коде Грея младшие биты меняются гораздо чаще старших, в этом он ничем не отличается от двоичного кода. Это легко проверить, вспомнив формулу перевода двоичного кода в код Грея (там просто XOR соседних битов).

При изменении на +-1 меняется только ОДИН бит, значит все будут равномерно изменяться

Код Грея не даёт других преимуществ кроме "атомарности" операции, что само по себе часто бывает полезным.

см. выше

[CD_Eater]

Rst7, Вы не правы. Байт, отвечающий за младший биты счётчика, будет перезаписываться каждое второе приращение, а старший бит счётчика изменится только один раз за весь диапазон !

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

Rst7, Вы не правы. Байт, отвечающий за младший биты счётчика, будет перезаписываться каждое второе приращение, а старший бит счётчика изменится только один раз за весь диапазон !

Да, справился с Гуглем, признаю, что был не прав. Получается, преимущество только одно - удалась запись или не успела закончиться при снятии питания - счетчик не порушится а лишь успеет/не успеет увеличить значение.

А перезапись на каждое второе приращение счетчика - уже вдвое увеличивает ресурс, вот

[smk]

Есть предложение. Кто-нибудь может привести конкретную формулу как часто можно писать в EEPROM, учитывающую количество свободных байт, таким образом чтоб обеспечивалась гарантированная работоспособность девайса в течение 2-лет (Закон о защите прав потребителей) ну и само собой программный код на Си, обеспечивающий это. Я бы принял это за отраслевой стандарт, как я думаю и многие другие.

А еще удобней, если рассчет будет опираться на количество часов непрерывной работы.

[xemul]

Соглашусь с предыдущими ораторами - при такой частоте записи разумнее использовать FRAM или NVRAM того или иного вида, а не EEPROM.
Но возник вопрос: назначение этой char n? Счетчик числа включений? Разрядность маловата. seed для rndg? Дык вроде бы питание не снимается, а только в powerdown контроллер падает.
Собственно нужна ли такая частота записи? И чем состояние коробочки сейчас отличается от ее состояния 256 секунд тому?

[smk]

Дык вроде бы питание не снимается, а только в powerdown контроллер падает.

Уже переписал все так, что в данном конкретном приложении удалось обойти эту ситуацию.

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

[defunct]

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

[acorn]

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

когда дойдем до 255 (или 65535 - это вряд-ли для встроенного EEPROM) и переполнимся - как писать/искать будем?

[proba]

если сделать кольцевои счетчик из 256 баит то число перезаписеи и растет 256 раз. если из 512 баит то получится ок. 50 млн. циклов.
некоторые EEPROM ( и все FLASH) имеют запиь без стирания, там можно атомарно биты писать, каждыи баит при том имеет 9 состоянии : FF,FE,FC,F8,F0,80,40,20,10,00.
я сделал таким образом счетчик в FLASH е , 125 баит как колцевои счетчик ( мах число = 125 x8= 1000) , а переполнение , т.е. тысячи считал в оставшихся 3 баитах. получилось счетчик, где происходить 1 стирние на 1000 единиц .учитывая ресурс Flash 100K , общии износь будет на 100млн. но не сложно удлинить кольцо 2 ^ N раз

[CD_Eater]

Почему запись без стирания не считается изнашивающей операцией?

[xemul]

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

При мониторинге событий обычно интересны не только сами события, но и время их возникновения. Для мониторинга питания есть специально обученные логгеры у DallasSemi. По любому для этих целей удобнее удобнее использовать что-нибудь с более быстрым циклом записи, чем у ЕЕПРОМ.
А в качестве примера использования кольцевого буфера в EEPROM - те же одометры в машинках. В VW'ах, например, пройденный путь пишется в 3 байта, буфер или 24, или 48 байт (не помню, давно ковырял), дискретность записи (LSB) 100 м. Несложно подсчитать, что VW не расчитаны на пробег более 1677721 км

если сделать кольцевои счетчик из 256 баит то число перезаписеи и растет 256 раз. если из 512 баит то получится ок. 50 млн. циклов.
некоторые EEPROM ( и все FLASH) имеют запиь без стирания, там можно атомарно биты писать, каждыи баит при том имеет 9 состоянии : FF,FE,FC,F8,F0,80,40,20,10,00.

А можно ссылочку на pdf таких занятных EEPROM и всех FLASH, которые умеют писАть без (скрытого) стирания, да еще и по-битово?

[smk]

Несложно подсчитать, что VW не расчитаны на пробег более 1677721 км

А больше и не надо. Вообще-то и половины более чем достаточно.

Я имел ввиду ведение статистики наступления событий. Например производим ежесекундный мониторинг какого-то события. качество события может характеризоваться тремя значениями: не произошло; произошло, но мало; произошло полностью. Ну вот и пишем статистику, а при попадании изделия на ремонт или по снятии с эксплуатации читаем статистику и делаем выводы. Полезно с позиций оценки ресурса датчиков событий, например...

[Григорий2000]

Самое простое - это хранение в начале/конце еепром структуры с адресами "рабочих" структур счетчиков в которых содержится как значение, так и счетчик циклов(применяется некоторая неиспользованность и считаю только до 65535 а не 100к, хотя это - дело вкуса) и все!
перезапись каждой ячейки происходит гарантированно меньше 100к раз!

[Alex B._]

>> Но вот только ходят слухи, что главный бич FRAM-ок
>> - это нестабильность в общем полупроводниковом смысле
>> (от питания/температуры). Любопытно было бы послушать
>> "пострадавших".

да во многих счетчиках электроэнергии бытовых и промышленных стоит FRAM. Тестировали, дошли до 3E+7 циклов чтение-приращение-запись-проверка, дальше забили - уже превышает срок жизни изделия.
По поводу хитрых алгоритмов записи в EEPROM - смущает длительное время записи - вероятность потери данных выше (так как нужно использовать дублирование и при считывании мажоритарную выборку). Но в общем тоже сейчас над этим думаю... Правда стремно уходить от проверенных временем решений - сброс счетчика энергии это все равно что непрописать данные в фискальный модуль кассы =(

[defunct]

когда дойдем до 255 (или 65535 - это вряд-ли для встроенного EEPROM) и переполнимся - как писать/искать будем?

Нужно чтобы количество записей было меньше разрешающей способности счетчика, тогда с поиском никаких проблем. Вот набросал пример:

Код

#define STORAGE_SIZE 128

typedef struct tagSTORAGE_REC
{
    U8 Sequence;
} TSTORAGE_REC, *PSTORAGE_REC;

TSTORAGE_REC Storage[STORAGE_SIZE];

U8 MaxSequenceIndex(void)
{
    U8 retval = 0;
    U8 max = Storage[0].Sequence;
    U8 i;
    
    for (i = 1; i < COUNT(Storage); i++)
       if (max < Storage[i].Sequence)
       {
          max = Storage[i].Sequence;
          retval = i;
       }
    return retval;
}

#define Next( Index ) ((Index) >= (STORAGE_SIZE -1)) ? 0 : Index + 1;
      
void Store(void)
{
    U8 Idx = MaxSequenceIndex(); // index for the next cell to write data to
    U8 Sq = Storage[ Idx ].Sequence;
    
    if ( Sq == 0xFF )
    { // warp
       U8 OldSq;
       U8 delta;
       do
       {
           OldSq = Sq;
           Idx = Next( Idx );
           Sq = Storage[ Idx ].Sequence;
           delta = Sq - OldSq;
       } while (  delta == 1);
       Sq = OldSq;
    }
    else
    { // normal case
       Idx = Next( Idx );
    }
    Sq += 1;
    Storage[ Idx ].Sequence = Sq; // Записываем..
}