Easyelectronics.ru

Маячит девайс, где надо сохранять данные во внешнюю память. Сохраняются они часто, самое редкое - раз в секунду (FRAM, так что пофиг на такую частую запись).
Естественно девайс могут отрубить в любой момент, посему возник вопрос, как бы сделать так, чтобы при отключении оно не попало на серединку записи.
Пока вижу лишь следующую штуку:
- допустим у нас во FRAM есть данные SettingsMain, в которой у нас должны сохраняются все нужные данные. Из неё же при включении мы тянем все настройки, контроль целостности обеспечивает CRC.
- делаем во FRAM еще одну структуру SettingsMainSafe, которая является копией SettingsMain. Когда нам нужно что-то сохранить в память, первым делом мы записываем нужные данные в SettingsMainSafe.
- затем, мы начинаем копировать SettingsMainSafe в SettingsMain.
- если всё записалось корректно, то у SettingsMainSafe намеренно портим CRC, тем самым показывая, что данные более не актуальны, данные корректно сохранились.
- при включении питания, первым делом смотрим в SettingsMainSafe - если CRC там неверно, то ничего не делаем.
- если видим там актуальное CRC, то понимаем, что питание отрубилось в процессе перекидывания SettingsMainSafe -> SettingsMain, и еще раз пытаем записать.

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

Что я упустил? Пока такая "атомарность" видится наиболее простой в реализации.

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

Тогда надо как-то проц сказать что именно этот блок используемый. А если байт/флаг который как раз это говорит не запишется?

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

Самое простое - делаем две области + отдельный байт-индикатор в котором лежит номер последней записаной части. Далее пишем блок, если успешно, то обновляем байт-индикатор. Если неуспешно, то пофиг - байт-индикатор все равно показывает на последнюю валидную запись. Пишем, естественно, не в ту область, на которую указывает байт-индикатор.

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

2cheblin:
Мне не критично потерять данные, ионистор тут по перебору. Главное - чтобы данные не повредились, и настройки не сбросились в дефолтные при включении, когда CRC не сойдется.
2evsi:
Да, это актуально для логгера, некоего журнала. Тут журнал тоже будет, и такой вариант я рассматриваю. Там точно пофиг если потеряется последняя запись.
UPD: выше описанные алгоритм подсмотрен в TI, у чипа CC26xx, там так обновляется прошивка по воздуху.

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

2u37:
Но что будет, когда питалово отрубится в процессе записи такого блока? Включается питание, проц читает блок, видит что CRC не сходится, и сносит все настройки не дефолтные. Нехорошо. А так - некое резервирование, которое даёт гарантию, что блок если и не запишется, то хотя бы не повредится, что более важно.

Взять предыдущий, с номером N-1.

Ну т.е. в любом случае есть второй зеркальный блок, который по сути повторяет рабочий. Тогда это тоже самое, только номер мне ни к чему.

Не надо отдельный флаг, можно в каждом блоке хранить ID который каждый раз увеличивается на 1. При включении читаем все блоки (можно сделать больше двух) и берем блок с максимальным ID. При записи пишем в любое место за исключением этого блока с максимальным ID. Проще всего писать в следующий по адресам блок.

Без номера вы не будете знать, какой блок =последний=.

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

исключается дублирующая операция записи блока. Это же тоже время, зачем его тратить попусту?

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

а стоит вот это все 30 рублей.

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

Еще раз - никакой аварии нет. Никакой катастрофы от того что пропадёт питание и мы не сохраним данные нет. Вы предлагаете воткнуть ионистор (с хорошим сопротивлением еще надо поискать), добавить комплектухи, втыкать компаратор/вход АЦП чтобы мониторить пропажу питания и не сохранять данные когда с питаловом беда. Ну нафига? Памяти вагон, требований к быстродействию нет.

Не совсем понял про "программистские закосы" - это к чему было сказано?
Конфиг не конфиг, есть задача сохранять часто. Надо продумать, чтобы при этом не попортить уже сохраненные данные. Я не могу дать гарантии, что отрубится быстрее, проц или память.

Быстрое решение проблемы - EEram.
Если на пальцах и коротко, то это статическая память с автоматической записью содержимого в ЕЕ при отключении питания. Быстрая, ресурс не ограничен, стоит дешевле FRAM..

http://www.microchip.com/design-centers ... rial-eeram

Пять раз спасет если процессор просбоит от ЭМИ или иных гадостей

Не бывает правильных и неправильных алгоритмов. Можно лишь констатировать, насколько выбранный алгоритм подходит к той или иной системе команд (МК). И явно об этом надо рассуждать не на примерах с ЯВУ.

Какой ионистор? Кондера в 10мкФ хватит, чтобы пару сотен килобайт в EEPROM записать, да еще "I'll be back" в USART чиркануть…

Да и черт с ним: один раз на миллиард — меньший шанс, нежели он тупо сдохнет от какой-нибудь нелепой фигни...

зависит от нагрузки

достаточно небольшой допустимый диапазон для STM32 максимум 3.6V минимум 2V...

Спасибо, дружище! Не знал про это, делал тоже на конденсаторе и ЕЕпроме, а оказывается можно проще и лучше.