サポートの概要

IAR EW 環境の統合は次のように提供されます。

プロジェクトのインポート機能とオプションの抽出機能は、ツールチェーン (EWARM、EW430、EWSTM8 など) に依存します。詳細については、以下のツールチェーンのセクションを参照してください。

IAR Embedded Workbench プロジェクトのテストを容易にするために、以下のコンポーネントが用意されています。

C-SPY シミュレーターで単体テストおよびアプリケーションテストを開始するためのテストコンフィギュレーション
- Run IAR EW Tests (Batch Template) バッチスクリプト (cspy.bat) を起動するEW 生成シミュレーターを使用。
- Run IAR EW Application with Mem Monitoring (Batch Template) バッチスクリプト (cspy.bat) を起動するEW 生成シミュレーターを使用。
テストコンフィギュレーションに関連付けられたテストフロー。統合されたテスト結果の読み込みが組込まれています。
- Build and run tests on IAR C-SPY Simulator
- Build and run tests on IAR C-SPY Simulator using EW-generated batch scripts (.cspy.bat)
- Build and run application on IAR C-SPY Simulator
- Build and run application on IAR C-SPY Simulator using EW-generated batch scripts (.cspy.bat)
以下のパブリッシュされたプロパティは、IAR 固有のテストコンフィギュレーション/テストフローで利用することができます。
- "Target architecture" (arch) 「Batch Template ではないテストコンフィギュレーション」で使用される。
- "C-SPY execution backend options" (bkend_opts) ターゲット上でテストバイナリを正しく実行するために必要とされる。「Batch Template ではないテストコンフィギュレーション」で使用される。
- "Original IAR EW project folder name" (prj_dir_name) プロジェクトファイルの直接の親フォルダーの名前。デフォルトはプロジェクト名。EW 生成のバッチスクリプトの場所を指定するために設定しなければならない。Batch Template テストコンフィギュレーションで使用される。
- "Original IAR EW project name" (prj_name) Eclipse プロジェクト名が元の名前と一致しない場合に備えて用意されているプロパティ。Batch Template テストコンフィギュレーションで使用される。
- "IAR EW project Build Configuration (leave empty for EW < 7.0)" (bld_cfg) 使用する EW プロジェクトビルド構成 (たとえば "Debug" または "Release")。IAR C-SPY シミュレーターで実行するアプリケーションのために使用する EW 生成のバッチスクリプトの場所を指定するために、最近のバージョンの EW では設定する必要がある (なぜなら、最近のバージョンの場合、EW 生成のバッチスクリプト名に EW プロジェクトビルド構成の名前が含まれるため)。古いバージョンの EW の場合は空白のままになる。Batch Template テストコンフィギュレーションで使用される。
- "Adjust CSpyBat command (enable only for IAR EW < 6.1)" (adj_cspy_cmd) 特別な調整ステップによって、EW 生成のバッチスクリプトを調整するかどうかを指定する。最近のバージョンの EW の場合、そのような調整は必要なく、値はデフォルトの false のままになる。Batch Template テストコンフィギュレーションで使用される。
- "Driver DLL" (drv_dll) CSpyBat が必要とするハードウェアデバッガードライバー DLL。デフォルトではこれは <アーキテクチャ>sim.dll (例えば EW430 用は 430sim.dll、EWRX 用は rxsim.dll など)であり、 EWARM 5.3 および 5.4 ではデフォルト値 (armsim.dll) で正しい。しかし、より新しいバージョンのEWARMでは armsim2.dll に変更しなければならない (EWARM 5.4 には両方の DLL がある)。「Batch Template ではないテストコンフィギュレーション」で使用される。
- "Flash loader specification file" (flash_loader) CSpyBat に渡すフラッシュローダー仕様ファイル。EWARM バージョンによって、これは .xml または .board/.flash ファイルである。ビルトインコンフィギュレーションは EW_DIR/arm/config/flashloader にある。すべての IAR 固有のテストコンフィギュレーション/テストフローで使用される。フラッシュローダーおよび「Batch Template ではないテストコンフィギュレーション」を使用する場合に設定する。この EWARM の問題のために、EWARM 5.3 だけについて Batch Template テストコンフィギュレーションを使用する場合に設定する。より新しい EWARM について設定してはいけない。これは重複フラッシュローダー仕様エラーを引き起こす。

各ツールチェーンのセクションで、さらにテストコンフィギュレーションについて説明しています。それらのテストコンフィギュレーションは手動で構成されます。EW 生成 C-SPY バッチスクリプトを利用できない場合や他の問題のあるケースのために、あくまでバックアップ的な解決方法として提供されたものです。可能な場合は必ず前述の Batch Template テストコンフィギュレーションを使用してください。

[Generate Unit Tests] や [Generate Stubs] などの標準的なテストコンフィギュレーションも IAR プロジェクトに対して使用できますし、コード品質を確保するために使用が推奨されます。

