Кто как организует в своих программах контроль завершённости

[Дон Амброзио]

транзакции обновления базы данных во внутренней EEPROM или во внутренней FLASH микроконтроллеров ATmega? И кто как реализует откат назад в случае если обнаруживается, что предыдущая транзакция была прервана(не завершена)..А?

[Сэр Мурр]

Упс! Опять тема глобального масштаба! Вечером перенесу её в МЯУ!, поскольку предвижу ситуацию с ответами..

[Дон Амброзио]

Упс! Опять тема глобального масштаба! Вечером перенесу её в МЯУ!, поскольку предвижу ситуацию с ответами..

Ничего глобального? Просто обычная..
А можно Вас попросить не переносить, а удалять просто ответы не по теме и ответы, которые Вы уже предвитете? Ну хотя бы 2 дня? Ради эксперимента?
Просто если Вы её перенесёте в "МЯУ" начнётся то, что всегда происходит в "МЯУ" - флуд и гнусные оскорбления
Ну ради эксперимента.. Посмотрю... Сэр Мурр

[savage]

Это называется контрольная сумма. Не совпала - принять меры.
Тему можно закрыть

[Дон Амброзио]

Вот я думаю, что для возможности восстановления повреждённой записи базы данных, разрушенной по причине незавершённости транзакции, вызванной отключением питания нужно хранить каждую запись в 4-х экземплярах. Потому что если хранить в 3-х то не будет возможности восстановить запись методом мажоритарного голосования.

Рассмотрим пример с 3-мя копиями и объяснение почему 3-х копий не хватает.

Допустим мы обновляем запись в базе данных во внутренней FLASH (или EEPROM) микроконтроллера. Одну копию записи успеваем обновить полностью, а вот на середине обновления 2-й копии транзакция прерывается выключением питания.

В результате мы имеем:
1-я копия обновлена полностью
2-я копия обновлена наполовину
3-копия вообще НЕ обновлена

Как быть? Мажоритарным голосованием восстановить не получиться, т.е. у нас нет хотя бы 2-х одинаковых копий записи - все 3 копии различны. А вот если бы у нас было 4 копии, то мы бы смогли "откатить" запись на основании значений записи для 3-й и 4-й записи. А если бы, допустим, транзакция была бы прервана на середине не 2-й , а 3-й копии, то тогда мы смогли бы даже не откатывать запись, а продолжить и завершить транзакцию, взяв данные совпадающих между собой 1-й и 2-й копий

[Ватсон]

Можно сделать буффер и данные кидать кусками размером с этот буффер. У каждого куска есть свой порядковый номер и номер версии обновления. Кондёр по питанию поставить побольше с расчётом чотбы буффер успел записаться во флешь (епром)+детектировать снижение питающего напряжения.
Идея заключается в том что мы на 100% уверены в неповреждённости данных и можем восстановить передачу с прерванного фрагмента.
Это в дополнение к вашему 4х кратному резервированию.
НО не понимаю чем Вас не устраивает обычная контрольная сумма? не совпала идём и ещё раз обновляем

[Ватсон]

Копии кстати достаточно только 2. Обновляются по очереди.
т.е. имеем либо
1) обновлённая не до конца
2) предыдущая
либо
1) предыдущая
2) обновлённая не до конца
.

[Дон Амброзио]

Идея заключается в том что мы на 100% уверены в неповреждённости данных

Нет такой уверенности. Данные в EEPROM часто коцаются

[Дон Амброзио]

Копии кстати достаточно только 2. Обновляются по очереди.
т.е. имеем либо
1) обновлённая не до конца
2) предыдущая
либо
1) предыдущая
2) обновлённая не до конца
.

А как убедиться, что обновленная до конца или предыдущая целы? Если они всего в одном экземпляре? CRC не даёт 100% гарантии, что блок данных цел ибо разные блоки могут иметь одну и ту же CRC

[Ватсон]

А как убедиться, что обновленная до конца или предыдущая целы? Если они всего в одном экземпляре? CRC не даёт 100% гарантии, что блок данных цел ибо разные блоки могут иметь одну и ту же CRC

Глупость. Используйте CRC32 или, в конце концов, CRC64, и вероятность совпадения будет в 1000и раз меньше, чем вероятность попадания метеорита в конкретного человека.
Если и этого вам мало, побейте на блоки, как я сказал, у каждого блока есть №блока и №версии, тогда Вы можете быть на 1000% уверенным в своих данных.

