А кто как организует в своих программах контроль завершённости, транзакции обновления базы данных Опции

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

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

[Непомнящий Евген...]

Только у меня не "флаг актуальности", а счётчик (2 байта). У кого он больше, тот пакет и последний.

На самом деле достаточно одного бита. Актуальный пакет находится "по переходу". Пример:

Код

Пакеты    П1    П2    П3
Флаг        1    1    0 Актуальный  - П2

Пакеты    П1    П2    П3
Флаг        1    1    1 Актуальный  - П3

Пакеты    П1    П2    П3
Флаг        0    1    1 Актуальный  - П1

и т.д.

В вашем случае получается примерно также, но вместо 1 бита вы храните 2 байта. Однако счетчик вероятно все равно может перескочить через 0 и вы получите тоже, что и у меня...

Вот я думаю, что для возможности восстановления повреждённой записи базы данных, разрушенной по причине незавершённости транзакции, [...]

У меня (см пример выше) П1, П2 и П3 - это НЕ КОПИИ. Это разные версии информации одного типа. Для верхнего примера П3 - самая младшая версия (из имеющихся), затем П1, затем П2 - актуальная версия. Когда мне придется сохранить информацию в очередной раз, пакет П3 будет затерт. Пусть при этом произошел сбой. Это значит, что я потерял самую старую версию информации (которая мне уже все равно не нужна). При следующем чтении будет прочитан П2, а П3 определен как "пустой".
Для такой схемы нужно как минимум 2 "слота" под однотипный пакет. Чем больше "слотов" тем сильнее "размазывается" ресурс епрома (и тем медленее происходит определение актуального пакета)