[yafalschivii 0]

всё и в правду, покажется просто, если поймёшь код Бина

[НЕХ 4]

только в этом патенте ругают и этот алгоритм...

а вот приветы от атмел, интел и микрософт.

курите на здоровье !

только результаты на общее обсуждение !

US6792065.pdf

US7065607.pdf

US6249562.pdf

[vazhko 0]

только в этом патенте ругают и этот алгоритм...

а вот приветы от атмел, интел и микрософт.

курите на здоровье !

только результаты на общее обсуждение !

Еще раз спасибо. Отпишусь обязательно, только закончу предыдущий проект.

[НЕХ 4]

не копая глубоко, имею вопросы...

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

стирание или запись "0"?

при стирании подвергаются ли износу биты = "1" ?

всегда ли предшествует записи операция стирания ?

стирание едино для байта или индивидуально для каждого бита, в зависимости от его состояния ?

имеет ли смысл использовать вместо битов целиком байты ?( прописывать 00h или FFh, а при анализе сравнивать кол-во 0 и 1 в байте и принимать решение по большинству)

ущербная ячейка куда будет склонять - к 0 или 1 ?

[vazhko 0]

имеет ли смысл использовать вместо битов целиком байты ?( прописывать 00h или FFh, а при анализе сравнивать кол-во 0 и 1 в байте и принимать решение по большинству)

ущербная ячейка куда будет склонять - к 0 или 1 ?

Совершенно верно. Так и планирую сделать. Не вдаваясь в подробности функционирования EEPROM конкретного взятого контроллера. Обращение (запись/чтение/ стирание) к ячейке EEPROM происходит побайтно. Стирание перед записью обязательно. Какие операции оказывают негативное воздействие не знаю. Надо читать теорию.

[НЕХ 4]

а попадались ли рекомендации непосредственно производителей контроллеров на эту тему ?

[vazhko 0]

а попадались ли рекомендации непосредственно производителей контроллеров на эту тему ?

Не попадались, по крайней мере у Микрочипа.

[atlantic 0]

Прошу помощи в следующей задаче.

Имеем массив энергонезависимой памяти (EEPROM) с ограниченным количеством перезаписи битов(число перезаписей около 1Е6).

Надо каждый раз писать в эту память значения счетчика при его инкременте. Допустим счетчик 32-битный. При инкременте на единицу, младший бит регистра изменяется настолько часто, что можно получить его неработоспособность всего регистра еще до того, как он заполнится. Соответственно, старший бит измениться всего один раз. Существует ли алгоритм такого представления числа(прямой и обратный, на подобие кода Грея), чтобы при последовательном инкременте до заполнения регистра, количество модификаций битов в регистре была примерно равна и минимальна. Разрядность преставления может быть больше разрядности самого числа.

У вас в вопросе уже готовый ответ, как биты не переставляй а гарантированный срок службы EEPROM 1-миллион циклов записей. Вам надо определится как часто будет запись, а то

изменяется настолько часто что можно получить его неработоспособность

это не цифры, например 1 раз в секунду, или сколько ?

 

если речь идет о количествах циклов записи более 10 тысяч в год, то для таких целей вероятно следует использовать другой тип памяти - энергонезависимое ОЗУ, например ibutton, срок службы ~10 лет,если мало то по прошествии срока, стоит обновить девайс :-)

[vazhko 0]

У вас в вопросе уже готовый ответ, как биты не переставляй а гарантированный срок службы EEPROM 1-миллион циклов записей.

Не всего EEPROM, а стираний/записей в конкретный регистр. Причем под 1 бит, будет отводится 1 байт.

изменяется настолько часто что можно получить его неработоспособность

это не цифры, например 1 раз в секунду, или сколько ?

Речь идет об относительной частоте. При заполнении счетчика в обычном представлении или в стандартном коде Грея, биты переключаются разное количество раз, а младший чаще всех. Задача выравнять количество переключений бит, но чтобы отличие соседних чисел в счетчике было только в одном разряде.

если речь идет о количествах циклов записи более 10 тысяч в год, то для таких целей вероятно следует использовать другой тип памяти - энергонезависимое ОЗУ, например ibutton, срок службы ~10 лет,если мало то по прошествии срока, стоит обновить девайс :-)

