Безопасное хранение и доступ к EEPROM - PullRequest
10 голосов
/ 24 августа 2010

Я недавно установил необходимость хранить редко обновляемые переменные конфигурации в EEPROM микроконтроллера.Добавление состояния в программу немедленно заставляет беспокоиться о

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

Обширный поиск в Google нашел только одну статью, в которой рассматривается сохранение данных EEPROM действительными при обновлениях встроенного ПО .Кто-нибудь использовал подход, обсуждаемый в этой статье?Есть ли лучший альтернативный подход?

Ответы [ 2 ]

7 голосов
/ 24 августа 2010

Лично я предпочитаю формат с теговой таблицей.

В этом формате ваши данные разделяются на серию «таблиц». Каждая таблица имеет заголовок, который соответствует предсказуемому формату, и тело, которое может изменяться по мере необходимости.

Вот пример того, как будет выглядеть одна из таблиц:

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 нулем (чтобы при первой загрузке вы не начинали загрузку в мусоре, думая, что это данные). Поскольку каждая таблица знает свою длину, можно расширить или уменьшить таблицу; однако вам необходимо переместить остальную часть области хранения таблиц, чтобы не было «дыр» (если вся цепочка таблиц не помещается в памяти вашего устройства, тогда этот процесс может раздражать). Лично я не считаю, что что-то из этого является большой проблемой, и это стоит того, чтобы сэкономить на использовании других методов хранения данных.

3 голосов
/ 24 августа 2010

Найджел Джонс рассмотрел некоторые из основ в вашей ссылке.Существует множество альтернатив.

Один из вариантов, у вас достаточно места, - это хранение пар ключ-значение вместо структур.Затем вы можете обновить одно значение (добавив его), не стирая все.Это наиболее полезно в устройствах с ограниченным числом циклов стирания.Ваша процедура чтения должна будет сканироваться с самого начала, обновляя значения каждый раз, когда встречается ключ.Конечно, ваша подпрограмма обновления должна иметь «сборщик мусора», который включается при заполнении памяти.

Для обработки ошибок устройства и отключений питания в середине обновлений мы обычно храним несколько копийданные.Самый простой подход - это пинг-понг между половинками устройства, используя порядковый номер, чтобы определить, что новее.CRC в каждом разделе используется для его проверки.Это также решает проблему неинициализированных данных.

Для версии со значением ключа вам нужно будет добавлять новый CRC после каждой записи.

...