こんにちは。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にもおそらく共通する話であろうかと思う。」
ツチノコさん、こんにちは。NoMaYです。＞ ビルドエラーが発生するのはT4のライブラリ（r_t4_rx/make_lib/make_lib.zip の中にライブラリソースと作成用プロジェクトが入っています）を自前で作成する時です。そういうことでしたか。週末にでもビルドして試してみようと思います。リプライどうもありがとうございました。
こんにちは。NoMaYです。最近、以下のスレッドに関わっているのですが、トラブルの連鎖の原因の根っこは分かっていないのですけれども、RXスマートコンフィグレータ上で以下のようなことが分かるようになっていたらどうだろうかと思いました。(1) 未サポートの新しいRX Driver Packageをダウンロードしようとしたらダウンロード前に未サポートであることが分かる(特定のバージョン以上のRXスマートコンフィグレータが必要であることが分かる)補足) 最近のBSPモジュールは特定のバージョン以上のRXスマートコンフィグレータでなければ使えないものがある(2) プロジェクトに追加しようとしたFITモジュールが未サポートならば(特定のバージョン以上のRXスマートコンフィグレータが必要ならば)追加前にそのことを知ることが出来る補足) BSPモジュール以外にそのようなFITモジュールがあるか分かりませんけれども。(現在は無くとも将来出てくるかも。)関わっているスレッド(トラブルの内容を細分化出来ていないせいで分かりにくいタイトルになっていますが):CC-RXからGCCへの移行後の警告についてjapan.renesasrulz.com/cafe_rene/forums-groups/beginners/f/002-2095199602/9511/cc-rx-gcc
ツチノコさん、こんにちは。NoMaYです。＞ ビルドエラーが発生するのはT4のライブラリ（r_t4_rx/make_lib/make_lib.zip の中にライブラリソースと作成用プロジェクトが入っています）を自前で作成する時です。あれこれ試してみて気付いたのですが、以下の投稿の通り、コンパイルオプションを-std=gnu99→c99へと変更することでビルドエラーを解消出来ました。(GCC for Renesas 8.3.0.202202-GNURXを使いました。) T4のライブラリをビルドするe2 studioプロジェクト設定のデフォルトを変更するのが良いと思うのです。Renesas TCP/IP stack T4 (libT4_XXXX.a)を最近のnewer GNURXでbuildする対処法を探してみたjapan.renesasrulz.com/cafe_rene/forums-groups/tools/f/forum21/9499/renesas-tcp-ip-stack-t4-libt4_xxxx-a-newer-gnurx-build/46544#46544
こんにちは。NoMaYです。かふぇルネの話題からですけれども、EXDMAを扱うものがFITモジュールにもCGコンポーネントにも無かったです。(RX SmartConfigurator V2.15.0＋RX Driver Package V1.36にて見てみました。)RXのEXDMAについてcommunity-ja.renesas.com/cafe_rene/forums-groups/tools/f/forum21/9602/rx-exdma[メモ]FAQ 1000611 : DMACAを外部⇔外部で使用する場合、EXDMACとの違いは何ですか？ja-support.renesas.com/knowledgeBase/17794935
こんにちは。NoMaYです。かふぇルネの話題からですけれども、FITのSCIモジュールでのUART通信ですが、受信をリングバッファで、送信をDMA/DTCで、という使い方をしたくても出来ないです。(RX SmartConfigurator V2.15.0＋RX Driver Package V1.36にてドキュメントを見てみました。)SCI 非同期通信設定でのDMACAについてcommunity-ja.renesas.com/cafe_rene/forums-groups/mcu-mpu/rx/f/forum5/8456/sci-dmaca[追記]むしろ、FITのSCIモジュール側ではリングバッファもDMA/DTCも使わない設定にして、コールバック関数内とかで自前で受信リングバッファを使ったり、送信前に裏技的にDMA/DTCを併用する設定を自前で行ったり、そういったことをやれば、出来なくも無いのかな、、、
こんにちは。NoMaYです。最近、以下のスレッドに関わったのですが、RX Driver PackageのFITモジュールでGNURX対応が済んでいないものとして何が残っているのか、ちょっと気になったので確認してみました。(RXスマートコンフィグレータ自体の話では無いのですけれども。)仮想EEPROMについてcommunity-ja.renesas.com/cafe_rene/forums-groups/beginners/f/002-2095199602/9578/eeprom以下、確認した資料です。(すみません、コンパイラ対応リストがGCC/IAR一緒くたですね。後で個別に見ます。)アプリケーションノート RXファミリ RX Driver Package Ver.1.36R01AN6515JJ0136 Rev.1.36 Pages 12 Jul.26.22www.renesas.com/jp/ja/document/apn/rx-family-rx-driver-package-ver136GNURX/ICCRX未対応のもの(制限付きのものも(どこで制限が発生するんだろう、、、))
IrDAインタフェース(IrDA)
r_irda_sci_rx
1.01
未対応
Δ-Σ モジュールタインタフェース(DSMIF)
r_dsmif_rx
1.00
制限付き
BLEモジュール(BLE)
r_ble_rx23w
2.40
RYZ012 Bluetooth Low Energyモジュール
r_ryz012_rx
QE Utilityモジュール(Profile)
r_ble_qe_utility
1.10
メッシュモジュール(Mesh)
r_mesh_rx23w
1.20
RYZ014A Cellular モジュール
r_cellular
1.06
フラッシュメモリデータ管理モジュール(DATFRX)
r_datfrx_rx
2.01
JPEGデコーダモジュール
r_jpegd_rx
2.06
JPEGエンコーダモジュール
r_jpege_rx
音声録音・再生システム(独自ADPCMコーデック)
r_s2_rx
3.04
ファームウェアアップデート モジュール
r_fwup
1.04
Aeropoint モジュール
r_aeropoint_rx
emWin v.6.22モジュール(EMWIN)
r_emwin_rx
未対応←間違い？
こんにちは。NoMaYです。先日のRX Driver PackageのFITモジュールでGNURX対応が済んでいないものの確認作業の残りですが、アプリケーションノートで「制限付き」と表記されていた箇所はGCC/IARの片方しか対応していないことを示していたようです。(それと、アプリケーションノートに誤記もありますね。あと、FITモジュールリストのxlsxファイルにも誤記がありそうです。)
・対象: RX113、RX230、RX231、RX23W、但し、CC-RXでも、RX113のみ対応・状況: GNURX未対応、ICCRX未対応、ソース上に #pragma interrupt の記述あり
・対象: RX72M・状況: GNURX対応済み、ICCRX未対応、ソース上はコンパイラ依存性は無いか解消済みの筈(なぜならGNURX対応済みなのだから)
・対象: RX23W・状況: GNURX未対応、ICCRX対応済み、バイナリライブラリを必要とするがGNURX版のバイナリライブラリは無い
・対象: 全て、但し、CC-RXでも、RX65Nのみ対応・状況: GNURX未対応、ICCRX未対応、ソース上はICCRXには対応してるかも、GNURXではRAマイコンのFSPの条件コンパイルに行くッポイ
・補足: BLEモジュール(BLE)に依存
・対象: 全て？、FITモジュールリストのxlsxファイルに誤記あり？・状況: GNURX対応済み、ICCRX未対応、ソース上はコンパイラ依存性は無いか解消済みの筈(なぜならGNURX対応済みなのだから)
・対象: 全て・状況: GNURX未対応、ICCRX未対応、ソース上に #pragma section の記述あり
・対象: 全て・状況: GNURX未対応、ICCRX未対応、ソース上に #pragma section や エンディアン指定CC-RX固有マクロ の記述あり・補足: バイナリライブラリのビルド環境がCC-RX＋HEWとなっていてCC-RX向けのバイナリライブラリのみ
・対象: 全て・状況: GNURX未対応、ICCRX未対応、アセンブラ記述ソースあり
未対応←誤記
・対象: 全て、但し、未対応デバイスあり・状況: GNURX対応済み、ICCRX対応済み
・対象: RX651、RX65N、RX66N？、RX72M？、RX72N、FITモジュールリストのxlsxファイルに誤記あり？・状況: GNURX未対応、ICCRX未対応、バイナリライブラリを必要とするがGNURX版/ICCRX版のバイナリライブラリは無い
・対象: RX651、RX65N、RX66N？、RX72M？、RX72N、FITモジュールリストのxlsxファイルに誤記あり？・状況: GNURX対応済み、ICCRX対応済み・補足: emWin v.6.26モジュールが出ています(シリアル接続LCDはRXマイコン全品種対応のようです)
こんにちは。NoMaYです。RXスマートコンフィグレータ自体の話では無いのですけれども、最近、以下のスレッドに関わったのですが、FITのR_SCI_RXモジュールのDMA/DTCのサポートに関して以下のことに気付きました。(DMA/DTCのサポートは、割と最近追加された機能だと記憶しています。)DMACAを利用したSCI 非同期通信で、２回目の受信ができませんcommunity-ja.renesas.com/cafe_rene/forums-groups/mcu-mpu/rx/f/forum5/9761/dmaca-sci-2気付いたこと:(1) DMA/DTCを使った場合にR_SCI_Control()では送信完了や受信完了を知る方法が無い・ 一応、SCI_CMD_CHECK_XFER_DONEという転送完了をチェックするコマンドはあるけれどもUARTでは使えない。・ もちろん、確かに、コールバック関数でのイベント判定で転送完了をチェックすることは出来るけれども、RL78のコード生成機能の過去10年程の事例から(チョコさんの過去の回答の事例から)推測されることとして、コールバック関数内でフラグを立て、スーパーループでフラグをチェックする、というやり方が思い浮かばないユーザさんがそれなりにいらっしゃるように見受けられます。・ 他方で、通常の(DMA/DTCを使わない)UART受信では、SCI_CMD_RX_Q_BYTES_AVAIL_TO_READコマンドで受信完了(というのは適切な表現では無いとは思いますが)を知ることが出来ますけれども、それとのバランスが良くないように思いました。・ もっとも、通常の(DMA/DTCを使わない)UART送信では、もともとコールバック関数を使わなければ送信完了を知ることは出来ないものである、ということもありますので、先程の「バランスが良くないように」というのは過度に話を広げてしまっているかも、とも思ってはいます。(2) UARTのDMA受信の場合に2回目のR_SCI_Receive()呼び出しで謎のエラーが返る・ 上のスレッドで気付いたこととして、R_SCI_RXモジュールのUARTのDMA受信のコードにバグがある、と思われます。詳細も上のスレッドに投稿されています。[追記](3) 一旦受信完了してから、次に受信動作を開始するまでの間に、もしもデータが来てしまった場合の動作は？・ 無視するか、何らかのエラーとするか、になるとは思いますが、少なくとも以後の受信が全く出来なくなる、というのは避ける必要がありそうだと思いました。・ 過去、RL78で、DTCを使用した受信を試していた時、内蔵周辺機能の事情もあったかも知れませんが(かなり忘れていますので)、まさにDTCをイネーブルする直前にデータが来てしまったような場合の対処で悩んだ記憶があります。(そのデータ受信による意図しない単体受信割り込みと正規のDTC受信完了割り込みを区別することが悩ましかったような記憶があります。)・ 通常の(DMA/DTCを使わない)UART受信でも、リングバッファを使用しない場合は、同様の状況がありそうですけれども、そこは調べて無いです。
こんにちは。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言語での一般的な慣行なども、ピンと来ていなかったのかなぁ、とも。)
こんにちは。NoMaYです。かふぇルネの話題からですけれども、多重割り込みに関して要望が再度ありました。なお、私は、この時に知りましたけれども、Cortex-MマイコンはCPUアーキテクチャレベルで多重割り込みを許可した状態で割り込みを受け付けていくアーキテクチャのようです。そして、ちょっと思ったのですけれども、RXマイコンは割り込み応答性というもの関して業界から10年遅れてしまった(マイコンファームウェア開発フレームワークの事情も込みで)、みたいなものなのかなぁ、と。スマート・コンフィグレータ要望 多重割込community-ja.renesas.com/cafe_rene/forums-groups/tools/f/forum21/7578/thread/47498#47498応急処置的には、たまたま別の案件のスレッドにおいて投稿している小細工などもありますけれども、そんな話では無い、ということになるのだろうなと思います。