1

私は現在、マイクロコントローラ (TI MSP430) 用に C でステート マシンを作成中です。現在、コードの記述と設計の実装に問題はありませんが、実際のハードウェアを使用せずにステート マシン ロジックを証明する方法を考えています (もちろん、まだ使用できません)。

デバッグ機能を使用して、割り込みをシミュレートできます (これはまだ試していませんが、大丈夫だと仮定しているだけです。結局のところ文書化されています)。また、TEST データを保持するための特定のメモリ領域を定義して予約しました。 、デバッグ マクロを使用して、Python スクリプトでアプリケーションの外部で実行時にアクセスできます。つまり、いくつかのテスト基盤が整っています。ただし、私の質問の焦点は次のとおりです。

「たとえば、入力ピンが高または低の場合など、ハードウェア入力を必要とする決定に対して、特定のステート マシン フローを強制するにはどうすればよいですか」。たとえば、「ピンが高い場合はこのパスをたどり、そうでない場合はこのパスをたどる」などです。

繰り返しになりますが、デバッグ マクロを使用すると、アプリケーションの外部のレジスタに書き込むことができます (たとえば、LED を点灯させるため)。上記の方法でのフローは、負担が大きいことを証明しています。

フローをテストしたい場合は、最終的に使用される入力ピンの代わりに出力ピンを使用してこの値をチェックできる #ifdefs を使用することを考えていました。しかし、これは間違いなく私のコードベースにテストのみのコードを追加することになり、これは間違ったアプローチのように感じます。このレベルのテストを達成するための良い方法について誰かアドバイスはありますか? おそらくシミュレーターを使用するだけでよいことは承知していますが、可能な限り実際のハードウェアを使用したいと考えています (この段階では評価ボードですが)。

4

3 に答える 3

1

抽象化が必要なようです。

「アプリケーション」コード (ステート マシン) で、GPIO レジスタ読み取りなどを使用して入力読み取りをハードコーディングする代わりに、それらの読み取りを、チェックを実行して値を返す関数にカプセル化します。関数内に、#ifdef代わりに TEST メモリ領域から読み取る :ed コードを配置して、存在しない GPIO ピンからの応答をシミュレートすることができます。

高いパフォーマンスを目指していても、これは実際に可能であるはずです。オーバーヘッドはそれほど大きくなく、それに取り組めばinline機能を実行できるはずです。

于 2012-09-14T10:55:49.880 に答える
0

テストベンチを構築します。まず最初に、たとえば入力レジスタなどを読み取るときに、ある種の関数呼び出しを使用することをお勧めします（これは、他のアドレスのものよりも揮発性です）。基本的に、すべてに少なくとも1つの抽象化レイヤーがあります。これで、各抽象化のテスト関数を使用して、メインアプリケーションを簡単に持ち上げてどこにでも配置できます。実際のハードウェアがなくても、そのコードを完全にテストできます。また、実際のハードウェアで、入力を変更または偽造する方法として、抽象化（ラッパー関数、呼び出したいものは何でも）を使用できます。

switch(state)
{
   case X:
      r=read_gpio_port();
      if(r&0x10) next_state = Y;
      break;
}

テストベンチ（またはハードウェアでも）：

unsigned int test_count;
unsigned read_gpio_port ( void )
{
   test_count++;
   return(test_count);
}

最終的に、asmまたはCでread_gpio_portを実装してgpioポートにアクセスし、テストコードではなくメインアプリケーションにリンクします。

はい、インラインにしない限り関数呼び出しが発生しますが、その見返りとして、デバッグとテストの能力が大幅に向上します。

于 2012-09-14T21:12:13.117 に答える
0

まだすべてのハードウェアを持っていなくても、ほとんどすべてをシミュレートできます。

Cでそれを行うための可能な方法...

割り込みハンドラ=イベントを待機しているスレッド。

入力デバイス=上記のイベントを発生させるスレッド。これらはPCキーボードに「接続」できるため、手動で「割り込み」を開始します。または、自動化された方法で必要なことを実行するための独自のステートマシンを持つことができます（それらもスクリプト化できます。固定された動作にハードワイヤードする必要はありません！）。

出力デバイス=同様にスレッド。PCディスプレイに「接続」できるため、「LED」の状態を確認できます。出力をファイルに記録することもできます。

I / Oピン/ポートは、専用のグローバル変数にすることができます。読み取り/書き込み時にI/Oデバイススレッドをウェイクアップする必要がある場合は、それも可能です。それらへのアクセスを適切な同期および通信コードにラップするか、これらのポート変数へのアクセスが信号/ページフォールトをトリガーし、ハンドラーが必要なすべての同期および通信を行うように、基になるメモリをマップします。

そして、主要な部分は、まあ、にありmain()ます。:)

これにより、実際に非常に近い環境が作成されます。競合状態を取得することもできます！

それについてさらにハードコードしたい場合、そして時間があれば、MSP430全体をシミュレートすることもできます。命令セットは非常にコンパクトでシンプルです。現在、いくつかのシミュレーターが存在するため、活用するための参照コードがいくつかあります。

コードを適切にテストする場合は、目的に応じて十分な柔軟性を持たせる必要があります。これには、グローバル変数にアクセスする代わりに、関数に＃ifdefs、マクロ、明示的なパラメーター、データと関数へのポインターを追加することが含まれる場合があります。これらは、テスト中にオーバーライドでき、あらゆる種類のテストフックです。

また、コードをハードウェア固有の部分、非常にハードウェア固有の部分、およびプレーンなビジネスロジック部分に分割することも検討する必要があります。これらは、別々のライブラリにコンパイルできます。そうすれば、実際のハードウェアライブラリをハードウェアをシミュレートするテストライブラリに置き換えることができます。

とにかく、ハードウェアデバイスを抽象化し、テストステートマシンを使用して本番コードとそのステートマシンをテストする必要があります。

于 2012-09-14T11:24:41.130 に答える