2017-04-22 34 views
0

私はの埋め込みシステムをCで開発しています。#define TESTING_ENABLEDによって有効になっているターゲットプラットフォームを使わずにローカルでテストできる環境をセットアップしました。埋め込みCテスト開発管理

これはまもなく拡張され、プロジェクトのすべての側面が含まれるため、各テスト定義の管理は、プラットフォームの切り替え時に面倒になる可能性があります。

私は#define directiveをメイクファイルで設定することができますか、別のコンパイラの使用を検出できますか?

答えて

1

この目的のために#define#ifを使用するのは、通常、いくつかの理由から非常に悪い考えです。 1.読み取り不可能です。 2.ポータブルではありません。 3.維持不能。

ヘッダーファイルには、#define#ifを持つことができます。プリプロセッサがソースファイルに移行するとすぐに、メンテナンスと移植性の点でプロジェクトの失敗に対する明確なパスになります。

だから、すべてのコストで避け、このようなコード:私は、コードを見てきた極端な例として

void foo() 
{ 
    ... 

#if TARGET_REAL_CPU 
    ... 
#endif 

    ... 
} 

bool some_func(
    int index, 
#if SOME_DEFINE 
    bool flag, 
#else 
    struct exception* ex, 
#endif 
    void* buffer, 
    size_t size, 
) 
{ 
    ... 
} 

上記のコードは、任意のプロジェクトをリードしますトータルクラスターファック!

ここで、どのように行われることになっていますか。

抽象化はあなたの友人です!ハードウェア、プラットフォーム、コンパイラ/ツールチェーンの3つの主なものの一般的な分離。コンパイルとプラットフォームを混乱させる人もいます。

私はプロジェクトのダミーの例を作成しました。ディレクトリ構造は次のようになります。それはあなたの分離がどのように行われるか明確なアイデアを与える必要があります。できるだけ多くのイン依存コード

firmware/ 
├── bin 
│   ├── arm 
│   ├── windows_x64 
│   └── windows_x86 
├── build 
│   ├── gcc 
│   │   └── arm 
│   ├── keil5 
│   │   └── arm 
│   └── vs2017 
│    └── windows 
├── include 
│   └── firmware 
│    └── frm.h 
├── src 
│   ├── arm 
│   │   ├── frm_init_impl.c 
│   │   └── frm_platform.h 
│   ├── frm_idle.c 
│   ├── frm_init.c 
│   ├── frm_state.c 
│   └── windows 
│    ├── frm_init_impl.c 
│    └── frm_platform.h 
└── test 
    └── firmware_test 
     ├── build 
     │   └── vs2017 
     │    └── windows 
     └── src 

1.書き込みプラットフォームを!ほとんどの場合、開発とデバッグが容易になります。例えば、Visual Studioのような便利な環境で&のデバッグをできるだけ簡単に書くと、viやgdb、さらにはKeilを使用する方がはるかに簡単で簡単です。私の個人的な意見は高価なごみです!すぐに、それはこの場合_platform.hファイル

FrmStatus frm_init() 
{ 
    // Platform in-depended code 
    ... 

    status = frm_init_impl(...); 
    if(FAILED(status)) 
    { 
     ... 
    }  

    // Platform in-depended code 
    ... 
} 

_impl.cファイルとすべてのプラットフォーム固有の定義に移動させなければならないプラットフォームに依存する機能を持っているよう

2.あなたがfrm_init_implの異なる実装を持っていますさまざまなフォルダとファイルの機能をWindowsのシミュレーションコードと実際のチップ固有のものとしましょう。しかし、あなたのプラットフォームに依存するfrm_init関数は、何が関係なく常に同じままです!

3。buildディレクトリの異なるフォルダを使用してコンパイラとツールチェーンを区切ります。これらのプロジェクトファイルには、srcの対応するサブフォルダからの特定の.c.hファイルが含まれています。

この手法は、WindowsのシミュレーションやKeilのエミュレーションを使用してファームウェアのテストスイートを簡単に開発するのに役立ちます。そして、実際のハードウェア用のテストプロジェクトを作成することができます。

私が何かを忘れてしまった場合は、そのプロセスで編集し、コミュニティの開発者が助けてくれるでしょう。

関連する問題