C の典型的な組み込みソフトウェアのファイル構造に関する適切な提案を見つけることができません。SO に関するそのような質問と回答は多数ありますが、私が提示する懸念をカバーするものや、C の組み込みシステムに適合していると思われるものはありません。
特効薬がないことは理解しています。それが提案を絞り込むのに役立つ場合、私の典型的なアプリケーションは、8 ～ 32 kB のフラッシュと数 kB の RAM を備えたターゲットに適合する必要があります。4 ～ 20 MHz 範囲のクロック。
1.レイヤー
ソースコードがレイヤーに編成されており、各レイヤーには独自のディレクトリがあります。
- 応用
- トランスポート層
- ハードウェア抽象化レイヤー
問題は、モジュールがこれらすべての層にファイルを持っていることが多いため、ディレクトリで層を分離すると、1 つのモジュールのファイルがあちこちに散らばることになります。カプセル化が悪い。
2. ディレクトリ内のモジュール、$ROOT/includes/ 内の h ファイル
モジュールごとに 1 つのディレクトリ。良いことは、実際のカプセル化です。モジュールの API を公開する方法がよくわかりません。オープンソース PC アプリケーション SW のようです:
- モジュールディレクトリにすべてのソースコードがあります（モジュール内でのみ使用されることを意図したすべてのCファイルとすべてのヘッダーファイル）
- API ヘッダー ファイルをモジュール ディレクトリの外にある に公開します
$PROJ_ROOT/includes。
そうすれば-I$PROJ_ROOT/includes、コンパイラ コマンドに (または同等のものを) 含めることができ、#includeステートメントに検索パスを含めることができなくなります。
問題は、API がモジュール ディレクトリの外にあるため、カプセル化が壊れていることです。たとえば、モジュールを VCS でスタンドアロンとして維持することは困難です。
3. ディレクトリに API を持つモジュール
上記と同じですが、モジュール ディレクトリに API ヘッダー ファイルがあります。適切にカプセル化され、モジュールのバージョン管理が容易になりますが、API ヘッダー ファイルは、プライベートであることを意図した他のモジュール ヘッダー ファイルと同じレベルにあります。このような「プライベート」ヘッダー ファイルをモジュールの外部にインクルードする誘惑は、将来の開発者にとっては大きすぎるかもしれません。
4. ディレクトリに API を含むモジュール、サブディレクトリにプライベート構造
API ヘッダー ファイルのみをモジュール ディレクトリに直接配置し、他のすべてのファイルを 1 つまたは複数のサブディレクトリに配置します。これはうまくいくかもしれませんが、構造がますます複雑になっているように感じます。これはあまり好きではありません。
私は2つか4つに行くべきだと感じていますが、洞察を大いに感謝します. 私が説明する関連する欠点に対処するにはどうすればよいですか? 他の選択肢は？
この種の規模の成功したオープンソース SW へのリンクもよいでしょう。文学的なアドバイスも大歓迎です。