その他①　マイコンのROM容量を考慮した設計

～ 容量不足は突然やってくる！効果的な最適化と事前対策 ～

開発の最終段階で「ROM容量が足りない！」と慌てた経験はありませんか？
低コスト化のために選定したROM容量が小さいマイコンは、予期せぬ機能追加やバグ修正で、突然プロジェクトを停止させる原因になりがちです。
ここでは、マイコンのROM容量を考慮した設計上の注意点と、効果的なROM容量最適化テクニックを、RL78シリーズなどの実例を交えてお伝えします。

１．なぜROM容量は「ぎりぎり」になるのか？

ROM容量は、組み込みシステムにおけるプログラムコードや定数データが保存される場所です。
当初の設計で十分な容量があったはずなのに、なぜギリギリになってしまうのでしょうか。

１．機能追加:顧客要求や市場の変化に対応した機能の追加。
２．バグ修正: バグを修正するためにデバッグ用のコードやデータが増加。
３．ミドルウェアの導入: RTOS、通信プロトコルスタック、ファイルシステムなどの利用。
４．開発ツールの違い: コンパイラのバージョンアップや最適化レベルの変更でコードサイズ変動。
５．データ量の増加: テキスト文字列、画像、サウンド、ファームウェア更新データなどの増加。
６．予期せぬライブラリの肥大化: 使用している標準ライブラリやメーカー提供のドライバが予想以上に大きい。

これらの積み重ねが、最終的にROM容量を圧迫します。

２．ハードウェア選定・設計段階での対策

ROM容量の設計は、プロジェクトの初期段階から意識することが非常に重要です。

１．将来性を見越したマイコン選定

ROM容量の余裕度:
現在の想定使用量より、最低でも20〜30%の余裕を持たせたマイコンを選定します。
特に長期プロジェクトや機能追加が予想される場合は、50%程度の余裕があると安心です。

上位互換品／ピンコンパチ品:
予算と容量のバランスを見て、物理的な互換性がある上位容量品も候補に入れておきます。
容量が不足した際に、基板パターン変更なしで交換できるとプロジェクト遅延を最小限に抑えられます。

外部メモリの検討:
データログや画像データなど、ROMに置かなくても良いデータは、SPI-FlashやSDカードなどの外部メモリを活用できるマイコンを選ぶか、基板設計で対応できるようにします。

２．データセグメントの分割

プログラムコードと特に大きいデータ（画像、フォントなど）のROM上の配置を検討します。
RL78/G14などの機種は「コードフラッシュ」と「データフラッシュ」という異なる性質のフラッシュを持っています。
書き換え頻度や利用用途に応じて適切に配置します。

３．ソフトウェア実装段階での対策

初期選定で余裕があっても、ソフトウェア的な努力でさらに容量を節約できます。

１．コンパイラの最適化オプション活用

コードサイズ最適化:
コンパイラには「-Os」（サイズ最適化）などのオプションがあります。これらを積極的に活用しましょう。ただし、最適化レベルによってはデバッグが難しくなることや、ごく稀に動作がおかしくなる場合もあるため、最終的には十分な動作検証が必要です。

未使用コード／データ除去:
リンカ最適化で、参照されていない関数や変数、未使用ライブラリのコードを最終バイナリから削除する設定を行います。

２．ライブラリの見直しと軽量化

標準ライブラリの代替:
printf などの高機能な標準ライブラリは、内部的に多くのコードを含みます。デバッグ用途であれば、必要最低限の機能を持つ独自の簡易関数（例：puts だけで済ませる）に置き換えることで、大幅に容量を削減できることがあります。

不必要な機能の無効化:
使用しないミドルウェアやドライバの機能は、設定ファイルやマクロでビルド対象から外しましょう。

整数型演算の活用:
浮動小数点演算は、浮動小数点ライブラリ（fpu.libなど）がリンクされ、容量が大きくなりがちです。可能な限り整数演算で代替することで、コードサイズを削減できます。

３．データ形式と圧縮

画像／フォントデータの最適化:
不要な色数や解像度の画像を削減したり、モノクロや2値画像にしたりします。特定のフォント文字のみを抽出して格納するなど、必要なデータだけを最小限の形式で持つように工夫します。

データの圧縮:
ハフマン符号化やLZSSなどのシンプルな圧縮アルゴリズムを導入し、ROM容量を節約できる場合があります。ただし、圧縮／解凍のためのコードとCPU負荷が増加するトレードオフがあります。

４．設計の見直し

汎用コードの再利用:
同じような処理を別々に記述せず、汎用的な関数としてまとめることでコードの重複を減らし、容量を削減します。

４．ROM容量を「見える化」する

MAPファイルの活用:
コンパイラやリンカが出力するMAPファイルには、どの関数や変数がどれだけのROM容量を使っているかの詳細な情報が記述されています。定期的にこれを確認し、肥大化している部分を特定する習慣をつけましょう。

容量監視ツールの導入:
IDE（CS+やe2 studioなど）には、ビルド後にROM使用率を表示する機能があります。これを常に意識し、目標の容量率（例：80%以下）を超えそうになったら警告を出すように設定することも有効です。

５．まとめ

ROM容量の最適化は、低コスト化と機能性のバランスを取るうえで非常に重要です。

１．**設計初期の「余裕を持った選定」**が重要。
２．コンパイラの最適化、ライブラリの見直し、データ形式の工夫でソフトウェア的に容量を削減。
３．MAPファイルの確認で「見える化」を習慣化する。

ROM容量の制限は、あなたの設計スキルを試す絶好の機会でもあります。
「容量不足は技術で乗り越える！」という意識で、堅牢なシステムを開発しましょう。