e2 studio v7.5.0でRDP v1.20ダウンロード後もSCFGプロジェクトを生成させるとr_bsp v4.01が使用されてしまう

こんにちは。NoMaYです。

今首を傾げているのですが、RDP v1.20にはr_bsp v5.20が含まれていますので、それが使用されることを期待したのですが、実際は掲題の通りになります。ちょっと意外でした、、、(スマートコンフィグレータウィンドウのコンポーネントタブ上でr_bsp v5.20へと変更することは出来ましたので、恐らくRDP v1.20のインストールミスでは無いと思われます、、、)

ちなみに、プロジェクトの生成では、コンパイラはCC-RX V3.01、デバイスはR5F565NEDxFP、に設定して試しました。

Parents
  • こんにちは。NoMaYです。

    CS+(V8.02.00)+スマートコンフィグレータ(V2.2.0)でr_bsp v5.20を使用すると、3種類のコンパイラ向けのそれぞれのiodefine.hのフォルダのパスが、3つともインクルードパスに含まれてしまいます。(下記の画面コピーを参照) CS+では、今のところ、まだiodefine.hを#include "iodefine.h"と書くことが出来ますので、これにはちょっと注意が必要ですね。(対して、e2 studioでは、iodefine.hのフォルダのパスをインクルードパスに含めることが出来ない(含めようとしてもコード生成時に強制的に除去される)ので書けなくなっていて、代わりに#include "platform.h"と書くことになっていますね。)

    対処としては、順番を入れ替えて(デフォルトは、IAR C/C++コンパイラ向け→GNURX向け→CC-RX向け、の順)、CC-RX向けのiodefine.hのフォルダのパスが最初になるようにすることかと思います。(なお、他のコンパイラ向けのiodefine.hのフォルダのパスを削除しても、CS+とスマートコンフィグレータの操作手順次第では、いつのまにか復活してしまうことがあります。)

    もっとも、今のところ、IAR C/C++コンパイラ向けのiodefine.hはCC-RXで使用しても正しく動作するように作成されていますので、ひとまずデフォルトの順番でも大丈夫なようです。

    以下、画面コピーです。

    3種類のコンパイラ向けのそれぞれのiodefine.hのフォルダのパスが3つともインクルードパスに含まれる



    対処としては順番を入れ替えてCC-RX向けのiodefine.hのフォルダのパスが最初になるようにする



    他のコンパイラ向けのiodefine.hのフォルダのパスを削除しても操作手順次第では復活してしまうことがある



    ちなみに、r_bsp v5.20内では、以下のように記述されていますので、インクルードパスの順番には影響されません。(さらには、インクルードパスにiodefine.hのフォルダのパスが含まれていなくても構いません。その代わり、r_bspのフォルダのパスが必要になります。)

    src/smc_gen/r_bsp/board/generic_rx65n/r_bsp.h

    #if defined(__CCRX__)
    #include    "mcu/rx65n/register_access/ccrx/iodefine.h"
    #elif defined(__GNUC__)
    #include    "mcu/rx65n/register_access/gnuc/iodefine.h"
    #elif defined(__ICCRX__)
    #include    "mcu/rx65n/register_access/iccrx/iodefine.h"
    #endif /* defined(__CCRX__), defined(__GNUC__), defined(__ICCRX__) */

    それから、今のところ、IAR C/C++コンパイラ向けのiodefine.hは以下のように記述されていました。

    src/smc_gen/r_bsp/mcu/rx65n/register_access/iccrx/iodefine.h

    略(コメント)

    #ifndef __RX65NIODEFINE_HEADER__
    #define __RX65NIODEFINE_HEADER__

    #ifdef __IAR_SYSTEMS_ICC__
    #pragma language=save
    #pragma language=extended
    #ifndef _SYSTEM_BUILD
    #pragma system_include
    #endif
    #endif

    #ifdef __IAR_SYSTEMS_ICC__
    #define __evenaccess
    #else
    #define __sfr
    #endif

    略(CC-RX向けのiodefine.hと同じ内容)

    #define BSC     (*(volatile struct st_bsc     __sfr __evenaccess *)0x81300)
    #define CAC     (*(volatile struct st_cac     __sfr __evenaccess *)0x8B000)

    #define WDT     (*(volatile struct st_wdt     __sfr __evenaccess *)0x88020)
    #define FLASHCONST  (*(volatile struct st_flashconst     __sfr __evenaccess *)0xFE7F7D90)
    #define TEMPSCONST  (*(volatile struct st_tempsconst     __sfr __evenaccess *)0xFE7F7D7C)

    略(CC-RX向けのiodefine.hと同じ内容)

    #ifdef __IAR_SYSTEMS_ICC__
    #pragma bitfields=reversed
    #else
    #pragma bit_order left (←CC-RX向けのiodefine.hと同じ)
    #endif

    #ifndef __IAR_SYSTEMS_ICC__
    #pragma unpack (←CC-RX向けのiodefine.hと同じ)
    #endif

    略(CC-RX向けのiodefine.hと同じ内容)

    #ifdef __IAR_SYSTEMS_ICC__
    #pragma bitfields=default
    #pragma language=restore
    #else
    #pragma bit_order (←CC-RX向けのiodefine.hと同じ)
    #endif

    #ifndef __IAR_SYSTEMS_ICC__
    #pragma packoption (←CC-RX向けのiodefine.hと同じ)
    #endif

    #endif

     

