Безопасное хранение и доступ к EEPROM
Недавно я обнаружил необходимость хранить редко обновляемые конфигурационные переменные в EEPROM микроконтроллера. Добавление состояния в программу немедленно заставляет беспокоиться об обнаружении
- неинициализированных данных в EEPROM (то есть первой загрузки),
- преобразовании или аннулировании данных из старых версий прошивки и
- адресации нескольких структур, каждая из которых которые могут расти с обновлениями прошивки.
Обширный поиск в Google дал только одну статью, которая касается обеспечения достоверности данных EEPROM с помощью обновлений прошивки . Кто-нибудь использовал подход, описанный в этой статье? Есть ли лучший альтернативный подход?
2 ответа
Лично я предпочитаю формат «таблицы с тегами».
В этом формате ваши данные разделены на серию «таблиц». Каждая таблица имеет заголовок в предсказуемом формате и тело, которое может меняться по мере необходимости.
Вот пример того, как будет выглядеть одна из таблиц:
Byte 0: Table Length (in 16-bit words)
Byte 1: Table ID (used by firmware to determine what this data is)
Byte 2: Format Version (incremented every time the format of this table changes)
Byte 3: Checksum (simple sum-to-zero checksum)
Byte 4: Start of body
...
Byte N: End of body
Я не хранил много данных, поэтому я использовал один байт для каждого поля в заголовке. Вы можете использовать любой размер, который вам нужен, но никогда не меняете его. Таблицы данных записываются одна за другой в EEPROM.
Когда вашей прошивке необходимо прочитать данные из EEPROM, она начинает чтение с первой таблицы. Если микропрограмма распознает идентификатор таблицы и поддерживает указанную версию таблицы, она загружает данные из тела таблицы (конечно, после проверки контрольной суммы). Если идентификатор, версия или контрольная сумма не проверяются, таблица просто пропускается. Поле длины используется для поиска следующей таблицы в цепочке. Когда микропрограмма видит таблицу нулевой длины, она знает, что достигла конца данных и больше нет таблиц для обработки.
Я считаю этот формат гибким (я могу добавлять данные любого типа в тело таблицы) и надежным (сохраняйте постоянный формат заголовка, и таблицы данных будут совместимы как в прямом, так и в обратном направлении).
Есть несколько предостережений, но они не слишком обременительны.Во-первых, вам необходимо убедиться, что ваша прошивка может справиться с ситуацией, когда важные данные либо отсутствуют в таблице, либо используют неподдерживаемую версию формата. Вам также необходимо будет инициализировать первый байт области хранения EEPROM нулевым значением (чтобы при первой загрузке вы не начали загружаться мусором, думая, что это данные). Поскольку каждая таблица знает свою длину, ее можно расширять или сжимать; однако вам необходимо переместить остальную часть области хранения таблиц, чтобы убедиться в отсутствии «дыр» (если вся цепочка таблиц не помещается в памяти вашего устройства, этот процесс может раздражать). Лично я не считаю, что все это является большой проблемой, и это стоит того, чтобы сэкономить на использовании некоторых других методов хранения данных.
Найджел Джонс рассмотрел некоторые основы в вашем справочнике. Есть много альтернатив.
Один из вариантов, если у вас много места, — хранить пары ключ-значение вместо структур. Затем вы можете обновить одно значение (добавив его), не стирая все. Это наиболее полезно для устройств с ограниченным числом циклов стирания. Ваша подпрограмма чтения должна будет сканировать с самого начала, обновляя значения каждый раз, когда встречается ключ. Конечно, ваша процедура обновления должна иметь «сборщик мусора», который срабатывает, когда память заполнена.
Для обработки ошибок устройства и отключений питания во время обновлений мы обычно храним несколько копий данных. Простейший подход состоит в том, чтобы пинг-понг между половинками устройства, используя порядковый номер, чтобы определить, какая из них новее. CRC для каждого раздела используется для его проверки. Это также решает проблему неинициализированных данных.
Для версии "ключ-значение" вам нужно будет добавлять новый CRC после каждой записи.