embedded - EEPROM 内のデータの整理

Question

AT Mega 1281 と通信するボード上に、128 バイトのページとして編成された 64KB の EEPROM があります。ボードには SD カード スロットもあり、一部の構成ファイルを EEPROM (内部として機能する) にコピーできます。メモリー）。ボードの性質上、必要なファイルは 2 種類だけです。1 つはサーキット データと呼ばれ、もう 1 つはロケーション データです。どちらもバイナリ ファイルです。

今までは、EEPROM を 32K の 2 つの半分に分割し、回路データを上半分に、位置データを下半分に書き込んでいました。どちらのファイルにも 25 バイトのヘッダーがあります。ファイルの最後のページのヘッダーをそれぞれ半分にコピーします。つまり、アドレス 0x7F80 で始まるページには回路データ ファイルのヘッダーがあり、0xFF80 で始まるアドレスには他のヘッダーがあります。データは常に固定幅になるため、ランダムアクセスが非常に簡単になります。

私の質問は、EEPROM でデータを整理するためのより良い、より簡単な方法はありますか? 現時点では、実際には必要ないため、データの長ささえ保存していません。しかし、ヘッダーにそれを含めると、安全性の別のステップが追加される可能性があると考えています。

Answer 1

より良い？場合によります。もっと簡単？本当にありません。あなたの「いつも」がどれだけ強いかによります。ファイルが常に固定長であるとどの程度信じていますか? あなたがこの質問をしているという事実は、おそらくいくつかの疑問を意味します. KISSの原則を心に留めておいてください。マイクロコントローラの開発は、いまだに不要な機能がソリューションの安定性を直接脅かす分野です。EEPROM アクセスをより一般的にしたい場合は、ヘッダーにデータ長があると便利です。しかし、繰り返しになりますが、2 つのファイルを一般化するのはやり過ぎです。

2番目の考え:実際には必要のないファイル長を導入するのではなく、ファイルヘッダーをそれぞれのメモリチャンクの反対側に保存する理由を知りたい. 「ヘッダー」は、ファイル自体の前に読み取る必要があるものです。読み取りアドレスの 1 回の転送を EEPROM に保存できます。

Answer 2

どんな組み込みプロジェクトでも、最もシンプルなソリューションが最適だと思います。ストレージを整理する方法はシンプルで、すべての要件を満たしているようです。

このソリューションを「改善」または「最適化」しようとすると、コードがより複雑になり、バグが発生する可能性が高くなります。そのため、すべてのエンジニアリング ソリューションをできるだけシンプルに保ちます。新しい要件が発生した場合、それらに対する新しいシンプルなソリューションをいつでも見つけることができます。時期尚早の最適化を行わないでください。