Есть разные хардварные решения данной задачи и попроще, чем применение энергонезависимого ОЗУ. Но, в данном конкретном случае, интересна именно программная реализация, т.к. задача не с нуля - железо УЖЕ есть.

[alexander55 0]

не копая глубоко, имею вопросы...

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

стирание или запись "0"?

при стирании подвергаются ли износу биты = "1" ?

всегда ли предшествует записи операция стирания ?

стирание едино для байта или индивидуально для каждого бита, в зависимости от его состояния ?

имеет ли смысл использовать вместо битов целиком байты ?( прописывать 00h или FFh, а при анализе сравнивать кол-во 0 и 1 в байте и принимать решение по большинству)

ущербная ячейка куда будет склонять - к 0 или 1 ?

Для Flash памяти стирание приводит к установке в 1. Запись осуществляет установку в 0.

Для ресурса имеет значение количество стираний.

Для EEPROM производится запись и поэтому разницы нет. Для ресурса имеет значение изменение состояния.

МСМ.

[atlantic 0]

Не всего EEPROM, а стираний/записей в конкретный регистр. Причем под 1 бит, будет отводится 1 байт.

 

это не цифры, например 1 раз в секунду, или сколько ?

 

Речь идет об относительной частоте. При заполнении счетчика в обычном представлении или в стандартном коде Грея, биты переключаются разное количество раз, а младший чаще всех. Задача выравнять количество переключений бит, но чтобы отличие соседних чисел в счетчике было только в одном разряде.

 

Есть разные хардварные решения данной задачи и попроще, чем применение энергонезависимого ОЗУ. Но, в данном конкретном случае, интересна именно программная реализация, т.к. задача не с нуля - железо УЖЕ есть.

И всетаки, какой EEPROM и сколько(в абсолютных величинах- разы :) циклов записи в год предполагаете?

 

Может чего-то я не понимаю ? Есть даташит на девайс, там оговорено максимальное кол-во циклов, причем не очень четко, т.е. для своих целей надо брать с запасом. Как бы биты не переставлялись, а операции записи от этого не уменьшатся(в кол-ве раз) так ведь, или я что то не понял? Как внутри работает EEPROM четко не специфицируется, и расчитывать на то, что при записи одинаковых значений несколько раз подряд, будь то хоть 0 хоть FF, общее кол-во допустимых(при которых нет отказов) циклов записи уменьшится нет никаких оснований. Есть физические процессы которые влияют на отказы при записи, и они зависят от температуры окружающей среды, напряжений питаний, технологии по которой изготовлена EEPROM. В даташите приведен усредненный параметр работы без отказов. Самый надежный способ работать без отказов - это придерживаться параметров даташит с запасом.

[vazhko 0]

Может чего-то я не понимаю ? Есть даташит на девайс, там оговорено максимальное кол-во циклов, причем не очень четко, т.е. для своих целей надо брать с запасом. Как бы биты не переставлялись, а операции записи от этого не уменьшатся(в кол-ве раз) так ведь, или я что то не понял? Как внутри работает EEPROM четко не специфицируется, и расчитывать на то, что при записи одинаковых значений несколько раз подряд, будь то хоть 0 хоть FF, общее кол-во допустимых(при которых нет отказов) циклов записи уменьшится нет никаких оснований.

Дык, в том и прикол, что перезаписываюся только изменившиеся биты. И только один (в идеале) за инкремент. Нет смысла перезаписывать ту позицию, которую не надо менять.

Изменено 6 ноября, 2008 пользователем vazhko

[scifi 1]

Речь идет об относительной частоте. При заполнении счетчика в обычном представлении или в стандартном коде Грея, биты переключаются разное количество раз, а младший чаще всех. Задача выравнять количество переключений бит, но чтобы отличие соседних чисел в счетчике было только в одном разряде.

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

[GoGus 0]

А наверное енто всё так просто не просчитать.. :)

Как я понял в ПЗУ организуется просто последовательный счётчик

Если места в EEPROMe много, что можно под бит использовать байт, то можно поступить и проще:

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

В этом деле можно смотреть на какой-нибудь большой разряд (например 18) и по его сбросу делать перенос всего счётчика (или его части) в другой набор ячеек, отмечая это смещение в специальной ячейке.

вот и всё

 

Да. Есть подозрение, что часто используемые ячейки не дадут паспортной длительности хранения (а ещё перепады температуры и т.п.).