スマートコンフィグレータの自動生成をカスタマイズしたい

コードジェネレータに /* Start user code があり、ここでカスタムコードを使用できるのですが、

/*Start user code 部分以外にカスタムコードを挿入したいのです。

/* Start user code 部分以外に挿入しても、「コード生成」で消えてしまうので

生成部分に手をいれて自動で出力するようにできないか?という希望がありました。

e2Studio を調べてみたら、 e2Studioのインストールフォルダ下、eclipse\pluginsに

jarファイルがあり、jarファイルの中に出力するコードのひな形(?)があり、これを修正することでほぼ

目的の出力が得られるようにはなりました。

ただ、このjarファイルはバージョンでファイルが分かれていて、e2Studioが何をもとに

バージョンを選択しているのか分かりません。

ファイルの日付?バージョンの新しいもの?

scfgファイルを見ると、コンポーネントのバージョンが記載されていたので、試しにこれを直接修正してみましたが、

e2StudioのスマートコンフィグレータUIの「概要」に示されるバージョン番号は変わらず。

(これが変更できれぱ、該当のバージョンを使用できるのかも)

jarファイルの中には、plugin.xml ファイルがあり、ここにバージョンがありましたので、こちらもscfgに合わせたバージョンに修正してみました。

このような修正(が出来たとして)は当然サポート外の修正となるのは承知していますが、

CGのコンポーネントバージョン(修正方法)とバージョンに対応するjarファイルの選択の仕組みをご存じの方が見えましたら、情報をお願いします。

Parents
  • ka.makiharaさん、こんにちは。NoMaYです。

    すみません、本件そのものについては、私も知らなくて、回答が出来ませんけれども、ちなみに、どのコンポーネントのどの部分に関してなのでしょうか?


    私が認識していることでは、以下のような点がありますけれども。

    * #pragma interrupt部分での多重割り込み許可
    * 割り込みエントリ関数の最初の部分と最後の部分でμITRON(NORTi等)対応のコードを入れたい
    * 割り込み関数を全体的に書き換えたい(例えば通信系CGコンポーネントでのリングバッファ対応とかスレーブモード処理とか)
    * 割り込み処理の起動処理(例えば送受信開始処理など)を全体的に書き換えたい)
    * コンポーネントの初期化処理で独自の初期化処理を追加したい(XXXX_UserInit()ではタイミング的にスッキリしない)
    * スタートアップ時のコンポーネントの一連の初期化処理と同じタイミングで独自の初期化処理を追加したい
    * インクルードファイルの順序問題や相互依存問題でテンプレートでのユーザ記述箇所以外に#includeを記述したい

  • ほやさん、NoMaYさんこんにちは。

    ほやさんに教えていただいた、別プロジェクトでやる方法と

    以前 NoMay さんが試していた、スマートコンフィグレータでLibを作る方法、を合わせてやってみようかと思っています。

    ・まずやりたいのは、NORTi の割込み対応コードを入れ込みたい。

    ・きっかけは、RSPIとI2Cのコンポーネントで、user関数で定義された割込みハンドラに /* start user code がなかったため

     ビルド(コード生成)毎に入れ込みたいコードが消えてしまう。

    ・mispoさんからは、ハンドラ内でauto変数も使用できない、と言われているので、RSPIの割込みハンドラ内の変数をグローバル変数とする。

    FITコンポーネントは一度ファイルが生成されると、消去でもしない限り、上書きされない(ヘッダーは変わる)ので

    入れ込んだのですが、CGはクリーンビルドでも更新されて消えてしまうので。

    消えてしまっても、ビルドエラーにならないので、間違ってリリースしてしまう危険性があり、

    何とか自動で入れ込みたいのです。

  • CGはクリーンビルドでも更新されて消えてしまうので。
    これについては .project ファイルから、SCContentBuilder と ScannerConfigBuilder のブロックを外し、
    Project Nature からも ScannerConfigNature を外してしまえば回避できると思います。

    ↑ 「SmartConfiguratorなしでプロジェクトを作った時の .project と同じにする」という意味です。
    次にコードを生成する時だけ戻せばOK。

  • ka.makiharaさん、こんにちは。NoMaYです。

    ところで、RSPIとI2Cに関してはFITでは駄目だから、という判断なのだと思われるのですが、どういうところが駄目なのでしょう?


    ちなみに、ライブラリ化うんぬんの件は、たぶん、手助けにならないと思います。

    それよりは、私が以前に別スレッドにリプライした内容なのですけれども、そちらの方がまだ幾らか手助けになるかもと思うのです。

    スマート・コンフィグレータ SCIの割り込み
    japan.renesasrulz.com/cafe_rene/f/forum21/5875/sci/32854#32854


    他方、思うに、発端となったミスポさんのNORTiの課題に関しては、割り込みベクタをフックしてCG(やFIT)の割り込みを横取りして事前に(及び事後に)しかるべきNORTiの割り込み管理関数呼び出しを実行出来るようにするフレームワーク的な仕組みを実装する、みたいなやり方が正統的(?)やり方のような気がします。

    箇条書きにしても意味が伝わらない可能性が高いですが、、、(気分が高揚した時があれば作ってみますが、、、)

    * 本来のベクタテーブルに加えてフック用ベクタテーブルを用意する
    * RXマイコンの割り込みベクタテーブルレジスタはフック用ベクタテーブルを指すように値を変更する
    * フック用ベクタテーブルに登録する処理は以下のようなルーチンです
    * OS管理外割り込みとするかOS管理割り込みとするか手作業でテーブル(Cソース、もしくは、アセンブラソース)を書き換えて指定する

    OS管理外割り込み

    * 本来のベクタテーブルが指す割り込み関数へジャンプする

    OS管理割り込み

    * NORTiの割り込み管理関数(入口用)を呼ぶ
    * PSWと戻り番地をスタックに積んで本来のベクタテーブルが指す割り込み関数へジャンプする(積む理由は割り込み関数の最後がRTE命令だから)
    * 割り込み関数側でRTE命令が実行されたら此処へ戻ってくる
    * NORTiの割り込み管理関数(出口用)を呼ぶ
    * RTE命令(割り込みが発生した時のアドレスへ戻る)


    あと、まだコードの断片しかありませんが、裏技的に(標準C言語の文法とCC-RXのC言語拡張文法の頓知的バランスの上で)以下のようなコードが利用出来そうな気がします。(変なコンパイルワーニングを我慢すればですけれども。)

    /* Start user code for global. Do not edit comment generated here */

    #define r_Config_RSPI0_transmit_interrupt(...) r_Config_RSPI0_transmit_interrupt(save)

    /* End user code. Do not edit comment generated here */

     

    #if FAST_INTERRUPT_VECTOR == VECT_RSPI0_SPTI0
    #pragma interrupt r_Config_RSPI0_transmit_interrupt(vect=VECT(RSPI0,SPTI0),fint)
    #else
    #pragma interrupt r_Config_RSPI0_transmit_interrupt(vect=VECT(RSPI0,SPTI0))
    #endif
    W0521051: Standard requires that parameter "save" be given a type by a subsequent declaration ("int" assumed)
    static void r_Config_RSPI0_transmit_interrupt(void)
    {
        略
    }

     

    /* Start user code for adding. Do not edit comment generated here */

    #pragma interrupt __r_Config_RSPI0_transmit_interrupt(vect=VECT(RSPI0,SPTI0))
    #pragma inline_asm _r_Config_RSPI0_transmit_interrupt

    void _r_Config_RSPI0_transmit_interrupt(void)
    {
        // TODO: PSWと戻り番地をスタックに積む
        bra.w __$r_Config_RSPI0_transmit_interrupt
    }

    void __r_Config_RSPI0_transmit_interrupt(void)
    {
        // TODO: NORTiの割り込み管理関数(入口用)を呼ぶ

        _r_Config_RSPI0_transmit_interrupt();

        // TODO: NORTiの割り込み管理関数(出口用)を呼ぶ
    }

    /* End user code. Do not edit comment generated here */

     

    以下、TODOが未コーディングの状態での生成コードです。(CC-RX V3.04 標準最適化)

    ___r_Config_RSPI0_transmit_interrupt:
            .STACK  ___r_Config_RSPI0_transmit_interrupt=36
            .RVECTOR    39,___r_Config_RSPI0_transmit_interrupt
            PUSHM R14-R15
            PUSHM R1-R5
            ._LINE_TOP  inline_asm
        bra.w __$r_Config_RSPI0_transmit_interrupt
            ._LINE_END  inline_asm
            POPM R1-R5
            POPM R14-R15
            RTE

     

  • ka.makiharaさん、ほや さん、こんにちは。NoMaYです。

    > ↑ 「SmartConfiguratorなしでプロジェクトを作った時の .project と同じにする」という意味です。

    私の経験では、.projectをそのようにしても(少なくともe2 studio 2022-01では)何かの拍子に削除したものが復活してしまい、よろしく無かったです。以下のスレッドに投稿した設定の方が(e2 studio 2022-04でも)具合が良いようです。

    壊れてしまったAmazon FreeRTOS Renesas RX OTA e2 studioプロジェクトを直してみるスレッド
    japan.renesasrulz.com/cafe_rene/f/forum21/8192/amazon-freertos-renesas-rx-ota-e2-studio/42292#42292
     

  • NoMaYさん、こんにちは。

    残念な話なのですが、FITがダメというわけではなく、最初にこの機能を作成した人がたまたまCGを利用したというだけでして、テストも終わっているので、今からFITに置き換えたくない。という理由なのです。。。

    このような小細工(?)をするぐらいなら、さっさとFITに置き換えてもいいんじゃないかと思うのですが。

    e2Studioの仕組みを知る亊もできるので、調べつつ(お尋ねしつつ)やっています。

    ライブラリ化は、おっしゃる通りなのですが、一度固まってしまえば、exeプロジェクトよりビルドする頻度は大きく減るので、上書きの頻度も下がる、という程度です。

    フレームワークを作るのが一番正しそうな気はするのですが、これも残念な理由から、すぐには対処できなさそうなのです。

    フレームワークの件で少し質問なのですが、

    NORTiの割込み管理関数はハンドラ(Cコード)の入り口、出口に入れますが、

    この場合、アセンブラコードを示して頂いたように、PUSHM R14-R15 PUSHM R1-R5 の後に管理関数が入ってきます。

    フレームワークの手順の場合、PUSHM の前に管理関数が入ってくる事になりますか?

    今回、ミスポさんからは、スマートコンフィグレーターで生成したハンドラ用ということで

    管理関数を頂いていまして、#pragma interrupt を使用したハンドラに使用してください、と言われています。

    管理関数もアセンブラで記述されていまして、アセンブラに詳しくなくて、

    PUSHM との順番が変わってもよいものかどうか、判断しかねています。

    裏技、良い手ですね、実はこれが一番現実的なのかもしれない・・・です。