Reply
  • こんにちは。NoMaYです。

    CS+(V8.02.00)+スマートコンフィグレータ(V2.2.0)でr_bsp v5.20を使用すると、3種類のコンパイラ向けのそれぞれのiodefine.hのフォルダのパスが、3つともインクルードパスに含まれてしまいます。(下記の画面コピーを参照) CS+では、今のところ、まだiodefine.hを#include "iodefine.h"と書くことが出来ますので、これにはちょっと注意が必要ですね。(対して、e2 studioでは、iodefine.hのフォルダのパスをインクルードパスに含めることが出来ない(含めようとしてもコード生成時に強制的に除去される)ので書けなくなっていて、代わりに#include "platform.h"と書くことになっていますね。)

    対処としては、順番を入れ替えて(デフォルトは、IAR C/C++コンパイラ向け→GNURX向け→CC-RX向け、の順)、CC-RX向けのiodefine.hのフォルダのパスが最初になるようにすることかと思います。(なお、他のコンパイラ向けのiodefine.hのフォルダのパスを削除しても、CS+とスマートコンフィグレータの操作手順次第では、いつのまにか復活してしまうことがあります。)

    もっとも、今のところ、IAR C/C++コンパイラ向けのiodefine.hはCC-RXで使用しても正しく動作するように作成されていますので、ひとまずデフォルトの順番でも大丈夫なようです。

    以下、画面コピーです。

    3種類のコンパイラ向けのそれぞれのiodefine.hのフォルダのパスが3つともインクルードパスに含まれる



    対処としては順番を入れ替えてCC-RX向けのiodefine.hのフォルダのパスが最初になるようにする



    他のコンパイラ向けのiodefine.hのフォルダのパスを削除しても操作手順次第では復活してしまうことがある



    ちなみに、r_bsp v5.20内では、以下のように記述されていますので、インクルードパスの順番には影響されません。(さらには、インクルードパスにiodefine.hのフォルダのパスが含まれていなくても構いません。その代わり、r_bspのフォルダのパスが必要になります。)

    src/smc_gen/r_bsp/board/generic_rx65n/r_bsp.h

    #if defined(__CCRX__)
    #include    "mcu/rx65n/register_access/ccrx/iodefine.h"
    #elif defined(__GNUC__)
    #include    "mcu/rx65n/register_access/gnuc/iodefine.h"
    #elif defined(__ICCRX__)
    #include    "mcu/rx65n/register_access/iccrx/iodefine.h"
    #endif /* defined(__CCRX__), defined(__GNUC__), defined(__ICCRX__) */

    それから、今のところ、IAR C/C++コンパイラ向けのiodefine.hは以下のように記述されていました。

    src/smc_gen/r_bsp/mcu/rx65n/register_access/iccrx/iodefine.h

    略(コメント)

    #ifndef __RX65NIODEFINE_HEADER__
    #define __RX65NIODEFINE_HEADER__

    #ifdef __IAR_SYSTEMS_ICC__
    #pragma language=save
    #pragma language=extended
    #ifndef _SYSTEM_BUILD
    #pragma system_include
    #endif
    #endif

    #ifdef __IAR_SYSTEMS_ICC__
    #define __evenaccess
    #else
    #define __sfr
    #endif

    略(CC-RX向けのiodefine.hと同じ内容)

    #define BSC     (*(volatile struct st_bsc     __sfr __evenaccess *)0x81300)
    #define CAC     (*(volatile struct st_cac     __sfr __evenaccess *)0x8B000)

    #define WDT     (*(volatile struct st_wdt     __sfr __evenaccess *)0x88020)
    #define FLASHCONST  (*(volatile struct st_flashconst     __sfr __evenaccess *)0xFE7F7D90)
    #define TEMPSCONST  (*(volatile struct st_tempsconst     __sfr __evenaccess *)0xFE7F7D7C)

    略(CC-RX向けのiodefine.hと同じ内容)

    #ifdef __IAR_SYSTEMS_ICC__
    #pragma bitfields=reversed
    #else
    #pragma bit_order left (←CC-RX向けのiodefine.hと同じ)
    #endif

    #ifndef __IAR_SYSTEMS_ICC__
    #pragma unpack (←CC-RX向けのiodefine.hと同じ)
    #endif

    略(CC-RX向けのiodefine.hと同じ内容)

    #ifdef __IAR_SYSTEMS_ICC__
    #pragma bitfields=default
    #pragma language=restore
    #else
    #pragma bit_order (←CC-RX向けのiodefine.hと同じ)
    #endif

    #ifndef __IAR_SYSTEMS_ICC__
    #pragma packoption (←CC-RX向けのiodefine.hと同じ)
    #endif

    #endif

     

Children
  • NoMaYさん

    こんにちは、シェルティです。

    ご指摘ありがとうございます。大変助かります。
    開発チームに確認してきました。本件対処を進めているとのことです。

    BSPのxmlに各コンパイラ専用のファイルの情報を追加し、
    Smart Configuratorがそれを読み込み、
    不要なファイル/フォルダパスをプロジェクトに
    追加しないようにできるか検討中です。

    以上です