Лично я предпочитаю формат «tagged table».
В этом формате ваши данные разделены на ряд «таблиц». Каждая таблица имеет заголовок, который следует за предсказуемым форматом и телом, который может измениться по мере необходимости.
Вот пример того, что одна из таблиц будет выглядеть следующим образом:
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 до нуля (так что при первой загрузке вы не начнете загружать мусор, думая, что это данные). Поскольку каждая таблица знает свою длину, можно расширить или сжать таблицу; однако вы должны перемещать остальную область хранения таблиц вокруг, чтобы убедиться, что нет «отверстий» (если вся цепочка таблиц не может вписаться в память вашего устройства, тогда этот процесс может раздражать). Лично я не считаю, что любой из них может быть таким большим, и это стоит того, что я могу сэкономить, используя некоторые другие методы хранения данных.
Это звучит как отличное решение для обработки изменений размера таблицы между версиями прошивки. Есть ли у вас какие-либо советы относительно того, чтобы сделать его толерантным к записи с потерей мощности, помимо дублирования данных? –
Запишите всю таблицу с недопустимой контрольной суммой, затем (в отдельной транзакции) вернитесь и напишите правильную контрольную сумму. Если есть проблема со средней записью, ваша контрольная сумма будет неправильной при чтении данных. – bta
Это элегантное решение, которое тривиально реализовать: спасибо за продолжение. –