Reply
  • NoMaYさん、こんにちは。

    残念な話なのですが、FITがダメというわけではなく、最初にこの機能を作成した人がたまたまCGを利用したというだけでして、テストも終わっているので、今からFITに置き換えたくない。という理由なのです。。。

    このような小細工(?)をするぐらいなら、さっさとFITに置き換えてもいいんじゃないかと思うのですが。

    e2Studioの仕組みを知る亊もできるので、調べつつ(お尋ねしつつ)やっています。

    ライブラリ化は、おっしゃる通りなのですが、一度固まってしまえば、exeプロジェクトよりビルドする頻度は大きく減るので、上書きの頻度も下がる、という程度です。

    フレームワークを作るのが一番正しそうな気はするのですが、これも残念な理由から、すぐには対処できなさそうなのです。

    フレームワークの件で少し質問なのですが、

    NORTiの割込み管理関数はハンドラ(Cコード)の入り口、出口に入れますが、

    この場合、アセンブラコードを示して頂いたように、PUSHM R14-R15 PUSHM R1-R5 の後に管理関数が入ってきます。

    フレームワークの手順の場合、PUSHM の前に管理関数が入ってくる事になりますか?

    今回、ミスポさんからは、スマートコンフィグレーターで生成したハンドラ用ということで

    管理関数を頂いていまして、#pragma interrupt を使用したハンドラに使用してください、と言われています。

    管理関数もアセンブラで記述されていまして、アセンブラに詳しくなくて、

    PUSHM との順番が変わってもよいものかどうか、判断しかねています。

    裏技、良い手ですね、実はこれが一番現実的なのかもしれない・・・です。

Children
  • ka.makiharaさん、こんにちは。NoMaYです。

    > フレームワークの手順の場合、PUSHM の前に管理関数が入ってくる事になりますか?

    作り方次第ですけれども、NORTiを使う前提でのものですので、今の管理関数がそのまま使えるようにフレームワークを作るようにすれば良いと思ってます。あくまでイメージ的なものですが、以下のようにフックすれば良いと思ってます。

    OS管理割り込み

        PUSHM R14-R15
        PUSHM R1-R5

        // TODO: NORTiの割り込み管理関数(入口用)を呼ぶ

        // TODO: PSWと戻り番地をスタックに積んで本来のベクタテーブルが指す割り込み関数へジャンプする(積む理由は割り込み関数の最後がRTE命令だから)
        // ざっくり書いてますが、やり方は利便性/難易度/小ささの組み合わせでピンキリ(は大げさかも)のレベルの実装がある、だろうなぁ、と思ってます。
        // なお、ベクタテーブルを介さず直接ジャンプすることは出来ません。なぜなら、FITもCGもCC-RX版は割り込み関数がstatic宣言になっていますので。

        // TODO: NORTiの割り込み管理関数(出口用)を呼ぶ

        POPM R1-R5
        POPM R14-R15
        RTE

     

    > ライブラリ化は、おっしゃる通りなのですが、一度固まってしまえば、exeプロジェクトよりビルドする頻度は大きく減るので、上書きの頻度も下がる、という程度です。

    それから、こちらは、そういう意図でしたか。納得がいきました。


    [追記]

    OS管理外割り込みも、1バイト/1クロックでも無駄な命令は削る、という考えをしなければ以下もありと思います、、、(どのみち、ベクタテーブルを介してジャンプする、というコードで何本かはレジスタを使うでしょうし、、、)

    OS管理外割り込み

        PUSHM R14-R15
        PUSHM R1-R5

        // TODO: PSWと戻り番地をスタックに積んで本来のベクタテーブルが指す割り込み関数へジャンプする(積む理由は割り込み関数の最後がRTE命令だから)

        POPM R1-R5
        POPM R14-R15
        RTE