Алгоритм экономии ресурса EEPROM при записи счетчиков?
Разрабатываю любительское устройство, в котором будет счетчик с записью последовательных значений в EEPROM контроллера ATtiny13. Производитель гарантирует 100 000 циклов перезаписи, у меня может быть больше.
Вопрос в следующем - представим 16-битный, например, счетчик. При счете от 0000 до FFFF младший бит переключится 65536 раз, а старший бит - всего два раза! Т.е. износ ячеек получается очень неравномерный.
Существует ли алгоритм кодирования значений счетчика таким образом, чтобы равномерно изнашивать биты? Если нет, наверное его стоило бы разработать.
Однако тут возникает нюанс - как записывается байт? Он весь стирается и заново пишется, или пишется побитово?
Спасибо Серожа noneevgeniy_lmiv_k за советы! А если взглянуть на вопрос шире - есть ли специальные алгоритмы кодирования (без выделения плохихи блоков) для экономии ресурса ячеек при постоянной перезаписи инкрементных счетчиков? Ведь теоретически ресурс можно увеличить в разы.
Поясню: что если вместо поседовательности 00 - 01 - 10 - 11 писать например 00-01-11-10 ? В первом случае мы "дергаем" первый бит четыре раза, а во втором - только два.
не знаю что вы делаете, но я бы так EEPROM не стал использовать
Для этого есть оперативная память (которой в ATtiny13 нет, однако). Можно время от времени скидывать данные в EEPROM. Короче, либо меняйте МК либо алгоритм. Как вариант можно использовать внешнюю EEPROM или SRAM.
Ну можно другой МК взять - ресурс плюс-минус порядок, все равно немного. Зписывать собираюсь банально - показания счетчиков воды и газа. Тикают они каждые 10 литров. На 100 000 циклов выходит всего миллион литров или 1000 кубов воды - это расход средней квартиры за 3-4 года.
Александр: ну так сделайте как в коммерческих ПУ - внешняя SRAM + аккумулятор. Как правило небольшая память есть во всех часах, они вам все равно понадобятся
Александр: В расходомерах, корректорах газа и пр. фигне. Лень искать конкретно.
В принципе с подсчетом среднепотолочного расхода с большим успехом справляются механические ПУ (как раз они используются в коммерческом учете), электронные нужны там где требуется расчет (учет тепла, коррекция объема газа) или сбор статистики.
evgeniy_lm: У меня тогда не ПУ а скорее УСПД (ус-во сбора и передачи данных). Нужно собирать и передавать (куда следует). Соответсвенно нужно и хранить между сеансами связи, причем хранить очень аккуратно, не накапливая ошибку годами.
ставьте внешнюю NAND и пишите туда показания как архив. т.е. постоянно добавляя новые записи. текущие значения храните в регистрах. так сделано например в теплосчетчиках.
Александр: Дык, это и есть прибор учета. Они то же собирают и передают данные, это их основные функции. Возьмите, например, Arduino или отдельно Atmega328. Там 2Кб SRAM.
хранение можно производить в формате: время в сек. от опред. даты(3байта)+объем(1байт). Таким образом вы сможете хранить данные за полгода для каждого факта расхода (пошел расход, записали сколько). Если уж сильно надо можно порциями (1 раз в день или по необходимости) сбрасывать на внешнюю EEPROM или даже SDcard
если прибор будет сертифицироваться как средство учета - накладываются некие ограничения, например не получится ставить sd карту, память хранения архива должна быть под пломбой, прошивка и данные должны быть с проверкой контрольных сумм, метрологический код тоже и прочие штуки. весь перечень не знаю, уже давно этим занимался. перечень выдает орган сертификации, если что.
iv_k: А что мешает опломбировать sd карту? Или установить NAND на плату девайса? Ко всему прочему все известные мне сертифицированные ПУ почему-то делаются на очень дорогих STM32, а не на копеечных ATtiny
evgeniy_lm: надежность разъема в которые вставляется карта. ну или напаивать прямо ее на плату. обычно ставится наплатная NAND. да, и конечно же более толстые контроллеры. я лично разрабатывал на lpc2x, stm32 и msp430
iv_k: надежность разъема SD карты определяется исключительно частотой вынимания этой самой катры, т.е. в случае пломбировки надежность будет достаточно высокая.
Но топикстартер не конструирует коммерческий ПУ, как я понимаю ему нужен некий мониторинг "за недорого" для личных целей. Т.е. о сертификации речи не идет
iv_k: сертифицировать если будем (в далекой перспективе), то как средство измерения, а это уже не органы по сертификации делают, а Росстандарт на основании результатов испытаний аккредитованного в соответствующей области испытательного центра. Я довольно плотно с этой историей связан, если какие-то будут вопросы, сам смогу вам рассказать :)
evgeniy_lm: Кстати, почему? Испытателям не особо интересна реальная начинка устройства, а Росстандарту тем более. Главное чтоб заявленным Вами же характеристикам удовлетворяла по результатам испытаний.
Александр: Не знаю, я просто констатирую факт отсутствия сертифицированных устройств даже на Atmega (может вам такие встречались?). ATtiny вообще заточен для использования в простых исполнительных девайсах типа "включил/выключил". Использовать такие МК в системе мониторинга мне видится проблематичным, в особенности ATtiny13
evgeniy_lm: а как вы узнали, что их нет? В описании типа СИ не указывают элементную базу. Я даже не представляю, как это можно выяснить, не опрашивая всех подряд производителей устройств, внесенных в госреестр.
Александр: Я же писал, что таких не встречал, а сталкиваться приходится часто: ПУ тепла, расходомеры, корректоры газа, промышленные контроллеры. Часто стоит STM32, иногда что-то другое, но точно не AVR. Почему так я не знаю.
стирание байта - запись во все ячейки единиц.
без стирания можно писать в ту же ячейку нулевые биты.
но вообще надо смотреть как устроена вот та конкретная еепром.
Да они в принципе все одинаково устроены (полевик с конденсатором). Все зависит от технологии производства. В любом случае EEPROM слишком медленное устройство и не очень долговечное. С другой стороны она и не предназначена для оперативного использования. Исключительно для длительного, энергонезависимого хранения редко изменяемых данных, например, настроек.
Средний
Простой
