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

こんにちは。NoMaYです。

過去にも同じようなスレッドを立てていましたが、CC-RXとGNURXで2つ立てていて、スレッドを使い分けるのも少し不便な気がしましたので、両者を区別せず投稿するスレッドを立ててみました。(e2 studioのプラグイン版もCS+の単体版もいっしょくたです。)

CS+でTB-RX140を使おうとして、単体RXスマートコンフィグレータ V2.10.0では未対応だったことに気付き、アップデートマネージャを起動してみたところ、V2.11.0がリリースされていましたのでアップデートしました。V2.11.0を触っていて気付いたのですが、CGコンポーネントのコードを再生成させた時、変更の無いソースファイルは再生成されなくなり、ファイルのタイムスタンプが変わらないようになっていました。

この挙動が設計意図なのか何かの拍子にそうなってしまっただけなのかは分からないのですが、再コンパイルする時間の短縮になるかも!と思ったのも束の間、以下の2つのファイルが変更が無くても毎回再生成されるので、思惑通りにはならないことに気付きました、、、以下の2つのファイルに関しても同様に変更の無い場合にはファイルを再生成しないように出来ないものでしょうか、、、

(1) platform.h (実は何故このファイルがコード再生成時に毎回タイプスタンプが更新されるのか不思議です)
(2) r_bsp_config.h (RX140の場合このファイルだけですがRX671とかの場合はr_bsp_interrupt_config.hもかもです)

[余談]

以下のニュース記事を読んでいて以下の解説に気付きました。ルネサスさんの取締役の人たちはソフトウェア開発ツールも含んで話をされていたのかな、、、まあ、過去形では無くて永遠に現在進行形であるべきテーマですね。(もっとも、Automotive部門の人の話だったようですけれども、、、)

新しい方向性を見出して走り出したルネサス、Progress Updateから見えたもの
2021/10/01 16:37 著者:大原雄介
news.mynavi.jp/article/20211001-1988188/

さてそのIIBUの大きな柱がMCUであることは論を待たないが、2025年までに大幅にシェアを引き上げる、としている(Photo19)。
。。。
これについては、後のAutomotive向けの質疑応答の中で出てきた話ではあるのだが、そもそもルネサスのMCUが使われなかったのは、1つは「良いかもしれないけど使いにくい」という部分があり、こうした部分を徹底的に改善した事で顧客に使って貰いやすくなったという回答があり、これはIIBUにもおそらく共通する話であろうかと思う。

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

    かふぇルネの話題からですけれども、RXスマートコンフィグレータのGUI上で設定した入力に対して、RXスマートコンフィグレータが生成したヘッダファイル内での#defineのシンボル名の付け方がC言語での一般的な慣行とは異なり、シンボル名にシンボルの値自体が名前の一部として含まれるようになっていて、ユーザ記述部などにてシンボルの値を参照したい(その心はGUI上で設定された入力を知りたい)と考えた時に、#defineのシンボル名が利用出来ない、というのがありました。

    スマート・コンフィグレータ要望 生成マクロ名
    community-ja.renesas.com/cafe_rene/forums-groups/tools/f/forum21/9765/thread

    概念的には以下のようなことです。(あくまで概念としてですけれども。)

    RXスマートコンフィグレータが生成したヘッダファイル内での#defineのシンボル名の付け方:

    #define _9600_UART_CH1_BAUDRATE 9600 ← 9600という部分は2箇所ともRXスマートコンフィグレータのGUI上で設定した入力に応じて変わる

     
    C言語での一般的な慣行:

    #define UART_CH1_BAUDRATE 9600 ← C言語の「.cファイルは出来るだけ変更せずに、.hファイルでカスタマイズする」という慣行です

     
    ユーザ記述部などにてシンボル名を参照したい(その心はGUI上で設定した入力を知りたい)場合:

    例) 通信速度に応じて何かの待ち時間を調整する、といったようなことなどをユーザ記述部などにて、汎用的に記述したい
    例) ストップビット数やパリティビット有無なども考慮して何かの待ち時間を調整する、とったようなこともあるかも知れない

    もちろん、応急処置的には、設定値が格納されている内蔵周辺I/Oレジスタを読み出せば良いわけですけれども、そんな話では無い、ということかと思います。(推測ですけれども、スマートコンフィグレータの前身のコード生成機能のお目見えの頃の大昔まで遡ると、当時、それまでマイコンのハードウェアマニュアルを元にコードを書いていた多くの人達にとっては、内蔵周辺I/Oレジスタに書き込まれる値がパッと見で分かるようになっている方が良かった、だからそうして欲しいという要望があった、のではないのかなぁ、と思ったりしますけれども。そしてまた、多くの人達にとっては、C言語での一般的な慣行なども、ピンと来ていなかったのかなぁ、とも。)

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

    かふぇルネの話題からですけれども、RXスマートコンフィグレータのGUI上で設定した入力に対して、RXスマートコンフィグレータが生成したヘッダファイル内での#defineのシンボル名の付け方がC言語での一般的な慣行とは異なり、シンボル名にシンボルの値自体が名前の一部として含まれるようになっていて、ユーザ記述部などにてシンボルの値を参照したい(その心はGUI上で設定された入力を知りたい)と考えた時に、#defineのシンボル名が利用出来ない、というのがありました。

    スマート・コンフィグレータ要望 生成マクロ名
    community-ja.renesas.com/cafe_rene/forums-groups/tools/f/forum21/9765/thread

    概念的には以下のようなことです。(あくまで概念としてですけれども。)

    RXスマートコンフィグレータが生成したヘッダファイル内での#defineのシンボル名の付け方:

    #define _9600_UART_CH1_BAUDRATE 9600 ← 9600という部分は2箇所ともRXスマートコンフィグレータのGUI上で設定した入力に応じて変わる

     
    C言語での一般的な慣行:

    #define UART_CH1_BAUDRATE 9600 ← C言語の「.cファイルは出来るだけ変更せずに、.hファイルでカスタマイズする」という慣行です

     
    ユーザ記述部などにてシンボル名を参照したい(その心はGUI上で設定した入力を知りたい)場合:

    例) 通信速度に応じて何かの待ち時間を調整する、といったようなことなどをユーザ記述部などにて、汎用的に記述したい
    例) ストップビット数やパリティビット有無なども考慮して何かの待ち時間を調整する、とったようなこともあるかも知れない

    もちろん、応急処置的には、設定値が格納されている内蔵周辺I/Oレジスタを読み出せば良いわけですけれども、そんな話では無い、ということかと思います。(推測ですけれども、スマートコンフィグレータの前身のコード生成機能のお目見えの頃の大昔まで遡ると、当時、それまでマイコンのハードウェアマニュアルを元にコードを書いていた多くの人達にとっては、内蔵周辺I/Oレジスタに書き込まれる値がパッと見で分かるようになっている方が良かった、だからそうして欲しいという要望があった、のではないのかなぁ、と思ったりしますけれども。そしてまた、多くの人達にとっては、C言語での一般的な慣行なども、ピンと来ていなかったのかなぁ、とも。)

Children
No Data