プロジェクトの PROM チップに組み込まれる Boot の開発に取り組んでいます。私は、ソフトウェアがおそらく使用する最終的なメモリ サイズを見積もることを任されましたが、これまで行ったことはありませんでした。
少し調べてみたところ、次のように考えています。
私の解決策は偽物である可能性が非常に高いです。誰かが助けてくれることを願っています。
原則として - あなたは正しい道を進んでいます:
いくつかの種類のメモリ フットプリントを区別する必要があります。
スタックは、主に再帰、ローカル変数、および関数パラメーターの影響を受けます。
動的メモリ (ヒープ) は明らかであり、おそらく関係のないものなので、ここでは無視します。
初期化された変数は、変数を 2 回カウントする必要があるため興味深いものです。1 回目は PROM 上のプログラム フットプリント (コードや定数と同様) 用で、もう 1 回は RAM フットプリント用です。
初期化されていない変数は明らかに RAM に向かっており、サイズをカウントするだけでほぼ十分です (アライメントとパディングも考慮する必要があります。
推定するのが最も難しいのはコードまたは PROM に入るものです。定数とローカル変数、およびコードをカウントする必要があります。コード自体は多かれ少なかれあなたが疑うものです (パディング、アラインメント、関数呼び出しのオーバーヘッド、割り込みベクトルの初期化を追加した後)など）しかし、インライン関数、ライブラリ関数（多くの一見些細な操作がそのような関数を含む）、キャストなど、多くのことが予想よりも大きくなる可能性があります.
質問に答える方法は、同様の機能を持つ既存のコードの経験または評価からです。ただし、コード サイズに影響を与える要因はいくつかあります。
「ブートの開発」は、ブート プロセスの要件や機能については何も教えてくれません。これは、コード サイズに最も大きな影響を与えます。ターゲットがどのように違いを生むかの例として、8 ビット ターゲットは通常、コード密度が高くなりますが、より大きなデータ型の算術演算用により多くのコードを生成します。コード密度が大幅に変わります。
これまでの経験や代表的なコード ベースがない場合は、いくつかの実験を行って、使用できるいくつかのメトリックを取得することをお勧めします。
空のアプリケーションをビルドします。C または C++ の場合は空の main() 関数だけです。これにより、ランタイム起動の基本的な固定オーバーヘッドが得られます。
ライブラリ コードを使用している場合、おそらくかなりの容量が必要になります。最終的なアプリケーションで使用するすべてのライブラリ インターフェースにダミー呼び出しを追加します。これにより、ライブラリ コードが占めるコードの量がわかります (ライブラリ コードがインライン化されていないと仮定します)。
その後は機能に依存します。必要な機能のサブセットを実装し、それが最終ビルドに占める割合を見積もることができます。
あなたの提案に関しては、定数初期化子はそうしますが、変数は ROM のスペースを占有しないことに注意してください。通常、ブートローダーは使用可能なすべての RAM を使用できます。これは、アプリケーションの起動によって、ブートローダーの環境と変数が破棄され、それ自体の新しいランタイム環境が再確立されるためです。
機能とターゲットの詳細を提供すると、コミュニティの経験を活用して、必要なリソースを見積もることができる場合があります。たとえば、ARM命令セットを使用するARM7でXMODEMプロトコルを使用してUART経由でロードするフラッシュプログラミングをサポートするブートローダーが4kバイトに収まること、またはロードのサポートを追加することを（経験から）伝えることができるかもしれませんSD カード経由ではさらに 6Kb が追加され、USB 仮想通信ポートではさらに 4Kb 追加される可能性があります。ただし、要件はおそらく固有であり、何らかの方法でリソースの負荷を自分で決定する必要があります。