6

外部ハードウェアに依存する組み込み C プロジェクトに取り組んでいます。ハードウェアを使用せずにシステムをシミュレートできるように、これらの部分にアクセスするコードをスタブアウトしたいと考えています。今までいくつかのマクロを使用してきましたが、これにより本番コードを少し変更せざるを得なくなりました。これは避けたいと思います。

例：

stub.h
#ifdef _STUB_HW
#define STUB_HW(name) Stub_##name
#else /*_STUB_HW*/
#define STUB_HW(name) name
#endif /*_STUB_HW*/

my_hw.c
WORD STUB_HW(clear_RX_TX)()
{ /* clear my rx/tx buffer on target HW */ }

test_my_hw.c
#ifdef _STUB_HW
WORD clear_RX_TX()
{ /* simulate clear rx/tx buffer on target HW */ }

このコードを使用すると、プリプロセッサ タグを使用してスタブのオン/オフを切り替えることができます_STUB_HW

。prod コードを変更せずに、多くの ifdef を回避することなく、これを実現する方法はありますか。また、回避できる場合は、同じファイルに製品コードとテスト コードを混在させません。テスト コードがどのように見えるかは、製品コードから可能な限り除外できる限り気にしません。

編集：

ファイル全体を置き換えずに関数を選択/名前変更できるといいですね。で始まるすべての関数を取り、新しい名前を付けてから、可能であればにnRF_##挿入test_nRF_##するようにnRF_##

4

3 に答える 3

1

上記に同意します。これに対する標準的な解決策は、ハードウェアの「ドライバー」である不透明な抽象化された関数呼び出しのセットを定義し、それをメインプログラムで呼び出すことです。次に、2つの異なるドライバー実装を提供します。1つはhw用、もう1つはsw用です。swバリアントは、適切な方法でハードウェアのIO効果をシミュレートします。

目標がより低いレベルにある場合、つまり、関数全体ではなく各ハードウェアアクセスをシミュレートするコードを作成する場合は、少し注意が必要です。ただし、ここでは、さまざまな「write_to_memory」関数と「read_from_memory」関数（または、ターゲットの速度が重要な場合はマクロ）を定義できます。

どちらの場合も、関数の名前を変更する必要はありません。2つの異なるバッチファイル、makeファイル、またはIDEビルドターゲット（使用しているツールに応じて）を用意するだけです。

最後に、多くの場合、より優れた技術的解決策は、 Qemu、Simics、SystemC、CoWare、VaSTなどの本格的なターゲットシステムシミュレーターを使用することです。これにより、常に同じコードを実行でき、代わりに、ソフトウェアの観点から実際のハードウェアのように機能するハードウェアのモデルを構築できます。それははるかに大きな先行投資を必要としますが、多くのプロジェクトにとってそれは努力する価値があります。基本的に、ターゲットとホストで異なるビルドを使用するという厄介な問題を取り除き、常にクロスコンパイラーをデプロイメントビルドオプションとともに使用できるようにします。多くの組み込みコンパイラスイートには、そのような基本的なシミュレーション機能が組み込まれていることに注意してください。

于 2009-01-09T08:12:31.067 に答える
1

Gerhard が言ったように、共通のヘッダー ファイル "driver.h" と、実際の関数とスタブ化された関数を含む別のハードウェア レイヤー実装ファイルを使用します。

Eclipse には 2 つのターゲットがあり、使用しない driver.c ファイルを「ビルドから除外」し、適切なファイルがビルドに含まれていることを確認します。その後、Eclipse はビルド時に makefile を生成します。

指摘すべきもう 1 つの問題は、オーバーフローの観点からコードが同じように動作するように、固定サイズの整数を定義していることを確認することです。（ただし、コードサンプルから、あなたがそれを行っていることがわかります。）

于 2009-01-06T12:40:58.203 に答える