Завершение переходного процесса в EEPROM

[NStorm]

Ус-во на атмеге, в EEPROM хранятся настройки и состояние. Для wear leveling, всё это дело пишется в виде кольцевого буфера, сохраняя номер последовательности.
Есть переходные процессы (смена состояния), которые физически могут занимать 5-10 сек. И вот надо бы отслеживать если процесс почему-то прервется (питание пропало и т.д.).
Какая пока мысль - перед сменой состояния пишем новую структуру в EEPROM со следующим ID последовательности, но без CRC. Как только смена состояния успешно прошла - дописываем CRC этого блока. Следовательно когда мы загружаем последний блок при старте - если CRC не совпадает, считаем что прошлый смена состояния не завершена, а из прошлого блока читаем соб-но прошлое состояние. И доделываем переход, и дописываем корректный CRC.
Почему CRC - ну чтобы отдельный байт под "успешно" не тратить. О чем нам еще может говорить битое CRC? Либо мы не успели записать нормально, либо произошел сбой EEPROM. Но в этом случае и в прошлом блоке с большой вероятностью будет битое CRC - тогда уходим в режим "авария, требуется ручное вмешательство".
Это в общем-то наверное будет работать. Но пока не реализовал, может у кого лучше идеи или критика будет.

[BOB51]

Встроенная в МК ЕЕПРОМка?
Или внешний кристалл?

[NStorm]

Встроенная, atmega8.

[ARV]

я не очень понял задачу... смутило "и т.д.".
отслеживать пропадание питания проще и лучше по MCUSR - там флажок есть PORF для этого.
перед началом вашего переходного процесса устанавливаете битик в переменной, после завершения смотрите, на этот битик и PORF - если PORF вдруг установлен, то был сбой и битик надо игнорировать. таким образом вы и будете отслеживать сбои, а отследив их - переписывать EEPROM.

или у вас EEPROM обновляется во время этого длительного перехода?

[NStorm]

ARV, не совсем понял - после перезапуска питания битик с переменной всегда будет 0, потому что SRAM очиститися )
Во время перехода EEPROM не обновляется. Но мне при PORF (или BORF, потому что BOD будет тоже включен кстати) надо понимать с какого на какое состояние шел переход, чтобы его корректно завершить.
И т.д. соб-но помимо пропадания питания соб-но - либо BORF, либо WDRF (вотчдог во время перехода будет сбрасываться, если всё идет нормально).

[BOB51]

При высоких требованиях к защите данных без резервного аккумулятора НЕ ОБОЙТИСЬ.

[ARV]

после перезапуска питания битик с переменной всегда будет 0, потому что SRAM очиститися

нет, после перезапуска из-за сбоя питания содержимому битика нельзя доверять (он может быть ка 0, так и 1), а вот после обычного СБРОСА (при нормальном, не исчезающем питании) содержимое битика будет сохранено, если переменную вы поместите в секцию .noinit

Добавлено after 3 minutes 10 seconds:

надо понимать с какого на какое состояние шел переход, чтобы его корректно завершить

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

[NStorm]

BOB51, особо высоких требований нет. Питание на самом деле и так через ИБП. Даже есть отдельная субсхемка мониторинга отдельно сетевого напряжения. Но исключать сброс/отключения МК по некоей причине во время перехода это всё-равно не позволяет.

ARV, обычный сброс (EXTRF) кстати не предусмотрен.

Добавлено after 3 minutes 39 seconds:

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

Мне надо еще понимать в т.ч. и КУДА шел переход. Если в переменной - после пропадания питания я уже это не узнаю. Поэтому и не подходит.

Грубо говоря: начинаем переход -> записываем новое состояние в EEPROM. Переход завершили -> дописываем дальше флаг окончания перехода.
Только в кач-ве флага у меня идея использовать не просто бит, а CRC блока с состоянием и настройками (он всё-равно вычитываться целиком будет).

Добавлено after 9 minutes 37 seconds:
Простой пример сейчас в голову пришел, чтобы понятнее было - дворники в авто. Допустим, обратная связь у нас только по концевикам крайних положений и всё. После пропадания питания во время движения дворников, после возобновления подачи питания, они всё-равно завершают свой цикл - если остановились на движении "вперед" - пройдут "вперед" до конца, и назад до конца. Если на движении "назад" - дойдут назад до конца.

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

[ARV]

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

[BOB51]

Самый простой способ - буфер данных из которого проводится запись в ЕЕПРОМ с последующим чтением записанного и сверкой с буфером исходных данных.
Как вариант - использование внешнего энергонезависимого ОЗУ (допустим... та же DS1307...) - запись там практически мгновенная.
(Когда-то делался счетчик на такой основе).
При пропадании питания у самого МК никакой гарантии, что содержимое временного буфера исходных данных будет без повреждений нету.
Обнаружив "возмущающее воздействие" (бросок по питанию) в любом случае перезапускаем/перезагружаем все критичные ресурсы.

[NStorm]

ARV, Речь не о сбое во время записи в EEPROM, а о сбое во время самого переходного процесса.
Поэтому и мысль ДО начала переходного процесса записываем следующее состояние в EEPROM - успешно записались и только тогда начинаем сам процесс перехода. Если он завершился без сбоя - дописываем дальше еще флаг успешного завершения перехода. Который как я в прошлом комментарии написал - планирую использовать CRC от прошлых данных, которые ДО перехода были сохранены.

[BOB51]

