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

только в этом патенте ругают и этот алгоритм...
а вот приветы от атмел, интел и микрософт.
курите на здоровье !
только результаты на общее обсуждение !

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

не копая глубоко, имею вопросы...
на ресурс памяти что оказывает большее негативное действие :
стирание или запись "0"?
при стирании подвергаются ли износу биты = "1" ?
всегда ли предшествует записи операция стирания ?
стирание едино для байта или индивидуально для каждого бита, в зависимости от его состояния ?
имеет ли смысл использовать вместо битов целиком байты ?( прописывать 00h или FFh, а при анализе сравнивать кол-во 0 и 1 в байте и принимать решение по большинству)
ущербная ячейка куда будет склонять - к 0 или 1 ?

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

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

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

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

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

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

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

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

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

Для Flash памяти стирание приводит к установке в 1. Запись осуществляет установку в 0.
Для ресурса имеет значение количество стираний.
Для EEPROM производится запись и поэтому разницы нет. Для ресурса имеет значение изменение состояния.
МСМ.

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

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

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

Сообщение отредактировал vazhko - Nov 6 2008, 10:08

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

А наверное енто всё так просто не просчитать..
Как я понял в ПЗУ организуется просто последовательный счётчик
Если места в EEPROMe много, что можно под бит использовать байт, то можно поступить и проще:
писать "прямым" и удобным для использования двоичным кодом и байт пряма в свой байт, но просто переносить весь (или начиная с младших байтов) в другие ячейки, а ячейки с выработанным ресурсов просто обходить.
В этом деле можно смотреть на какой-нибудь большой разряд (например 18) и по его сбросу делать перенос всего счётчика (или его части) в другой набор ячеек, отмечая это смещение в специальной ячейке.
вот и всё

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