複数の IAR EW が共存する環境のサポートに対して、大幅な変更が C++test 9.1 から適用されました。C++test がプロジェクトを正しくビルドしてテストするには、どの IAR のバージョン/インストレーションがインストールされているかについての情報が非常に重要です。

IAR のバージョン/インストレーション情報を得るために内部プロジェクトデータを使用することを IAR は推奨しません。そのため、IAR の Windows レジストリエントリを参照したり、EW_DIR や PATH 環境変数などの基本的な情報を参照して推測しなければなりません。Parasoft は、EW_DIR 変数を EW のインストールディレクトリのパスに設定し、C++test バックアップメカニズムとして別の手法を可能にすることを強く推奨します。

C++test は、プロジェクトをインポートするときと .ewp プロジェクトファイルをスキャンするときの両方について、このバージョン付け手法を使用します。各手法と環境設定を利用して、選択/推測された EW がレジストリにあるかをチェックします。適切に登録されていない場合、C++test は EW と連携して動作することができません。

単一のセッション (アプリケーション実行) の最中、C++test は選択された 1 つのバージョン/インストレーションとだけ連携して動作します。これを変更するには、変更された環境で C++test で再起動する必要があります。

要件

コンパイラおよび C-SPY 実行可能ファイルが PATH 変数に追加されていること。
ランタイムライブラリのビルド用コンフィギュレーションファイルに EW_DIR 環境変数があり、EW インストールディレクトリを指していること。
"Build and run tests on IAR C-SPY Simulator" および "Build and run application on IAR C-SPY Simulator" テストフローは、EW_DIR 環境変数に EW インストールディレクトリが設定されていること、およびシミュレーターのバックエンドオプションが手動で用意されることを必要とします。そのために、テストフローのプロパティを編集します。
最近のバージョンの EW の場合、"Build and run tests on IAR C-SPY Simulator using EW-generated batch script template" および "Build and run application on IAR C-SPY Simulator using EW-generated batch script template" テストフローに EW プロジェクトビルド構成の名前を設定する必要があります ("IAR EW project Build Configuration" テストフロープロパティを使用)。
C++test ランタイムライブラリ機能の選択/構成によっては、IAR の C/C++ ランタイムライブラリ (DLib) 構成が特定の要件を満たさなければならない場合があります。特に、テスト結果をファイルチャネルで転送する場合 (デフォルト) および事後条件/アサーションでメッセージを出力する場合は、DLib に stdio 互換の FILE および printf インターフェイスがなければなりません。つまり、"Full" "Semihosted" DLib コンフィギュレーションを使用するか、適切な機能を有効化した "Custom" コンフィギュレーションを使用する必要があります。

既知の制限事項

EW には環境セットアップスクリプトが付属していません。そのため、EW のインストーラーによって設定された環境変数を使用するか、他の方法で環境をセットアップする必要があります。
IAR メモリ属性 (例えば '__data'、'__data20'、'__tiny'、'__near_func') に関する IAR 拡張は、完全にはサポートされていません。この制限により、解析の最中にパースエラーやインストゥルメントされたコードのコンパイルエラーなどのエラーが発生する可能性があります。また、元のコードのメモリ属性とは別のメモリ属性がコードに含まれているかのように解析される場合があります。
サポートされない IAR C++ 拡張アルゴリズム:

クラステンプレートの部分特殊化マッチング

- 関数テンプレートのパラメーター推論
これらの拡張は、IAR メモリタイプ属性 (例えば '__code' 、 '__data'、'__data20'、'__near_func') と C++test テンプレートを組み合わせた使用に関係します。特に IAR ARM コンパイラの場合、この問題は、テンプレートパラメーターに置き換わるタイプの不正なメモリタイプ属性につながる可能性があります。この制限はEC++ には影響しません (なぜならこのモードではテンプレートは使用できないからです)。このセクションで説明した IAR のテンプレート関連 C++ 拡張は、IAR DLIB ヘッダーで広範に使用されているため、C++test は IAR STL ヘッダーを使用しているコードを解析できないか、誤って解析する可能性があります。
(カバレッジビューなどで) C++test がレポートする関数シグニチャから IAR タイプ属性に関する部分が抜けている場合があります。例えば、 void f(int __data16 *) と void f(int __data24 *) という 2 つの異なる関数のカバレッジが、同じ f(int *) というシグニチャで表示される場合があります。
一部の特殊な状況では、IAR 言語拡張が無効化されていると、C++test が解析対象コードを解析できない可能性があります。この制限を回避するには、IAR 言語拡張を有効にします。IAR 言語拡張を有効にするには、EW 内のプロジェクト設定で行うか、プロジェクトの C++test コンパイラオプションに -e コンパイルオプションを追加します。
1. プロジェクトを選択し、[プロジェクト] > [プロパティ] > [Parasoft] > [C++test] > [ビルド設定] をクリックします。
2. [コンパイラオプション] フィールドに -e を入力し、[適用] をクリックします。
C++test にあらかじめ用意されている IAR コンパイラ構成を使用した場合、C++test は元のプロジェクトまたはビルドで使用されている C++ モードにかかわらず、EEC++ (Extended Embedded C++) モードで C++ コードを解析します。この制限は、C++test の EWSTM8 サポートには影響しません。この制限を回避するには、次の操作を行って、C++test IAR コンパイラ構成を修正します。

