高度に埋め込まれた（制限されたコードとRAMサイズ）プロジェクトは、コード編成に固有の課題をもたらします。
組織のないプロジェクトをたくさん見ました。（ほとんどの場合、私の経験では、コードの非機能的な側面には関心がないハードウェアエンジニアによるものです。）
ただし、それに応じてコードを整理しようとしています。
モジュールごとに、目的をこれら3つのタイプのいずれかに保つようにしています。
組み込みプロジェクトのサイズが限られており、パフォーマンスが重視されているため、この組織を維持することがよくあります。
ある文脈では、私の現在のプロジェクトは、8kフラッシュと256バイトRAMを備えたMSP430上の限定されたDSPアプリケーションです。
私は、MSP430 を含むさまざまなターゲット マイクロで複数の組み込み製品 (30 以上および数え切れないほど) を作成および保守してきました。私が最も成功した「経験則」は次のとおりです。
私は、同様の制限のある 8 ビット PIC プロセッサで作業しました。
あなたが持っていない制限の 1 つは、コメントの数や、メソッド、変数などに名前を付けるために選択したものです.利用してください. 速度とサイズの制約は組織化に勝ることもありますが、いつでも説明できます。
もう 1 つのヒントは、論理ソース ファイルを必要以上の断片に分割#includeし、コンパイル ユニットでそれらを ing してバインドすることです。これにより、多くの再利用可能なコード (ファイルごとに 1 つのルーチンでも) を保持しながら、必要な順序で組み合わせることができます。これは、コンパイル ユニット サイズの制限を満たしたい場合や、次のプロジェクトで必要な共通サブルーチンを選択する場合などに便利です。
例外的な状況 (注を参照) を除いて、コードの編成は最終製品に影響を与えません。(コードの内容は明らかに別問題)
そのことを念頭に置いて、他のプロジェクトと同じようにコードを整理する必要があります。
そうは言っても、以下はかなり典型的なものです。
これが以前に取り組んだ、または将来取り組む予定のプロセッサである場合は、通常、将来プロジェクト間で共有できる専用のハードウェア抽象化レイヤーを保持する必要があります。通常、このモジュールには、UART、タイマーなどを管理するためのルーチンなどのアイテムが含まれます。
通常、幹部がアプリケーションを引き継いで実行するまでのすべての構成と初期化を実行する、初期化とセットアップ用のプラットフォーム固有のコードのセットを維持することは合理的です。また、プラットフォーム固有の hal ルーチンも含まれます。
エグゼクティブ/アプリケーションは、おそらく別のモジュールとして維持されます。ハードウェア固有のコードはすべて hal に隠されている必要があります (前述のとおり)。
このようにコードを分割することにより、ハードウェア固有のコードをハードウェアを模倣するルーチンに置き換えるだけで、アプリケーションを完全に異なるプラットフォームでシミュレーションとしてコンパイルおよび実行するオプションも利用できます。これは、単体テストとデバッグ、および発生する可能性のあるアルゴリズムの問題に適しています。
異常なコンパイラ制限によって課せられる可能性がある例外的な状況。例えば。すべての割り込みサービス ルーチンが 1 つのオブジェクト ファイル内でコンパイルされることを期待するコンパイラをいくつか見つけました。
あたかも無制限の RAM と ROM があるかのように整理しようとしましたが、通常はうまくいきます。他の場所で述べたように、絶対に必要になるまで最適化を試みないでください。
より多くのリソースを備えたピン互換のプロセッサを入手できる場合は、適切な構造とレイアウトに集中してそれを機能させ、後でコードをよりよく理解してからサイズを最適化することをお勧めします。
私は Tmote Sky のようないくつかのセンサーを使用してきましたが、私も貧弱な組織を見てきました。とにかく、あまりにも多くのモジュールをロードしたり、プログラムの一部をロードしすぎたりすると、(imho) リソースが殺されるため、多少の混乱が必要になると思います。
明らかに、これは caos を開始するという意味ではありませんが、たとえば、tinyOSのソース コードとアプリケーションの構成を調べてみてください。これは、私が言おうとしていることのアイデアです。
少し面倒ではありますが、組み込み C ライブラリでやや一般的な編成手法の 1 つは、すべての関数と変数を個別の C ソース ファイルに分割し、その結果の O ファイルのコレクションをライブラリ ファイルに集約することです。
これを行う動機は、ほとんどの通常のリンカーではリンケージの単位がオブジェクトであり、すべてのオブジェクトについて、オブジェクト全体を取得するか、オブジェクトをまったく取得しないかのどちらかであるということです。C ファイルとオブジェクト ファイルの間には 1 対 1 の関係があるため、各シンボルを独自の C ファイルに配置すると、それぞれに独自のオブジェクトが与えられます。これにより、リンカーは、実際に使用される関数と変数のサブセットのみを取り込むことができます。
この種のゲームは、ヘッダーが単一のファイルとして喜んで残される場合、まったく役に立ちません。