こんにちは。NoMaYです。いま2つ気になっています。(1) ICCRL78とLLVM-RL78(とGNURL78)でワーニングレベルを上げるとワーニングがとてもたくさん出る(2) RL78スマートコンフィグレータGUI上でオンチップデバッグトレースを使用する設定にしても予約RAM領域を空けていない
こんにちは。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の「ソフトウェアコンポーネント設定」で「インターバル・タイマ」を選択したときの「動作モード」が「８ビット・カウント・モード」になっているのが奇異 →本件は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全般)の標準ソフトウェアアーキテクチャの体系を再定義」については次の返信で書き込みます。
以上です
シェルティですこんにちは。
「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の「ソフトウェアコンポーネント設定」で「インターバル・タイマ」を選択したときの「動作モード」が「８ビット・カウント・モード」になっているのが奇異
解凍内容：→本件はSCとしてはデバイス仕様通りの実装なので直せそうにないです。デバイス仕様（あるいはマニュアルの書き方）の面からの改善は図れる可能性があり、その方面で検討を進めます。
どうも、新たに追加された1チャネルだけの「32ビット・インターバル・タイマ」の表記に引きずられてしまっているようです。RL78にはもっと多くのチャネルがあるTAUが存在します。
ユーザーズマニュアルには、以下のように記載されています。マニュアルはデバイスの仕様書に基づいて書かれているので、「８ビット」に違和感があります。この表記はG13の時代から同じです。８ビットにできるのはチャネル1と3だけで、設定するレジスタのディフォルト値は0で16ビット・タイマとしての動作です。
指摘内容：10
こちらでも、新しくやってみたところ再現できませんでしたので、キャンセルします。
こんにちは。NoMaYです。たぶん来月にはe2 studio 2021-10が出るとは思いますので、時期的に少し出し遅れたかもとも思いますけど、BSPに同梱されているLLVM-RL78向けstart.Sを更新して欲しいです。以下の画面コピーの通り、BSPに同梱されているものはプロジェクトウィザードで生成されるものより古くて、C++のオブジェクトの初期化処理が古いもののようなのです。以下、ファイル比較ツールの画面コピーです。(左:BSPに同梱されているもの、右:プロジェクトウィザードで生成されたものに当方でBSPとの暫定結合処置を施したもの)
NoMaYさん
こんにちはシェルティです。
本件、先日リリースされたBSP rev.1.12でstart.Sが更新されました。
rev.1.12のstart.Sにはプロジェクトウィザードで生成される内容を反映しております。
お手数ですが、個別に最新版をダウンロードいただき、ご使用願います。
e2 studioに入っているBSPは追って更新する考えです。
チョコさん
返信が遅くすみません。ご指摘通りと思います。
ご指摘内容：それは違うと思います。従来のコード生成から、通信を開始して即APIから戻ってくるのは、通信動作とほかの処理を並行に実行させることがベアメタルの使い方となっているはずです。
少し考え方を変えて、以下方向で再定義を進めています。
RL78の世界観においてはほぼほぼCGになると思っていますが、製品によってはRTOSを載せたりSDカードドライバとファイルシステムを載せたりPWMから音声出したりなどで、モジュールプログラミングが必要なこともあり、世界の流れとしては確実に②の方向性ではあるので、RL78向けにも②を作っていきたいとうのがシェルティの主張です。ただいま社内の意見整合など進めています。②はノンブロッキング・ブロッキング方式どちらでも動くようにしておき、②の上位にArduinoラッパーを被せることでArduinoユーザが詳細デバッグしたい場合には②の環境提供（あとから①も足せる）ができるようにもしていこうと思っています。
またいただいたフィードバックについては前の書き込みように一覧にして定期的に報告させていただきます。
開発方針のご提示有難うございます。
気になるのが、①のレベルで済むところに対しても初心者向けでブロッキング方式が必要になってきていることです。
おそらく、I2CバスやSPIでのセンサ制御程度なら②では重すぎると思いますが。
従来の非同期式（不完全なノン・ブロッキング式？）についても、きちんとした使用方法を提供できるようにすべきです。というか、マニュアルで、どのような思想で作られたライブラリであるかと、きちんとした使用方法についての指針が必要だと思っています。どうも、現状は、ユーザの考えているところとずれているようです。
"Arduinoラッパー"ですか、どんなものなのか気になります。RL78/G23用のArduino IDE（これのステータスがどうなるか気になっていますが）との関係も気になります。
何か気になるとばかり言って申し訳ありません。期待しています。