賢い EEPROM デザイン

2020年1月15日

組み込み製品では、電源を切った後も記憶させたい情報の保存先として、大抵 EEPROM が使われます。ですから、製品を開発しようとするとき、ソフトウェア開発者はこの EEPROM 内部のデータ構造を設計する必要があるわけです。

組み込み屋の悲しい性か、こんなとき私はつい、極力サイズに無駄が出ないよう、敷き詰めるようにデータを並べてしまいます。ちょうど C の構造体をそのまま EEPROM に転写するように。

しかし、バイト当たりの単価がタダ同然の今日、このような古典的なデザインに執着する必要が本当にあるのでしょうか。今回は、あえて冗長なデータ構造を採ることで、その後の開発を有利に進めることができるという提案です。

初めが肝心

見過ごされがちですが、EEPROM の設計はとにかく初めが肝心です。ここで決めたことが、後の10年を左右するといっても過言ではありません。少なくとも次のことを観点とした検討は、初めのうちに済ませておくべきです。

  • EEPROM 容量は、必要な情報量に対して十分余裕があるか
  • 読み込み時間・書き込み時間はユーザーにとって重要か
  • データを作成・編集したいのは誰か。たとえばソフト屋以外の人が扱いたい場面はないか
  • 開発を進める中で、保存すべきデータの定義が揺らぐことはないか

これらをよくよく考えると、必ずしも生のバイナリを EEPROM に配置する方法がベストとは限らないことがわかってきます。ただし、ここからの提案は、「便利さはデータ容量・アクセス時間とのトレードオフである」という点を念頭に置いてお読みください。

Windows ファイルとの親和性を持たせよう

サイズのことや実装のシンプルさのことを考えると、EEPROM 内部のデータはどうしてもバイナリ形式になりがちです。しかし、製品の外に吸い出したデータの意味が直ちにはわからないということが、どれだけ開発の足かせになるか。私は実際に大変苦労しました。

ここはたとえ冗長でも、テキスト形式にしておくことをお勧めします。もっと言えば、Windows のファイル形式そのもの、たとえば INI や CSV などにしておくとさらに便利になります(さすがに XML は嵩張りすぎるのでお勧めしません)。

こうしておけば、吸い出したデータの意味を理解するのも楽ですし、第三者にも作成・編集が可能になります。もちろん、ファームウェア側にパーサを実装する必要がありますが、その価値は十分にあります。

前方互換と後方互換の両方を持たせよう

ややこしい用語なので整理すると、前方互換は「古い製品が新しい形式のデータを読めること」、後方互換は「新しい製品が古い形式のデータを読めること」です。

特に前方互換は重要です。開発中は、バグの調査のために ROM を古いバージョンの製品に戻して使いたいという局面がよくあり、前方互換がないとエラーのせいでいちいち作業が止まることになるからです。

互換性を持たせるということも、テキスト形式だからこそ成せる業です。互換性といっても、実用上は次の2つのロジックを実装すれば十分でしょう。

  • 不明なデータが存在しても、それを無視する
  • 期待するデータが存在しない、あるいは異常値の場合、代わりにデフォルト値を使う

デフォルト値を使う場合、ユーザーに向けて何らかの警告を発するようにすべきですが、それでも「それなりに動く」ということは、開発の大きな助けになってくれるはずです。