カスタムコンパイラコンフィギュレーションを作成します (カスタムコンパイラコンフィギュレーションの詳細については「カスタムコンパイラを使用するテストの設定」を参照)。
gui.properties ファイルの cppCompilerCmdLine= で始まる行を探し、--eec++ オプションを必要なオプションに変更します。この行は、例えば次のように見えます。
cppCompilerCmdLine=$(exe) $(filtered_opts) --eec++
-I $(CPPTEST_INCLUDE_DIR) $(input) -o $(output)
gui.properties ファイルに cppCompilationModeOption= で始まる行がある場合、--eec++ オプションも必要な値に変更する必要があります。この行は、例えば次のように見えます。
cppCompilationModeOption=--eec++
cpp.psrc ファイルを次のように変更します。
edgtk.preprocessorCommand で始まる行および edgtk.gccAutoconfiguratorCommand で始まる行を探し、--eec++ コンパイラオプションを必要な値に変更します。これらの行は、例えば次のように見えます。
edgtk.preprocessorCommand {exe} --preprocess=nl {out} {opts} --eec++ {in}
edgtk.gccAutoconfiguratorCommand {exe} --preprocess=nl {tmpout} {opts} --eec++ --silent --predef_macros {out} {in}

コンパイラプラグマディレクティブのサポートは限定的です。解析の際、プラグマディレクティブを含むソースコードを解析することができ、通常はソースコードにディレクティブが保持されますが、解釈されません。一部の特殊な状況では、プラグマディレクティブを含むソースコードは、それらのディレクティブが存在しないか、別の場所にあるかのように解析されます。このため、解析中にエラーが発生したり、解析結果が不正確になる場合があります。動的解析および C++ ファイルを含むプロジェクトの場合、コンパイラヘッダーファイル内で使用されているプラグマディレクティブ (inline または function_effects など) に関する警告メッセージが C++test のコンソールに出力される場合があります。たいていの場合、これらの警告はテスト対象コードの最適化レベルが元のプロジェクトに含まれる同じコードの最適化レベルと異なっていることを表しており、無視することができます。
IAR コンパイラにはいくつかの C++ モードがあり (例えば EC++、EEC++、C++ など)、コマンドラインオプションでモードを有効化できます。C++ モードを有効にすると、コンパイラコマンドラインに存在するすべてのソースファイルが、ファイル拡張子にかかわらず C++ ファイルとして扱われ、有効化されたモードでコンパイルされます。C++ モード選択オプションを含む .bdf ファイルから C++test プロジェクトを作成した場合、C++test はコンパイラのインストールディレクトリから他のディレクトリ (bin または inc など) も選択し、それらのディレクトリをリンクされたフォルダーとして扱う場合があります。結果として、解析スコープに余分なファイルが含まれ、パフォーマンスの問題を引き起こしたり、C++test コンソールに予期しないメッセージが表示されることがあります。この問題を回避するには、C++test プロジェクトから不要なリンクされたフォルダーを削除します。また、C++test が .bdf ファイルから新規プロジェクトを作成する際に、余分なディレクトリを選択するのを回避することもできます。例えば、GUI で次の操作を行います。
1. メインメニューの [ファイル] > [新規] > [プロジェクト] > [ビルドデータファイルからプロジェクトを作成] をクリックします。
2. .bdf ファイルを選択し、設定を確認します。
3. [次へ] をクリックし、プロジェクトのコンテンツを展開して不要なフォルダーを見つけます。
4. フォルダーを右クリックし、コンテキストメニューの [Remove folder(s)] をクリックします。
以下のキーワードはサポートされません。
- 特別な IAR ビルトイン演算子 __no_alloc_str() および __no_alloc_str16()
- __as_get_base()、__as_get_bounds()、および __as_make_bounds() のような特別な C-RUN 演算子
これらの IAR 拡張キーワードを使用するコードを解析すると、解析中にパースエラーが発生します。
以下のキーワードは部分的にサポートされます。
- 特別な IAR キーワード __no_alloc および __no_alloc16 キーワード
これらの IAR 拡張キーワードを使用するコードを解析すると、パースエラーやインストゥルメントコードのコンパイルエラーといったエラーが解析中に起こる可能性があります。
サポート対象アーキテクチャ固有の既知の制限については、以下のツールチェーン固有のセクションを参照してください。