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

こんにちは。NoMaYです。

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

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

  • こんにちは。NoMaYです。

    e2 studio 2021-07のRL78スマートコンフィグレータGUI上からBSPモジュールをアップデートしたのですけど、以下の障害が発生しました。(詳細は画面コピーを参照して下さい。) CS+と単体RL78スマートコンフィグレータも同様です。

    (1) アップデート操作は正常終了したけれどBSPモジュールのソースがアップデートされていない

    正確には、新しいBSPモジュールで追加されたソースは追加されましたが、既にあったソースは変更されていませんでした。

    (2) アップデート操作は正常終了したけれどプロジェクトを削除して再インポートするとBSPモジュールのバージョンが古いまま

    これは上記の(1)で実質的にはソースがアップデートされていなかったので古いままというのは分からなくは無いですけど、そもそもアップデート操作は正常終了しているのにそうなっているのは変だと思います。もっとも、別の見方も出来まして、SCFGファイルの保存操作をしていなかったというのはあるのですが、e2 studioのツールバーの保存ボタンは押せない状態でしたし、プロジェクトを削除する時に何の警告も表示されなかったのも変だと思います。(記憶では、RXの方だと思いますけど、SCFGファイルを保存せずにプロジェクトを削除しようとすると警告が表示されていたと思うのです。)

    以下、e2 studioの画面コピーです。

    アップデート操作は正常終了









    BSPモジュールのソースがアップデートされていない(左ペインが新規作成したもの、右ペインがアップデータしたもの)



    プロジェクトを削除して再インポートするとBSPモジュールのバージョンが古いまま

     
    [追記]

    元の状態に戻してもう一回アップデート操作をやり直して確認したところ、アップデート操作直後はBSPモジュールのバージョンは新しくなっていました。ですので、SCFGファイルを保存していなかった(保存することが出来なかった)というのが上記の(2)の肝心な点なのかなと思いました。

    以下、e2 studioの画面コピーです。


     

  • チョコです。

    先ほどコメントを書き込みましたが、”スマートコンフィグレータのCG で生成した SCI 調歩同期のコードで、連続複数回の送信が出来ません"でもコード生成の時代からの通信処理に共通の問題が上がっていました。

    https://japan.renesasrulz.com/cafe_rene/f/forum5/7355/cg-sci

    ベアメタル型のプログラミングに対応しているのでしょうが、あまりにも不親切です。最低でも、完了フラグの処理くらいはつけておくべきです。できれば、そのフラグを使って通信完了までループするようなAPI関数も準備してほしいです。

    以上

  • こんにちは。NoMaYです。

    以前から私は送信完了や受信完了をウェイトするタイプのAPI関数名として既存のAPI関数名の末尾に_UWT(Unlimited Wait Timeの意)を付けたものを提案していましたが(とは言えはっきりした行為を行ってはいませんでしたが)、今朝、以下ではどうだろうか?という考えが思い浮かびました。サンプルプログラム置き場に投稿してある自前のサンプルプログラムで試行してみようかなと思い始めました。(正直、どうせやるならBSPモジュールも最新版にしてとも思うものの、とっかえるのがちょっと億劫でもあり、そこは今のまま放置するかも知れませんけれど。)

    以前の案: API関数の末尾に _UWT を付ける (先頭が U_ なのは自作関数であったからです)

    例)

    void U_Config_SCI12_IIC_Master_Send_UWT(uint8_t adr, uint8_t * const tx_buf, uint16_t tx_num) ← RXの例
    void U_Config_UART1_Send_UWT(uint8_t adr, uint8_t * const tx_buf, uint16_t tx_num) ← RL78の例

     
    今朝の案: API関数の引数に、完了を待つ/待たないのフラグを追加、してみる(boolが方針的に不可ならuint8_tです)

    例)

    void U_Config_SCI12_IIC_Master_Send_Ex(uint8_t adr, uint8_t * const tx_buf, uint16_t tx_num, bool tx_wflag) ← RXの例
    void U_Config_UART1_Send_Ex(uint8_t adr, uint8_t * const tx_buf, uint16_t tx_num, bool tx_wflag) ← RL78の例

    tx_wflagは MD_WAIT (true) もしくは MD_NOWAIT (false) の何れかです(どちらも案としてです(正直'NOWAIT'がしっくりこない)) 2021/08/15 08:00 変更
    tx_wflagは MD_WAIT_FINISH (true) もしくは MD_DONT_WAIT_FINISH (false) の何れかです(どちらも案ですけれど)

     
    RX231のコード生成を用いた簡易IIC通信について
    japan.renesasrulz.com/cafe_rene/f/002-2095199602/6169/rx231-iic/34171#34171

    TB-RX65N/RX130/RX231+CSplus sample program
    japan.renesasrulz.com/cafe_rene/f/002-2095199602/6870/tb-rx65n-rx130-rx231-csplus-sample-program/36990#36990
     

  • こんにちは。NoMaYです。

    e2 studio 2021-07でLLVM-RL78&C++&RL78スマートコンフィグレータという組み合わせのプロジェクトを試していて気付いたのですけれど、C++側のソースのインクルードパス設定に以下の画面コピーのようにr_bspとr_configのパスが無いですね。しかも、手作業で追加してもコード再生成するとe2 studioが強制的に削除してしまいますね。これには困惑してしまいます。

    問題点:

    (1) C++側のソースのインクルードパス設定にr_bspとr_configのパスが無い
    (2) 手作業で追加してもコード再生成するとe2 studioが強制的に削除してしまう

    以下、e2 studioの画面コピーです。

    C側のソースのインクルードパス設定にはr_bspとr_configのパスが有る


    C++側のソースのインクルードパス設定にはr_bspとr_configのパスが無い

     

  • チョコです。

    RL78/G23で32ビット・インターバル・タイマを2つの16ビット・インターバール・タイマで使うように設定してみました。

    すると、割り込みの設定のところを眺めると、下のようにワーニングが出ています。

    これは、明らかにおかしなメッセージです。

    32ビット・インターバル・タイマの割り込みは1本しか存在しません。1本の割り込みなので、「複数の割り込み機能に対して1つのレジスタ・バンクを指定することはできません。」は何を言っているのか不明な(手抜きの)ワーニングです。

    以上

  • こんにちは。NoMaYです。

    COMPort通信デバッグで monitoring point function というものが使えるようなのですが、これは何なのでしょうか?

    以下、e2 studioのRL78スマートコンフィグレータの画面コピーです。


     

  • こんにちは。NoMaYです。

    LLVM-RL78向けの生成コードですが、DTCを使ったり、あるいはスレッドの最初に書いたオンチップデバッグトレースを使用する場合の予約RAM領域を確保するよう修正された場合の危惧だったりですが、以下のようにリンカスクリプトに、NOLOADが付いていない(或いは何ら対処が行われていない)DTC制御データのエントリを生成したり、もしくはNOLOADが付いていない(或いは何ら対処が行われていない)オンチップデバッグトレースの予約RAM領域のエントリを生成したりするのではないかと気掛かりだったり、します。以前にGNURXの別スレッドでも取り上げましたが、これですとビルドしたSRECファイルをRFPで読むとエラーが発生しますので、案としてはNOLOADを付けるようにして欲しいです。

    現状+危惧:

    .dtc_vectortable 0xffd00 : AT(0xffd00)
        {
            KEEP(*(.dtc_vectortable))
        } >RAM
    .dtc_controldata_0 0xffd40 : AT(0xffd40)
        {
            KEEP(*(.dtc_controldata_0))
        } >RAM

        .ocd_traceram 0xFC300 : AT(0xFC300)
        {
            KEEP(*(.ocd_traceram))
        } >RAM 

     
    より望ましいと思われるもの(案):

    .dtc_vectortable 0xffd00 (NOLOAD) : AT(0xffd00)
        {
            KEEP(*(.dtc_vectortable))
        } >RAM
    .dtc_controldata_0 0xffd40 (NOLOAD) : AT(0xffd40)
        {
            KEEP(*(.dtc_controldata_0))
        } >RAM

        .ocd_traceram 0xFC300 (NOLOAD) : AT(0xFC300)
        {
            KEEP(*(.ocd_traceram))
        } >RAM

     
    以前に取り上げたGNURXの別スレッド

    RX SmartConfiguratorのGNURX向け生成コードのBugではないかと思われる動作について
    apan.renesasrulz.com/cafe_rene/f/forum5/5753/rx-smartconfigurator-gnurx-bug/31907#31907
     

  • チョコさん、NoMaYさん

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

    私の動きが遅くすみません。以下のように全件ピックアップして対処を進めております。

    進捗しましたら適宜報告いたします。

    1. (NoMaYさん): ICCRL78とLLVM-RL78(とGNURL78)でワーニングレベルを上げるとワーニングがとてもたくさん出る
    →BSPでまず対応中です。スマートコンフィグレータで出力できるコード全般についても確認を進めています。
    2. (NoMaYさん): RL78スマートコンフィグレータGUI上でオンチップデバッグトレースを使用する設定にしても予約RAM領域を空けていない
    →対応を進めております。
    3. (チョコさん): RL78のSmartConfiguratorではコンポーネントの割り込みでレジスタ・バンクが指定できるようになりましたが、同じ割り込み優先順位で同じバンクを指定するとワーニングが出ます
    →対応を進めております。
    4. (NoMaYさん): LLVM-RL78(とGNURL78)はC++が使えることをセールスポイントのひとつにしています(と私は認識しています)ので、ゆくゆくは使えるようにした方が良いのではないでしょうか
    →対応を進めております。
    5. (チョコさん): IICのコード生成におけるコールバック関数の呼び出し位置がおかしいのでは?
    →対応を進めております。
    6. (チョコさん): IICのコード生成におけるNACK応答後のコールバックの通知があたかもエラーになったように見受けられるがそれは違うのではないか?
    →対応を進めております。
    7. (チョコさん): 全般的に割り込み周りの処理体系が不完全。ArduinoのようにAPIの内部で完了待ちを行うソフトが幅を利かせてきたので割り込み周りの処理で初級者が混乱を来たしているように思う。なので通信完了後に処理完了待ちを追加してみたらどうか?
    →RL78(含めMCU全般)の標準ソフトウェアアーキテクチャの体系を再定義を試みています。
    8. (チョコさん): SCの「ソフトウェアコンポーネント設定」で「インターバル・タイマ」を選択したときの「動作モード」が「8ビット・カウント・モード」になっているのが奇異
    →本件はSCとしてはデバイス仕様通りの実装なので直せそうにないです。デバイス仕様(あるいはマニュアルの書き方)の面からの改善は図れる可能性があり、その方面で検討を進めます。
    9. (チョコさん): SCでデジタル入出力の端子兼用機能であるアナログ入力(デバイスの初期状態)を初期設定でデジタル入力に設定しようと考えました。PDIDIS0レジスタで該当するビットが1になっていて、確かに設定内容には合っているのですが、違和感を禁じえません。
    →対応を進めております。
    10. (チョコさん): TM07をインターバルタイマに設定した状態で、IIC00を追加したところ、ワーニングが発生しました。これは、どうもSCL00が使用する端子がリダイレクトした場合のTO07とぶつかっているからだと思われます。
    →ルネサスでは再現しませんでした。もう少し詳細議論できれば真因が分かるかもしれません。
    11. (チョコさん): SCが生成した簡易IICの割り込み処理の先頭にコード生成にはなかったソフトウェアタイマによる遅延処理が追加されています。出来れば、ここはハードウェアのタイマを使うことで、CPU時間を解放することをお勧めします。
    →RL78(含めMCU全般)の標準ソフトウェアアーキテクチャの体系を再定義を試みています。
    12. (NoMaYさん): e2 studio 2021-07のRL78スマートコンフィグレータGUI上からBSPモジュールをアップデートしたのですけど、以下の障害が発生しました。
    →対応を進めております。
    13. (NoMaYさん): チョコさん指摘の時間待ちについてUWT(Unlimited Wait Time)をAPIとして準備してBSPで実装してみては、という話。
    →RL78(含めMCU全般)の標準ソフトウェアアーキテクチャの体系を再定義を試みています。
    14. (NoMaYさん): (1) C++側のソースのインクルードパス設定にr_bspとr_configのパスが無い、(2) 手作業で追加してもコード再生成するとe2 studioが強制的に削除してしまう
    →対応を進めております。
    15. (チョコさん): RL78/G23で32ビット・インターバル・タイマを2つの16ビット・インターバール・タイマで使うように設定してみました。すると、割り込みの設定のところを眺めると、下のようにワーニングが出ています。
    →詳細確認中です。
    16. (NoMaYさん): COMPort通信デバッグで monitoring point function というものが使えるようなのですが、これは何なのでしょうか?
    →詳細確認中です。
    17. (NoMaYさん): LLVM-RL78向けの生成コードでリンカスクリプトにNOLOADを付けるべき
    →詳細確認中です。

    文中の「RL78(含めMCU全般)の標準ソフトウェアアーキテクチャの体系を再定義」については次の返信で書き込みます。

    以上です

  • チョコさん、NoMaYさん

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

    「RL78(含めMCU全般)の標準ソフトウェアアーキテクチャの体系を再定義」について現時点で議論中ですがその内容を少しお知らせします。車載向けデバイスの話は除きます。

    まずスマートコンフィグレータが各デバイス向けに標準ソフトウェアを生成しユーザプロジェクトに組み込む流れはどのデバイス(RA、RX、RL78、RZ、REなど)でも同じ流れになってきています。

    生成されるコードは以下2種類に分類されます。

    ①単機能・直列的実装なシステム向け

    ②複数機能・並列的実装なシステム向け

    RXファミリの世界観でいうと①はCG(Code Generator)、②はFIT(Firmware Integration Technology)です。

    ①は従来通りのコード生成機能です。単機能の評価・実装に向きます。各種ソフトウェアはシーケンシャルに動くことが前提となっています。単一の周辺機能のみが動作するシステムの量産に向きます。生成されたコードはパラレルに動くことは考慮されておらず必要に応じてユーザ側でカスタムすることを想定しています。

    ②はFITのように並行で動作することを前提で作られたソフトウェアモジュールです。組み合わせ機能の評価・実装に向きます。様々な周辺機能が同時並行に動作するシステムの量産に向きます。各種ソフトウェアはパラレルに動くことが前提となっておりユーザ側でカスタムせずそのまま量産製品に搭載することを想定しています。(もちろんユーザが好きにカスタムしても良いです)

    従来組み込みシステムやRL78のように元々単機能を実現する目的をカバーするのに向いたデバイスでは①が主体でした。RXではリアルタイムOS活用が多く②のようなソフトウェアが市場から求められておりあとから②を追加しています。RAでは①のタイプはそぎ落とした状態にしました。

    このような形でマイコンファミリ毎に時代を追うごとに少しずつ色が変わっていっています。①から②への変遷ですね。

    スマートコンフィグレータでこのあたりを単一で表現できるように①と②を包含しています。

    テクノロジ先行で上記のような概念的なところが少々置き去りになっていてユーザビリティが低下しているとも感じております。

    RL78においても②の世界観が求められているので、いつしかNoMaYさんが仰っていたようにFITモジュール的なものをRL78向けに用意していきたいと考えています。(実は書き込みをみたときNoMaYさんにシェルティの心の中が読まれたと思って少し戦慄しました)

    手始めにチョコさんが仰っているように、Arduinoに慣れた人にはブロッキングコール、ベアメタルに慣れた人にはノンブロッキングコールが使えるようなAPIをまとめた②のタイプのIICバス制御用のモジュールを作ってみようと考えています。①のタイプに慣れ親しんだ人も多いと思うので①は①で何かより良い手(コード生成の最後に処理完了待ちのビットポーリングのコードを生成する、など)はないか常に考え続けます。

    種々情報を整理し可能な限り分かりやすく、使いやすいツール群を目指していきたいと考えています。

    細かいところで特にまだまだ整備が不十分なところがあると考えており皆様の意見が大変参考になります。

    また色々議論させていただけますと幸いです。

    以上です

  • チョコです。

    対応の検討ありがとうございます。

    >①は従来通りのコード生成機能です。単機能の評価・実装に向きます。各種ソフトウェアはシーケンシャルに動くことが前提となっています。単一の周辺機能のみが動作するシステムの量産に向きます。生成されたコードはパラレルに動くことは考慮されておらず必要に応じてユーザ側でカスタムすることを想定しています。

    それは違うと思います。従来のコード生成から、通信を開始して即APIから戻ってくるのは、通信動作とほかの処理を並行に実行させることがベアメタルの使い方となっているはずです。シーケンシャルに動かすだけであれば、通信の完了までをきちんとケアしているはずです。現状のコードはそこの部分すらきちんとできていない、中途半端なものです。

    ベアメタルとしては、両方を満足するようなコードであるべきだとの考え方には賛成です。

    それと、I2C関係での応用で、単にI2Cバスで定義されたレベルの通信ではなく、さらに1歩踏む込んだスレーブ・デバイスとの共通的な通信プロトコルへの対応も考えていただければと思います。

    具体的には、RL78/G23のIICA0のAPNでは、スレーブが4つの256バイトのRAMになっているので、マスタはスレーブ・アドレス(これで、4つのRAMのどれかを選択)+(RAM内部の)内部アドレスを指定するような使い方になっています。これは、i2Cバスでの一般的なスレーブと同じような通信プロトコルです。このプロトコルでは、書き込みは一連の送信だけで済みますが、読み出しでは、まず、スレーブアドレスと内部アドレスを送信し、その後にリスタートして受信動作を起動してデータを読み出します。(この動作が、コード生成でリスタートが要求された背景です。)

    蛇足かもしれませんが、RL78/G13の改版されたIICA0のAPNでは、スレーブ側にコマンドまで定義しています。最初に、コマンドを送信してスレーブを動作許可にするなどやっています。これは、センサ等のスレーブと同様な通信方法と言えます。

    単純な、通信完了の確認方法をお願いしているうちに、外部の状況はどんどん変わっています。ぜひご検討をお願いします。

    それと、プログラムだけでなく、マニュアルの見直しもよろしくお願いします。

    以上

  • チョコです。

    対応の検討ありがとうございます。

    指摘内容:8. (チョコさん): SCの「ソフトウェアコンポーネント設定」で「インターバル・タイマ」を選択したときの「動作モード」が「8ビット・カウント・モード」になっているのが奇異

    解凍内容:→本件はSCとしてはデバイス仕様通りの実装なので直せそうにないです。デバイス仕様(あるいはマニュアルの書き方)の面からの改善は図れる可能性があり、その方面で検討を進めます。

    どうも、新たに追加された1チャネルだけの「32ビット・インターバル・タイマ」の表記に引きずられてしまっているようです。RL78にはもっと多くのチャネルがあるTAUが存在します。

    ユーザーズマニュアルには、以下のように記載されています。マニュアルはデバイスの仕様書に基づいて書かれているので、「8ビット」に違和感があります。この表記はG13の時代から同じです。8ビットにできるのはチャネル1と3だけで、設定するレジスタのディフォルト値は0で16ビット・タイマとしての動作です。

    指摘内容:10

    こちらでも、新しくやってみたところ再現できませんでしたので、キャンセルします。

    以上

  • こんにちは。NoMaYです。

    たぶん来月にはe2 studio 2021-10が出るとは思いますので、時期的に少し出し遅れたかもとも思いますけど、BSPに同梱されているLLVM-RL78向けstart.Sを更新して欲しいです。以下の画面コピーの通り、BSPに同梱されているものはプロジェクトウィザードで生成されるものより古くて、C++のオブジェクトの初期化処理が古いもののようなのです。

    以下、ファイル比較ツールの画面コピーです。
    (左:BSPに同梱されているもの、右:プロジェクトウィザードで生成されたものに当方でBSPとの暫定結合処置を施したもの)




     

  • NoMaYさん

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

    本件、先日リリースされたBSP rev.1.12start.Sが更新されました。

    rev.1.12のstart.Sにはプロジェクトウィザードで生成される内容を反映しております。

    お手数ですが、個別に最新版をダウンロードいただき、ご使用願います。

    e2 studioに入っているBSPは追って更新する考えです。

    以上です

  • チョコさん

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

    返信が遅くすみません。ご指摘通りと思います。

    ご指摘内容:それは違うと思います。従来のコード生成から、通信を開始して即APIから戻ってくるのは、通信動作とほかの処理を並行に実行させることがベアメタルの使い方となっているはずです。

    少し考え方を変えて、以下方向で再定義を進めています。

    RXファミリの世界観でいうと①はCG(Code Generator)、②はFIT(Firmware Integration Technology)です。

    • ①CG(Code Generator)
      • A/D変換やタイマ制御などデバイス単体で機能実現可能な機能のみを搭載するシステム向け
      • 可読性に優れ、上位層に合わせたカスタマイズが可能
    • ②FIT(Firmware Integration Technology)
      • リアルタイムOSやミドルウェア等、複数のソフトウェアモジュールを結合する必要のあるシステム向け
      • 提供されている形態のまま流用することが可能

    RL78の世界観においてはほぼほぼCGになると思っていますが、製品によってはRTOSを載せたりSDカードドライバとファイルシステムを載せたりPWMから音声出したりなどで、モジュールプログラミングが必要なこともあり、世界の流れとしては確実に②の方向性ではあるので、RL78向けにも②を作っていきたいとうのがシェルティの主張です。ただいま社内の意見整合など進めています。②はノンブロッキング・ブロッキング方式どちらでも動くようにしておき、②の上位にArduinoラッパーを被せることでArduinoユーザが詳細デバッグしたい場合には②の環境提供(あとから①も足せる)ができるようにもしていこうと思っています。

    またいただいたフィードバックについては前の書き込みように一覧にして定期的に報告させていただきます。

    以上です

  • チョコです。

    開発方針のご提示有難うございます。

    気になるのが、①のレベルで済むところに対しても初心者向けでブロッキング方式が必要になってきていることです。

    おそらく、I2CバスやSPIでのセンサ制御程度なら②では重すぎると思いますが。

    従来の非同期式(不完全なノン・ブロッキング式?)についても、きちんとした使用方法を提供できるようにすべきです。というか、マニュアルで、どのような思想で作られたライブラリであるかと、きちんとした使用方法についての指針が必要だと思っています。どうも、現状は、ユーザの考えているところとずれているようです。

    "Arduinoラッパー"ですか、どんなものなのか気になります。RL78/G23用のArduino IDE(これのステータスがどうなるか気になっていますが)との関係も気になります。

    何か気になるとばかり言って申し訳ありません。期待しています。