Если сбой по питанию - то уже о верности исходных данных можно забыть.
А для ЕЕПРОМКИ...
Лучше тогда использовать жестко формализованную запись одинакового размера и оформления.
При восстановлении работы проверяем массив на контрольные точки начала записи, считываем и проверяем последнюю на предмет целостности (стартовый байт, стоповый байт, контрольная сумма (CRC для куражу).

Допустим тот же формат INTEL hex8...
Или блок из 8 байт с CRC микро лан - но... там начало и конец записи не различимы, если записи стоят друг за дружкой впритык.

[NStorm]

BOB51, это излишне в данном проекте мне кажется. Да и аппаратные вмешательства не хотелось бы рассматривать. Целостность буфера будет подтверждать CRC, которая записывается ПОСЛЕ перехода. Пропадание питания во время записи EEPROM очень маловероятно - 8.5мс на байт, у меня там данных блок всего 6 байт. И ИБП есть, как я говорю.
Переходные процессы - соб-но кручение разных моторчкиов. Соотв. жрут сильно больше МК во время работы. И их нужно проводить в т.ч. даже при питании от батареи. Вот тут и есть мысль поэтому - записали блок "куда" идем - и начинаем крутить моторы. Если тут просядет или пропадет напряжение - после возобновления питания уже будем знать "откуда и куда мы шли".

[BOB51]

Это вполне решаемо аппаратно - ставим по питанию у МК приличной емкости конденсатор, отделенный от питания остальной части схемы диодом...

[NStorm]

Как вариант, что-то вроде журнала в журналируемых файловых системах, только в примитивнейшем виде для МК и соотв. размера EEPROM. Перед записью данных, писать их "метаданные". Только в обратном порядке. ) Потому что сами данные у меня занимаю тоже очень мало.

В общем я тут подумал еще и думаю надежнее всё-таки как-то так примерно. Структура данных одинаковая, фиксированный размер:
[порядковый номер блока + данные + CRC16] 12 байт + [CRC8 ] 1 байт + [PADDING ?]
CRC16 от порядкового номера блока + данных, а CRC8 от них + еще CRC16.
Перед переходным процессом сначала зачищаем (т.е. перезаписываем в 0xFF) в EEPROM данные по позиции CRC8 и PADDING'а, если буду его использовать (ну просто чтобы кратное объему EEPROM было). Потом пишу всю первую часть. После перехода дописываю корректный CRC8. Итого имеем CRC16 для признака корректной записи данных ДО перехода, а CRC8 как признак корректного завершения перехода. Если вместо CRC8 - 0xFF - значит переход начался, но успешно не завершился. Если CRC8 или CRC16 не совпадает - значит это уже сбой данных во время записи EEPROM, тут режим аварии включаем.

PS: Битность CRC пока просто для примера. Можно и больше сделать.
PPS: Я ж правильно помню, что для очистки байта EEPROM в ATMega его можно записать в 0xFF?

[ARV]

Речь не о сбое во время записи в EEPROM, а о сбое во время самого переходного процесса.

я, конечно, извиняюсь, но с чего вдруг вы так уверены, что во время записи в EEPROM питание у вас не пропадет, если предполагаете, что оно может пропасть во время другого процесса?

что-то вроде журнала в журналируемых файловых системах

журналируемые ФС имеют возможность ОТКАТА к известному состоянию, но никак не ПРЕДУГАДАНИЯ несостоявшегося. а у вас при сбое требование знать "будущее" состояние. прошлое у вас есть, а будущее - как узнать? журнал - это ИСТОРИЯ... т.е. только то, что было.

[NStorm]

я, конечно, извиняюсь, но с чего вдруг вы так уверены, что во время записи в EEPROM питание у вас не пропадет, если предполагаете, что оно может пропасть во время другого процесса?

Не уверенность, но как пишу очень маловероятно - несоизмеримость времени и тока потребления + наличие ИБП.
Ну и CRC есть, который пишется последним.

[ARV]

как пишу очень маловероятно

вероятность этого события ровно такая же, как и любого другого - 50% либо будет, либо нет.

смотрите: какая бы ёмкость в БП у вас ни была, все равно момент, когда напряжение питание станет меньше допустимого, наступит обязательно, если основное питание исчезнет. и момент наступления этого события может совпасть с записью в EEPROM любого байта.

таким образом, увидев, что CRC у вас некорректна, какой вывод вы сможете сделать? вы сможете из предыдущей записи с корректной CRC узнать предыдущее состояние, но как вы собираетесь узнавать то состояние, в которое пытались перейти?

[musor]

исползовани встроеной епром ка буфера промежуточногьт хранения идея хреновая по ресурсу -он будет выработан очень быстро я уж не говоря об тратак на обращени туда с контролем
разумне это сделать с внешней памятью на шине I2C|SPi сответсвующе избыточного обьема чтоп перезаписи практически не было в штатном режиме

Добавлено after 2 minutes 30 seconds:
я пормню теле где проц с встроеной епромкой был через год 2 ячейки громкости дохли
иногда дохли и те куда пишут настройки програм
тогда плата шла в мусор посколку чип не имел возможности прицепить доп епром

Добавлено after 2 seconds:
я пормню теле где проц с встроеной епромкой был через год 2 ячейки громкости дохли
иногда дохли и те куда пишут настройки програм
тогда плата шла в мусор посколку чип не имел возможности прицепить доп епром

[NStorm]

ARV, я же поэтому в позапрошлом комментарии и написал, что пока пришла мысль использовать 2 CRC. CRC1 пишется ДО начала любого перехода. Даже перечитать его можно, проверив, что он корректно записался и данные совпадают. И только потом начинаем переход. И если он успешно завершился - пишем CRC2.

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