[Дон Амброзио]

А как убедиться, что обновленная до конца или предыдущая целы? Если они всего в одном экземпляре? CRC не даёт 100% гарантии, что блок данных цел ибо разные блоки могут иметь одну и ту же CRC

Глупость. Используйте CRC32 или, в конце концов, CRC64, и вероятность совпадения будет в 1000и раз меньше, чем вероятность попадания метеорита в конкретного человека.
Если и этого вам мало, побейте на блоки, как я сказал, у каждого блока есть №блока и №версии, тогда Вы можете быть на 1000% уверенным в своих данных.

А сколько копий считаете целесообразным хранить?

А насчёт CRC64.. Зачем? Если вероятность того, что будут разрушены все копии гораздо больше, чем вероятность коллизии (когда разные записи имеют один и тот же CRC64)

[Ватсон]

А сколько копий считаете целесообразным хранить?

Я остаюсь при своём мнении, что больше 2х копий хранить нет смысла.

А насчёт CRC64.. Зачем? Если вероятность того, что будут разрушены все копии гораздо больше, чем вероятность коллизии (когда разные записи имеют один и тот же CRC64)

Не совсем понял. Почему все копии могут оказаться разрушенными?

[Дон Амброзио]

А сколько копий считаете целесообразным хранить?

Я остаюсь при своём мнении, что больше 2х копий хранить нет смысла.

Существует не нулевая вероятность случайной записи/стирания ячеек EEPROM сразу в обоих копиях.
Например если в момент загрузки значения в регистр EEAR прошла помеха и мы писанУли не в ту ячейку куда надо. И попали прям во 2-ю копию и повредили её. И в этот момент отрубили питание. В результате 2 копии оказались разрушенными.

Если взять больше 2-х копий эта вероятность снизится

А насчёт CRC64.. Зачем? Если вероятность того, что будут разрушены все копии гораздо больше, чем вероятность коллизии (когда разные записи имеют один и тот же CRC64)

Не совсем понял. Почему все копии могут оказаться разрушенными?

Ответил выше

[Ватсон]

Существует не нулевая вероятность случайной записи/стирания ячеек EEPROM сразу в обоих копиях.
Например если в момент загрузки значения в регистр EEAR прошла помеха и мы писанУли не в ту ячейку куда надо. И попали прям во 2-ю копию и повредили её. И в этот момент отрубили питание. В результате 2 копии оказались разрушенными.

Если взять больше 2-х копий эта вероятность снизится

В таком случае может быть попробовать 2 внешние последовательные ЕЕПРОМины?
Что за устройство делаете, если не секрет? Часовой механизм для атомной бомбы?

[Дон Амброзио]

В таком случае может быть попробовать 2 внешние последовательные ЕЕПРОМины?

А обоснование где? Ну что это существенно снизит вероятность потери данных.. Я пока чёта не понимаю.

Что за устройство делаете, если не секрет? Часовой механизм для атомной бомбы?

Шутки это конечно хорошо. У меня вполне рядовое простенькое устройство, но работающее в условиях жесточайших помех от импульсных токов в сотни Ампер. Настолько мощных, что даже после применения всех методов защиты аппаратуры от них все равно случаются и случайные джампы и порча ячеек EEPROM. Поэтому приходиться думать. Когда я перешёл от 2-х копий к 4-м количество случаев невосстанавливаемого разрушения информации в EEPROM сразу уменьшилось более чем в 10 раз

[Ватсон]

Шутки это конечно хорошо. У меня вполне рядовое простенькое устройство, но работающее в условиях жесточайших помех от импульсных токов в сотни Ампер. Настолько мощных, что даже после применения всех методов защиты аппаратуры от них все равно случаются и случайные джампы и порча ячеек EEPROM. Поэтому приходиться думать. Когда я перешёл от 2-х копий к 4-м количество случаев невосстанавливаемого разрушения информации в EEPROM сразу уменьшилось более чем в 10 раз

Проблемы лучше всего решать интенсивным путём, а не экстенсивным. Я ставил атмегу8 в пускатели 55КВт двигателей и всё было норм. Может Вам ещё раз стоит уделить внимание разводке пп и экранированию? Попробуйте не флешевый проц, а однократку + внешняя хорошая еепром.