個人的には、「タグ付きテーブル」形式が好きです。
この形式では、データは一連の「テーブル」に分割されます。各テーブルには、予測可能な形式に従うヘッダーと、必要に応じて変更できる本文があります。
表の1つがどのようになるかの例を次に示します。
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
あまりデータを保存していなかったので、ヘッダーの各フィールドに1バイトを使用しました。変更しない限り、必要なサイズを使用できます。データテーブルは次々にEEPROMに書き込まれます。
ファームウェアがEEPROMからデータを読み取る必要がある場合、ファームウェアは最初のテーブルから読み取りを開始します。ファームウェアがテーブルIDを認識し、リストされたテーブルバージョンをサポートしている場合、ファームウェアはテーブルの本体からデータをロードします(もちろん、チェックサムを検証した後)。ID、バージョン、またはチェックサムがチェックアウトされない場合、テーブルは単にスキップされます。長さフィールドは、チェーン内の次のテーブルを見つけるために使用されます。ファームウェアが長さがゼロのテーブルを検出すると、ファームウェアはデータの最後に到達し、処理するテーブルがこれ以上ないことを認識します。
この形式は柔軟性があり(テーブルの本体に任意のタイプのデータを追加できます)、堅牢です(ヘッダー形式を一定に保つと、データテーブルは下位互換性と下位互換性の両方になります)。
それほど負担はありませんが、いくつかの注意点があります。まず、重要なデータがテーブルにないか、サポートされていない形式のバージョンを使用している場合に、ファームウェアが処理できることを確認する必要があります。また、EEPROMストレージ領域の最初のバイトをゼロに初期化する必要があります(最初の起動時に、データだと思ってガベージのロードを開始しないようにするため)。各テーブルはその長さを知っているので、テーブルを拡大または縮小することができます。ただし、「穴」がないことを確認するために、テーブルの残りのストレージ領域を移動する必要があります(テーブルのチェーン全体がデバイスのメモリに収まらない場合、このプロセスは煩わしい場合があります)。個人的には、これらのどれもそれほど大きな問題ではないと思いますが、