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

Что-то я плохо понял суть вопроса, не похоже, что на него ожидается ответ. Уж не продолжение ли это "апрельских" тезисов?

И хорошо.. Кто "в теме" - тот поймёт.. А от тех кто не "в теме" мне ответы не нужны

В епром использую следующий механизм:
Группа параметров хранится в пакете. Пакет имеет CRC и флаг актуальности.
Для одной и той же группы параметров в епроме выделено место для нескольких пакетов (мимнимум 2).
При записи самый неактуальный пакет перетирается. Если при этом произошла ошибка - то при последующем чтении CRC пакета будет неверное и система будет считать, что тут "пусто"; данные будут прочитаны из последнего актуального пакета. При следующей записи такой неудачный пакет будет затерт новым.
Вот примерно так...

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

Вот тут:

Пользую примерно такой-же способ как 'Непомнящий Евгений'. Только у меня не "флаг актуальности", а счётчик (2 байта). У кого он больше, тот пакет и последний. Ещё по теме хочу сказать, что длина пакета в EEPROM д.б. кратна 8 и начинаться он должен с адреса кратного 8. Я к такому выводу пришёл, когда у меня 8 байт в EEPROM объFFились. Видимо в EEPROM всё таки какие-то блоки 8 байтные имеются.

Да нет наверное....
Это скорей всего потому у Вас 8-ми байтный блок объFFевился потому что у Вас "пакеты" в EEPROM по 8 байт, т.е. потому что Вы пишите в EEPROM 8-ми байтными блоками

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

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

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

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

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

Сообщение отредактировал Дон Амброзио - Mar 28 2008, 03:34

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

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


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

Не поверите - одним битом. Черным.
Сколько не пытались потом выбить прибор на ходу, в момент обновления firmware или базы данных, ни у кого не получилось. Ни у своих, ни у чужих.

Вероятность "слёта" (т.е. случайного изменения) бита 50% (слетит или не слетит)..

Так что ИМХО это ненадёжная защита...

Т.е. как у той блондинки.
- Какова вероятность, что вы встретите динозавра на улице?
-50 на 50. Или всречу, или нет.

Заливаем в ЕЕПРОМ данные хоть блоками по 1, хоть по 256 байт. Затем дожидаемся подтверждения, что данный блок успешно "лег" в ЕЕПРОМ. После этого шлем следующий блок данных. Если в течении нескольких итераций блок данных не попадает адресату, то значит нелады с получателем.
Всё. Тревожная ситуация.
Какой смысл дальше "орать" в пустоту?
Далее понятно.

У меня тоже счётчик. Надо сказать с ним есть непределённость определённая... Вобщем или кодов для счёта будет БОЛЬШЕ числа страниц flash для перезаписи. Или нельзя сказать чётко какая последняя. С битом -- это по-моему бред. Как там последнюю найти? Только если не удалять сразу неактуальные записи. Я вот не удаляю, стираю только при записи. А дописываю как есть по кругу (есть пул flash-страниц для циклической перезаписи). Да, когда у меня было всего 2 страницы в другом приборе, там было 2 БИТА. Ибо по 1 биту нифига непонятно кто последний в таком случае. А так есть серия номеров последовательно с разрывом (зацикленность опускаем), соответственно тот что перед разрывом -- последний. Поэтому номеров и БОЛЬШЕ должно быть чем страниц.

Да, про неопределённость. Это когда разрывов в нумерации больше одного. Тут хоть по rand() выбирай нужный блок...

Сообщение отредактировал Kirill Frolov - Mar 28 2008, 20:07

см разобранный пример выше. Записи никогда не удаляю. Самая старая просто перетирается, когда надо записать новую.