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

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

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

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

Вот тут:

Если при этом произошла ошибка - то при последующем чтении CRC пакета будет неверное и система будет считать, что тут "пусто"; данные будут прочитаны из последнего актуального пакета.

[galjoen]

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

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

Видимо в 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