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の設定でそれが反映されていないのが原因です。どこに問題があるかがナビゲートできていません。ここらを改善しないと初心者にはつらいかもしれません。

  • チョコさん、NoMaYさん

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

    ツール部門のメンバと相談開始しました。対応を進めたいと思っています。

    種々フィードバックいただき感謝です。検討状況進捗などまた書き込みます。

    以上です

  • チョコです。

    RL78/G23FPBにRL78/G14FPBからArduinoのデジタル入出力関数を移植することを検討していて、少し手抜きをしようと考えて、SCでデジタル入出力の端子兼用機能であるアナログ入力(デバイスの初期状態)を初期設定でデジタル入力に設定しようと考えました。そこで、SCで以下のように設定を行いました。

    すると、Config_PORT.cは以下のようにコード生成されていました。

    PDIDIS0レジスタで該当するビットが1になっていて、確かに設定内容には合っているのですが、違和感を禁じえません。

    PDIDIS0レジスタはディフォルトでは0になっているのをわざわざセットしています。

    これは、以下のように入力バッファがオプション的な扱いになっているのが原因していると思われます。

    出力に設定すると、これは選択できなくなりますが、入力に指定したときにもこの設定はなくていいはずです。

    ここで、念のためにP00を出力に設定してコード生成すると、以下のように、P00でもPDIDIS0レジスタの該当するビットが1になっています。

    これは、PDIDIS0レジスタの意味を取り違えていると考えられます。

    ハードウェア マニュアルには、以下のように書かれています。

    つまり、入力や出力の時にPDIDIS0レジスタの該当するビットを1にするのは明らかに間違いです。

    どちらかというと、未使用時のみ選択できるようにすべきでそれ以外では0にしておくべきです。

    または、入力や出力と同等にして、「入力バッファオフ」の選択子にすべきです。

    以上

  • チョコです。

    >つまり、入力や出力の時にPDIDIS0レジスタの該当するビットを1にするのは明らかに間違いです。

    >どちらかというと、未使用時のみ選択できるようにすべきでそれ以外では0にしておくべきです。

    >または、入力や出力と同等にして、「入力バッファオフ」の選択子にすべきです。

    以下のように修正します。

    PDIDIS0レジスタの該当するビットを1にできるのは、未使用かNchオープンドレイン出力だけにすべきです。(この2つの場合には、無条件に1にしてもいいかもしれません。)

     

  • チョコです。

    TM07をインターバルタイマに設定した状態で、IIC00を追加したところ、ワーニングが発生しました。

    これは、どうもSCL00が使用する端子がリダイレクトした場合のTO07とぶつかっているからだと思われます。

    これは明らかにおかしいワーニングです。TM07とIIC00の接点はこのP10しかありません。

    しかし、TM07はインターバル・タイマに設定しているので、この端子を使うことはないのでリダイレクトしたとしても問題ないはずです。

    そもそも、タイマの出力を未使用時に他の兼用機能に影響するような初期化をしていたら、そのようなコードを出すことが問題では。

    以上

  • チョコです。

    SCが生成した簡易IICの割り込み処理の先頭にコード生成にはなかったソフトウェアタイマによる遅延処理が追加されています。

    これ自体は、以前から私がタイマ割り込みでやっていることと同じ目的(RL78の簡易IICには、クロックストレッチがないことへの対策)だと思います。この目的だけ考えるとこれでいいのですが、このやり方では、この遅延時間の間は割り込み処理の中になるので、他の割り込みを受け付けできません。おそらく10μ秒以上の時間はあるかと思います。この点をどこかで明確にしておくべきでしょう。出来れば、ここはハードウェアのタイマを使うことで、CPU時間を解放することをお勧めします。

    複数のリソースを組み合わせることはコード生成機能としては、難しいかもしれませんが。