Как стать автором
Обновить

Комментарии 16

Добивайте EEPROM посредством внедрения FRAM.
Классическое решение из флеш памяти:
После стирания у нас все биты в 1.

1. Состояния счетчика можно записывать побитно без стирания как 11111110,11111100,11111000 и т.д.

2. В случае если данные не могут быть равны 0 (например путем добавления бита четности или помехоустойчивых кодов) используем кольцевой буфер, а старые данные забиваем нулями.
Для побитного обновления счетчика самое лучшее, что мы можем сделать, это использовать коды Грэя, как и сказано в статье. При этом мы получаем не 8 возможных значений счетчика для восьми бит, а все 256.
нет, так же останутся 8 возможных значений. Коды грея работают как 1->0 так и 1->0.
И какая разница в каком порядке занулить если поставить единицу сложно и надо избегать.
Коды Грея дают такое же количество комбинаций для одного и того же количества бит, что и прямой код. На двух битах возможно получить четыре разных значения кодов Грэя, на трех битах — восемь разных значений кодов Грея, и т.д.

Код Грея на Википедии
Суть в том, что изменение 1 -> 0 делается просто, а 0 -> 1 только через стирание. Коды Грея требуют обеих операций.
получить можно, но EEPROM придется каждый раз стирать, а от этого пытаются уйти
лучший способ: кольцевой буфер, со счетчиком номера в структуре данных, находится вроде за log(n)
Хранение данных в оперативке + ионистор, запись в flash/eeprom только при пропадании основного питания.

Ячейки памяти убивают люди! ;) Писали как-то драйвер по работе с flash, ошиблись в цикле — приращали не адрес, а значение по адресу. Память убивается за несколько секунд…
А какую схему заряда ионистора используете? Ведь разряженный он потребует большого тока при старте.
Ограничитель тока на паре транзисторов отлично справится
current limiter
Это схема, как я понял, для ограничения зарядного тока ионистора, а если необходимо защитить ионистор от перенапряжения?
Не подавать на ионистор напряжение больше, чем тот сможет выдержать. Ионистор на 5,5В? Заряжайте от 5В.
Ионистор защитит только от пропадания питания.
Какая нибудь другая внезапная гадость типа программного\аппаратного сбоя или разрушение устройства не даст записать последние данные (это из обсуждения реализации регистратора в аварии в московском метро).
надежность оборудования в различных ситуациях закладывается на этапе разработки
вы не можете винить разработчиков за то что ваш регистратор расплавился в жерле вулкана и не сохранил данные
Естественно, обвинять разработчиков в том, что устройство не выполняет то, чего не требует ТЗ не следует.

А в топике скорее обсуждается вопрос как реализовать хранение актуальных данных, которые переживут внезапное прекращение работы устройства и при этом не затереть флешку до дыр.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории