Как известно, почти все современные МК обладают встроенной EEPROM данных. Хотя ресурс данной памяти довольно велик, он всё же ограничен, и приведён в даташитах. А вопрос, каков механизм записи в EEPROM? Т.е. идёт "изнашивание" всей памяти, или только той ячейки, к которой обращаются?
_________________ ICQ нет, и, в ближайшее время, не будет.
Страничную организацию имеет flash-память, и для нее правила другие. EEPROM-же страниц не имеет, это одно из основных отличий от flash с т.з. пользователя.
maglev, тенкс! Только поясните, правильно ли я понял, что с "изнашиванием", память перестаёт стираться (т.е. все биты выставляться в "1"), и при записи, нестёртые биты остаются в исходном состоянии, а те, которые программируются (в которые записывается "0"), программируются нормально?
_________________ ICQ нет, и, в ближайшее время, не будет.
Память перестает стираться (стирание это запись "1"), дохлый бит остается в нуле. Но я-бы не рассчитывал на эти тонкости, т.к. заявленный ресурс она отрабатывает гарантированно во всем диапазоне температур и напряжений, а испорченные ячейки могут повести себя непредсказуемо. Охладишь или нагреешь - возможна спонтанная регенерация, потом опять вывалится.
Память перестает стираться (стирание это запись "1"), дохлый бит остается в нуле.
Ну, я так примерно и сказал. Просто сейчас пишу программу, где надо периодически сохранять данные. Данных всего один байт, поэтому сделал алгоритм проверки записи, и, при ошибке, смены адреса ячейки.
_________________ ICQ нет, и, в ближайшее время, не будет.
алгоритм проверки записи, и, при ошибке, смены адреса ячейки.
Я-бы так не делал, если правильно понимаю идею. Ты используешь одну ячейку до исчерпания ресурса, надеясь поймать момент, когда она умрет. Этот момент надежно поймать нельзя. Правильнее писать каждый раз в новые адреса, размазывая (гарантированный) ресурс на количество используемых ячеек. Так обычно и делают, если имеет смысл по количеству планируемых перезаписей.
А какова вероятность, что новые данные не равны уже записанным? Или там случайное число 0-255? А то можно перед записью проверять, вдруг и записывать ничего не нужно, тогда еще немного ресурс сэкономится.
Почему же? Если верификация записи не проходит, вот и "момент".
Тебе правильно сказали что записывать в одну и туже ячейку ожидая что она даст сбой записи это не оптимальный вариант, по той например причине что ячейка с выработанным ресурсом может нормально записаться но например считаться неверно позже. Грубо говоря не все ошибки при записи и чтении можно отследить. Я когда делал такую вещь использовал распределение записи. В епромке ресурс тратится при любом изменении состояния битов, так что есть вариант записывать (не стирая) например одну и туже ячейку несколько раз подряд (8 на самом деле) обнуляя биты по очереди получая для одной ячейки тот же ресурс при 8кратном увеличении количества физических записей, при этом ты можешь использовать содержимое такой ячейки как указатель. Сама схема такая, выбираешь сколько тебе нужно ячеек, разбиваешь их на две группы - указатель и данные. Указателей в 8 раз меньше чем данных. Потом при записи ты последовательно обнуляешь биты в указателях, записывая в соотв ячейку данных новые. Ресурс увеличивается пропорционально количеству ячеек под данные. Те при использовании 9 байт = 1байт указатель и 8 байт данные, ресурс будет в 8 раз больше. Количество ячеек можно рассчитать. Ресурс среднего епрома 1 миллион перезаписей, это примерно 11 дней можно записывать новые данные в одну ячейку раз в секунду. Если требуется к примеру ресурс в 5 лет то 5 лет *365 дней/ 11 дней = 165 ячеек данных + 165/8 ~ 20байт указателей. Естественно все эти расчеты будут другими если частота записи отличается от раза в секунду.
_________________ Информация по RLC mini находится >тут<
Простите, что влезаю. Но ведь запись в EEPROM в основном используется для спасения каких-то данных на случай пропадания питания. Может и тут такой случай и достаточно поставить конденсатор на питание МК и как то отслеживать наличие напряжения питания и в случае чего писать в EEPROM, а не периодически. Конечно возможно, что конденсатор некуда поставить или ног не хватает для отслеживания питания. В этом случае конечно "такраканы пассуют".
Но ведь запись в EEPROM в основном используется для спасения каких-то данных на случай пропадания питания.
Не обязательно. Может быть, ведется журнал событий. Если держать его в ОЗУ, а в момент пропадания питания переписывать в EEPROM, то простого конденсатора по питанию явно недостаточно - это не умозрительно, сам на этом деле долго ломал бошку. Нужен автомат питания, который четко отследит момент, начиная с которого энергии хватит только на записать в EEPROM. И если в процессе записи питание восстановилось, тем не менее закончить запись. А если не восстановилось, во избежание автколебательного процесса по питанию включить все допустимые нагрузки, и как Титаник, уйти на дно с включенной илюминацией - сбросить энергию из накопительных конденсаторов. И тут еще возникает проблема работы при длительном провале питания ( например, рядом двигун мощный раскручивается ). Проблема, конечно, не из разряда неразрешимых, но в пол-пинка не делается. Вот вариант с указателями (Neekeetos) мне нравится - красиво.
Заголовок сообщения: Re: Механизм записи и увеличение ресурса EEPROM у МК
Добавлено: Чт мар 17, 2011 00:01:12
Друг Кота
Карма: 25
Рейтинг сообщений: 99
Зарегистрирован: Вс янв 24, 2010 19:19:52 Сообщений: 4468 Откуда: Главный Улей России (Moscow)
Рейтинг сообщения:0
А я бы так сделал: Данные держал бы в ОЗУ и в случае отключения питания сохранил бы в EEPROM, но запитав МК по такой схеме:
Отслеживать питание ногой РХ1 и после всей процедуры отключить МК от батареи, выставив лог. 0 на ноге РХ0 Ногу РХ1 можно настроить как внешнее прерывание по спадающему фронту и в обработчике произвести запись в EEPROM. В конце обработчика выставить ногу РХ0 в лог. 0 Для защиты от кратковременных отключений питания, можно повесить электролит в пару сотен мкф между ногой PX1 и массой, но наверное надо будет устранить утечку заряда из него, поставив в цепи PX1 диод и кондёр этот подключить после него.
Как уже говорили, довольно сложная аппаратная реализация. В моём случае, вдобавок, конструкция уже готовая, переделке не подлежит, а надо новую прошивку.
maglev писал(а):
А завтра форточку открыли, или солнышко с утра пригрело, или конденсатор в питателе подсох
Или бульдозером наехали, или кислотой облили...
Jack_A писал(а):
Вот вариант с указателями (Neekeetos) мне нравится - красиво.
Допустим, теория с побитным изнашиванием верна. Тогда поясните, что за МК такой, который позволяет запись осуществлять без стирания?
Если говорить об извращениях, могу ещё один вариант предложить. Если достаточно семи битов данных, то восьмой можно использовать в качестве указателя. И никаких дополнительных ячеек.
_________________ ICQ нет, и, в ближайшее время, не будет.
Заголовок сообщения: Re: Механизм записи и увеличение ресурса EEPROM у МК
Добавлено: Пт мар 18, 2011 12:55:01
Друг Кота
Карма: 25
Рейтинг сообщений: 99
Зарегистрирован: Вс янв 24, 2010 19:19:52 Сообщений: 4468 Откуда: Главный Улей России (Moscow)
Рейтинг сообщения:0
Dmitry Dubrovenko писал(а):
Тогда поясните, что за МК такой, который позволяет запись осуществлять без стирания?
ATTINY26L. Даю полную гарантию, что новые данные можно писать в EEPROM поверх старых, без предварительного стирания. А вот FLASH требует предварительного стирания. Я уже много проектов сделал с использованием записи в EEPROM.
_________________ I am DX168B and this is my favourite forum on internet!
Тут копируются байты из массива в EEPROM. Извратов не пугайтесь. Это маленький отрывок большой программы. По окончанию процедуры записи стоит вырубить прерывание по готовности EEPROM, иначе оно Вас зае***т в процессе работы программы. Незнаю, как в других МК, но тут такая мелкая гадость.
_________________ I am DX168B and this is my favourite forum on internet!
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения