RL78 SmartConfiguratorで気になった点とか改善する案とか報告してみるスレッド

こんにちは。NoMaYです。

いま2つ気になっています。

(1) ICCRL78とLLVM-RL78(とGNURL78)でワーニングレベルを上げるとワーニングがとてもたくさん出る
(2) RL78スマートコンフィグレータGUI上でオンチップデバッグトレースを使用する設定にしても予約RAM領域を空けていない

  • チョコです。

    RL78のSmartConfiguratorではコンポーネントの割り込みでレジスタ・バンクが指定できるようになりましたが、同じ割り込み優先順位で同じバンクを指定するとワーニングが出ますが、これはおかしいです。異なる優先順位ならレジスタバンクは同じにはできませんが、同じ優先順なら、多重割り込み許可でも同時には受け付けないので同じレジスタ・バンクを用いても問題ありません。

  • NoMaYさん、チョコさん

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

    RL78とスマートコンフィグレータをご活用いただきありがとうございます。

    RL78のBSP開発やスマートコンフィグレータ連携などを僭越ながら指揮させていただいております。

    他にはArduino開発やRL78用Amazon FreeRTOS開発も進めております。

    いただいたフィードバックは関係者に展開し改善を図ってまいります。

    いつも有益な情報をいただき、大変助かります。

    以上です

  • NoMaYさん、チョコさん

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

    開発チームと相談しました。

    (1) ICCRL78LLVM-RL78(GNURL78)でワーニングレベルを上げるとワーニングがとてもたくさん出る

     →まずBSPで検討を進めてみます。BSPの次版で修正できるところから直していきます。スマートコンフィグレータで出力するいろんなコンポーネントについても見てみようと思います。具体的に○○を見たほうがよいなどありましたらご指摘いただけると有難いです。

    (2) RL78スマートコンフィグレータGUI上でオンチップデバッグトレースを使用する設定にしても予約RAM領域を空けていない

     →対応を進めます。

    (3) RL78SmartConfiguratorではコンポーネントの割り込みでレジスタ・バンクが指定できるようになりましたが、

      同じ割り込み優先順位で同じバンクを指定するとワーニングが出ます

     →対応を進めます。

    以上です

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

    > (1) ICCRL78とLLVM-RL78(とGNURL78)でワーニングレベルを上げるとワーニングがとてもたくさん出る

    実際のワーニングの事例は以下に投稿したものがあります。

    RL78/G23  Fast Prototyping Boardを買いました
    japan.renesasrulz.com/cafe_rene/f/forum18/7087/rl78-g23-fast-prototyping-board/37997#37997

    プログラムは以下に投稿したものがあります。

    RL78/G23-64p Fast Prototyping Board Blinky sample program
    japan.renesasrulz.com/cafe_rene/m/sample_program/463

    それで、ワーニングレベルを上げるとワーニングがとてもたくさん出る理由ですけど、コード生成側ソースの幾つかでのヘッダファイルのインクルード忘れ、ですね。それによる、プロトタイプ宣言漏れ、のワーニングですね。

    特に大量に出るのが、LLVM-RL78で、未使用の割り込みの割り込みベクタに登録する空の関数がずらりと定義されたファイル r_cg_inthandler.c があるのですけど、インクルード忘れにより、割り込み関数ではなくて単なる関数が生成されていて、それが割り込みベクタに登録されてしまっています、、、(未使用の割り込みですので殆ど実害は無いのですが、本来は割り込み関数でretiであるべきところが誤ってretになっている通常関数が割り込みベクタに登録されてしまっています、、、) 実は、ヘッダファイル自体は r_cg_interrupt_handlers.h というファイル名で存在しています。

    また、LLVM-RL78とICCRL78で共通して、もうひとつ r_cg_sau_common.c というファイルでも r_cg_sau_common.h というヘッダファイルのインクルード忘れ(というのは言い過ぎかも知れませんが)で、ワーニングが多く出ています。こちらは、コードが不正になっているわけでも無く、関数本体記述箇所で出ているだけですので関数呼び出し時と違ってプロトタイプ宣言漏れによってゆくゆく不正なコードが生成されてしまうリスクも無いですので、あまり強く、おかしい、と言えない面もありますけれども。(ちなみに、それ以外のファイルでもインクルード忘れがあります。)

    なお、前者の割り込み関数に関しては手作業でヘッダファイルをインクルードする余地が全く無いのですが、後者のものについては手作業で Start user code ~ End user code の箇所にヘッダファイルをインクルードすることは可能です。

    あと、インクルード忘れ、以外もありますね。BSPモジュールですと、機能の有無(有効無効)を切り替える#defineを#defineされた箇所よりも前で参照している、というものがありました。(BSP_CFG_API_FUNCTIONS_DISABLEです。)

  • こんにちは。NoMaYです。

    ひとつ新たに気付いたことがあります。e2 studio 2021-04です。(もう1週間もすれば2021-07が出るでしょうが。)

    (0) RXスマートコンフィグレータに関しては、CC-RXでもGNURXでもe2 studioでC++プロジェクトを作る場合も使えるようになっています
    (先ほど別スレッドで認識しまして、今しがた試すと、プロジェクト作成ウィザードで、使うことを選択出来る、ようになってました)

    (1) 他方、RL78スマートコンフィグレータに関しては、LLVM-RL78でe2 studioでC++プロジェクトを作る場合には使えないようになっています
    (出来ない記憶があったので、今しがた試すと、プロジェクト作成ウィザードで、使うことは選択出来ない、ようになってました)

    LLVM-RL78(とGNURL78)はC++が使えることをセールスポイントのひとつにしています(と私は認識しています)ので、ゆくゆくは使えるようにした方が良いのではないでしょうか。

    [追記]

    すみません、e2 studio 2021-07でLLVM-RL78 C++ RL78スマートコンフィグレータという組み合わせのプロジェクトが作れるようになっていました。以下に画面コピーを投稿しました。

    e2 studioでC++ソースでのINDEXER/CODANの調子が悪そうなので調べてみようと思います
    japan.renesasrulz.com/cafe_rene/f/forum21/7273/e2-studio-c-indexer-codan/38910#38910
     

  • チョコです。

    コード生成でも最近問題になったのですが、スレーブ受信の"r_Config_IICA0_callback_slave_receiveend"を呼んでいる場所は最後のデータを受信した8クロック目のACK応答戻すタイミングの割り込みのところです。この後、1クロック経過したらACKを確認する9クロック目で割り込みが発生します。"r_Config_IICA0_callback_slave_receiveend"で長い処理を行うと、おかしなタイミングでの割り込みとなってしまいます。

    正しくは9クロック目の転送まで終了した下側の赤い四角で囲んだ「WREL0 = 1U;」の後にすべきです。少なくとも、この後にIICA0の割り込み発生はない、本当の最後です。

    また、callback関数の中(まだ割り込み処理の中です)で長い処理をゆるすのも問題があります。ここは、単純にフラグ処理だけにして、割り込みを抜けたところで続きの処理を行わせるべきではないでしょうか。

    スレーブ処理については、まだまだ言いたいことがあります。IICA0の場合にはI2Cバスの状態はIICS0レジスタでモニタされています。勝手に作った"g_iica0_slave_status_flag"みたいな変数で制御するのは間違いです。

    "if (0U == (g_iica0_slave_status_flag & _80_IICA_ADDRESS_COMPLETE))"は"if( 1==STD0)で判断すべきです。

    ついでに、ストップ・コンディション検出割り込み処理の中でSPIE0を0にするのも間違いです。

  • チョコです。

    また、IICA0のスレーブの割り込み処理です。

    送信したデータに対してマスタがNACK応答したときの処理ですが、"r_Config_IICA0_callback_slave_error(MD_NACK);"とあたかもエラーのような処理を行っていますが、これは問題があると思います。この状態はマスタが受信を完了したことを示しているだけです。これをエラーとして処理するのには抵抗があります。

    "r_Config_IICA0_callback_slave_error"はユーザに処理をゆだねているので、間違った処理を行う危険性が高いです。(せめて引数がマスタが受信終了したことがわかるような内容ならまだしも、"MD_NACK"では、意味不明です。

  • チョコです。

    >"if (0U == (g_iica0_slave_status_flag & _80_IICA_ADDRESS_COMPLETE))"は"if( 1==STD0)で判断すべきです。

    これについて、少し追加しておきます。

    マスタが、通信完了時にストップコンディションを発行しないで、リスタートを行うのはSCでもサポートされています。

    マスタがリスタートを行ったときに、このスレーブの処理では対応できません。ここらが、コード生成でもリスタートに対応できなかった原因と考えられます。if( 1==STD0)で処理していればきちんと処理できるようになったと思われます。

  • チョコです。

    IICA関係のプログラムを眺めていたので、もう1件です。

    IICAに限らず、従来のコード生成の通信系はそのままでは、通信が完了したかどうかを確認できません。Arduinoが幅を利かせてきて、ベアメタル型の裏で割り込みを待つのが一般常識でなくなってきています。ここらの終了条件が不明確なために、SendやReceiveのAPIを呼び出して、戻ってきたら処理は完了してるいると誤解して、次の通信処理を起動していいるユーザがかふぇルネに結構見受けられました。ここらをフラグでも準備してきちんと対応するように鈴木さんにはぼやいていたのですが、SCでも変わっていないようです。

    上記のようなユーザがいるのに、Master_SendやMaster_ReceiveのAPIでは、以下のようにバスのことしかケアしないでスタートコンディションを発行しています。前の通信が完了していることをきちんとチェックしてから次の処理を起動すべきです。これは、通信全体をきちんと見ていないからではないでしょうか。

    このエラー処理を追加するだけでもユーザはエラーの原因を考えるヒントになるかもしれません。

    最後に、失礼な表現が多数あったであろうことをお詫びしておきます。ぜひ、改善をよろしくお願いします。

  • チョコです。

    SCの「ソフトウェアコンポーネント設定」で「インターバル・タイマ」を選択したときの「動作モード」が「8ビット・カウント・モード」になっているのが奇異に感じます。

    16ビットがメインのモードで、対象も以下のように8ビットよりは多いです。(TAU は16ビットがメインで、8ビットはチャネル1と3だけのオプション機能のようなものです。

    初期状態を考え直してもらいたいです。

    また、設定の細かなところですが、インターバル時間をμsからmsに変更したら、100のところが赤くなるたけでどこをいじればいいかがわからない。何かコメントをポップアップで出してほしい。

    この場合には、クロック・ソースを変更するしかないと思いますが。

    引き続いて今度はTAU01を時間だけ10μsにしてもエラーは発生しません。

    そこで他の機能にして、「コードの生成」をクリックすると、以下のようにワーニングメッセージが出ます。

    しかし、問題の原因はこの時表示しているコンポーネントではありません。問題はタイマなのですが、コンポーネントの「タイマ」に小さく赤い印がついているだけです。要は、TM00でCK00をfCLK/2^8に設定したのに、TM01の設定でそれが反映されていないのが原因です。どこに問題があるかがナビゲートできていません。ここらを改善しないと初心者にはつらいかもしれません。