こんにちは。NoMaYです。別スレッド「RXシュミレータでの最小プログラムの作成について」でRXシミュレータの代わりにMinGWを使うと言う話が出ていましたので、とりあえず、ビルド出来るようにするにはどうすれば良いのだろうか試してみることにしました。まずはMingGWのインストールから。今回、以下を参考にさせて頂きました。私は64bit版をインストールしてみました。[追記] 正確には、MinGW-W64にて、64bitターゲットアーキテクチャを選択したのですが、この選択は不適切でしたので、後日、32bitターゲットアーキテクチャを選択し直しました。gccのインストール(Windows) - 電気通信大学joho.g-edu.uec.ac.jp/joho/gcc_win/続く。
こんにちは。NoMaYです。MinGWをインストールして電気通信大学のウェブページのようにWindowsでPathを設定するとe2 studioがMinGWを認識するようになりますので、手元のRX72N Renesas RX Simulator CC-RX e2 studioプロジェクトを流用してみました。(以下に作業中の画面コピーを幾つか添付しました。) プロジェクトが出来たところでビルドしてみたところ、出だしで以下のエラーになったのですが、よくよく考えてみれば、CC-RXプロジェクトを流用して始めるよりコンパイラとして同系統のGNURXプロジェクトを流用して始めた方がハードルが低い筈であることに気付いて、いったんやり直すことにしました。出だしのエラーの画面コピー続く。以下、作業中の幾つかの画面コピーです。(全ての手順の画面コピーを取ったわけではないので気になる箇所のみです。)MinGWのPathをWindowsで設定するとe2 studioがMinGWを認識してMinGWプロジェクトを作成出来るようになるCC-RXプロジェクトを流用する小技にe2 studioのリンクされたフォルダ機能など諸々使用して隣のプロジェクトのソースを共有途中省略インクルードパスやマクロ定義を設定すれば準備完了(小技ですが.cproject間で設定を手作業でコピペすると楽ちんです)
NoMaYさん
先ほどのスレッドで投稿した者です。自分も64bitなので、正確にはMingw-w64です。
e2 studioでMinGWを使うのは面白いですね。自分はe2 studioではなくVisual Studio Codeを使っています。(コード生成、実機用にビルドするときはe2 studio)なので、ビルドスクリプトを書くところから苦労しました(汗)
RXではなくRL78/H1Dなのですが、OSなしなので実行もできました。OSありだと難しそうですね。
testさん、こんにちは。NoMaYです。実は、FreeRTOSに関してはWindows版があるのですよ。ふっふっふっ。FreeRTOS Windows PortFor Visual Studio or Eclipse and MingWwww.freertos.org/FreeRTOS-Windows-Simulator-Emulator-for-Visual-Studio-and-Eclipse-MingW.htmlまた、思うに、testさんはWindowsのマルチタスクプログラミングにも苦労されたのでは無いかなと思うのですけれども、一案として、Windows上のFreeRTOSのマルチタスクプログラミングで擬似割り込み処理やそこからのコールバック処理を実現することで、幾らかは新規に試行錯誤すること/覚えることを減らすことが出来るかも知れません。(FreeRTOSにある程度慣れていれば、ということですけれど。) (何かFreeRTOSのWindows PortにSimulated Interrupt Service Routinesなるものがあるけれども何だろう、、、)とはいえ、そういったことを、スーパーループプログラムをWindows上で動作させてみることの実装上のいち手法としている限りは頭が混乱することは少ないように思いますが、RTOSを既に使っているプログラムで同じように実装上の手法としてもRTOSを使おうとすると、なんか頭がこんがらがって来そうな気がしなくもないですね。(という文面で伝わるかどうかちょっと怪しいかとも思いますけれど。)あと、RXスマートコンフィグレータで且つFITだけ使っている限りにおいては、レジスタの動作をシミュレーションするという手法の他に、FITのAPIレベルでごっそり置き換えてしまうという手法も考えられます。今の私は、そちらの方が簡単ではないかなぁ、と思っていたりします。例えば以下のようにです。(testさんはRL78とのことでしたけれども。)(1) FITのBSP → 丸ごとビルドから除外ごく単純にはWinMain()からmain()を呼ぶ(FreeRTOSであればFITのProcessing_Before_Start_Kernel()周りを真似る)(2) その他のFITモジュール → [追記] これも丸ごとビルドから除外かな必要なモジュールに関してFITのAPIレベルでWindows上で動きを真似するプログラムを自作する対向テストベンチとの接続処理なども含むことになると思うコールバック処理は上に書いた実装上の手法としてFreeRTOSのタイマタスクとかからコールバック関数を呼ぶとか(WindowsのFreeRTOSの機能を駆使しても良いとは思うけれどやりすぎると頭がこんがらないかちょっと心配)(3) アセンブラを含まないユーザー処理ANSI/ISOに従ってプログラムを書いていればそのままビルド出来る筈(意味合いは微妙ですが”動く”筈でもある)内蔵周辺レジスタを操作するコードは上記(1)と(2)で全て取り除かれている筈(でもきっと直接ポート入出力はやってるかな)(4) アセンブラを含むユーザー処理これはCで書き換えて代替処理を作らないと駄目かな他方、ちょっと方向性の違うやり方として、以下のような方法も考えられるようにも思います。(実質的には同じ?)(A) マイコン内蔵周辺レジスタ依存のソースと非依存のソースでフォルダを綺麗に分ける(B) 以下のスレッドのe2 studioのリンクされたフォルダの機能などを使って非依存ソースだけをMinGWプロジェクトに取り込む(C) FITだけ使っていれば、後は、上記(2)と同様にFIT APIとAPIレベルで同じように見えるものをWindowsで作るe2studioにおけるライブラリの作成についてjapan.renesasrulz.com/cafe_rene/f/forum21/7222/e2studio/38502#38502
iTRONを使うことが多かったのですが、FreeRTOSかなりよさそうですね。iTRONはこういう便利機能が不十分な印象です。(今は違うのかな?)
> testさんはWindowsのマルチタスクプログラミングにも苦労されたのでは無いかなと思うのですけれども
まさにその通りでして、main関数が割り込み処理よりも先に動くから調べてみたらmain関数が別のCPUコアで動いていた...とかおかげでWindowsにもだいぶ詳しくなりました(苦笑)
> あと、RXスマートコンフィグレータで且つFITだけ使っている限りにおいては、> レジスタの動作をシミュレーションするという手法の他に、FITのAPIレベルでごっそり置き換えてしまうという手法も考えられます。
FITはよくわかっていませんが、自分もコード生成のドライバ(R_UART0_Start等)を置き換える形ですね。ただ、レジスタの値は見たいので、完全に入れ替えるのではなく必要な箇所だけWindowsの処理を追加しています。R_UART0_Startで割り込みマスクと割り込み要求フラグがクリアされるといったところはそのまま動いてほしいですしポートに関しても、対向はRL78のポートレジスタの値を監視するという形になっています。
Visual Studio Codeでビルドするときは入れ替えた方のフォルダでe2 studioでビルドするときは正規のフォルダで、アプリケーションはそのまま、ドライバを入れ替えたらWindowsにもRL78にもなるという形にしています。なので、
> 他方、ちょっと方向性の違うやり方として、以下のような方法も考えられるようにも思います。(実質的には同じ?)
こちらのやり方とも言えます。
昔RXを使ったときはFITなんてあったかな...そもそもHEWだった気がしますが、最近の進化は驚くばかりです。
testさん、こんにちは。NoMaYです。確かに、割り込みフラグ関連の操作/動作は同じにしておきたい、というのはありますかね。その一方、FITでは、以下のスレッドに書いた個人的見解のように、そういうものも含めて内蔵周辺レジスタの操作/動作を丸々隠蔽するという方向で設計されていますので、FIT視点だとそういうことは余り気にならなくなって、それ故に、よりいっそう実装し易くなる傾向にあるかなぁ(ハードルが下がる、というか、そもそもの目指すところの目標レベルが下がる、というべきか)、とも思い始めています。API関数japan.renesasrulz.com/cafe_rene/f/forum5/6780/api「ただ、(私の思い込みかも知れませんけど)以下の太字部分の好き嫌いで使い分けられているのではないかなぁ、という気がしています。以下、引用+αです。> Smart Configurator と FIT という言葉の使い分け方がまだ良く分かっていませんが他に、CGという言葉も出てきますよ。単純に書くと、こんな感じですかね。Smart Configurator = CG(コード生成) + FIT(Firmware Integration Technology) + αFITを先に見つけた人にとって分かり難いだろうと思うのは以下の点ではないかと思います。・ マイコンのベーシックな機能の操作に関してCGとFITで役割が重複するコンポーネントがある・ (高度な機能を操作するようなミドルウェアと呼ばれるものに関してはFITのみで提供される)・ Smart Configuratorでは役割が重複する一部のFITに関してはデフォルト設定で非表示にしている(GPIOもそうです)CGとFITには(私の印象では)以下のような差異がありますので、一部のFITを非表示にするまでも無いと思ったりすることもありますが、現状、デフォルト設定がそうなっていますので、必要に応じてその設定を解除すれば良いと思います。CGのメリット・GUIによるドライバ設定を直感的だと好む人には有難い・マイコン内蔵周辺レジスタ操作コードが剥き出しのマイコン感溢れるソースコードを好む人には有難い・機能が少ないマイコンではコードサイズが小さい(と思う)・処理が軽いCGのデメリット・マイコンを変更する時に面倒(GUI上でマイコン型番変更をして必要に応じて入力し直すのが面倒)FITのメリット・GUIによるドライバ設定を面倒臭いと嫌う人には有難い・マイコン内蔵周辺レジスタ操作コードを隠蔽してくれるライブラリAPIを使うことを好む人には有難い・マイコンを変更するときにやや楽(設定の大半はソース上なのでGUI上で入力し直すのは僅か)FITのデメリット・機能が少ないマイコンではコードサイズはCGより大きくなる(と思う)・CGよりは処理が重いFITのメリット(番外編)・最近のFITは対応マイコンを絞り込んだのでCGとの差は無いですが少し前のFITは殆どのRXマイコンに対応していた。(たぶん、それらは今もダウンロード出来ると思う。ただし、RXスマートコンフィグレータ未対応ですが。)」
NoMaYさん、testさん
こんにちはシェルティです。ルネサスの中の人です。
NoMaYさん、いつもスマートコンフィグレータやFIT/CGの考え方をまとめていただき感謝です。まったくもって書いていただいた通りです。
昨今FIT周り含めAmazon FreeRTOSやAzure RTOSの環境を合わせて整備しており、ツールでダウンロードできるコードの出所を徐々にGitHubに移していってます。それに伴い、過去あった制限(FreeRTOS環境だとCGの使用を禁止していた)を取り払う方向で種々対応を進めております。
testさん、まだまだ過去経緯があり制限がかかったままになっていて使いづらかったりするところが残っていると思いますので適宜ご意見ください。ツール仕様に反映していきたいと考えています。引き続きご支援いただけますと幸いです。
以上です
NoMaYさん、こんにちは。
実際にあったのが、割り込みが入らない→よく見ると割り込みマスクがセットされている→変なところからR_XXX_Stopしていた恥ずかしながら、こういう不具合を机上で見つけられたのがよかったです。まあ隠蔽度が大きいFITの方が、実機の動作と合わせやすい(デバッグも楽になる)かもしれないですね。
API関数、低レベルな操作(レジスタを隠蔽するだけ)のものは、CGにも対応する関数があってどちらを使えばいいの??という感じでしょうか。一見同じ内容に見える関数が複数あって、不安になるのはよくある話ですね。
FITのメリットでマイコンを変更するときに楽、というのはPOSIXに似てるかなと思いました。OSによっては、独自のシステムコール上にPOSIXレイヤーをつくってLinuxのアプリケーションが(ある程度は)そのまま動くのを謳っているものもありますがそんな感じなのかなという気がしました。そのためのオーバーヘッドを嫌う人は、システムコールを直接使えばいいということで。
ちなみに、自分はマイコン感あふれるのが好きですが、CGには感動しています。過去に、簡単にツールをつくってコード生成やってみたんですがなかなかプロジェクトをまたいでの活用ができず、報われない感が強かったのでこんなのが欲しかったんだという気持ちです。
シェルティさん
お世話になります。
Visual Studio Codeの拡張機能をつくってほしい実機のビルド、デバッグもこちらでやりたいと言うとぶん殴られそうですが...
おっしゃるような制限ではないのですが、個人的に不便に感じたのが、
・コード生成の出力フォルダ名を変更できないアプリケーションとCGのフォルダを分けたいのですがCGの出力フォルダ名が"src"固定のようなので手でsrc→driverとリネームしています。(app,srcというフォルダ構成だと違和感を感じるので)
・CGを再生成すると、すべてのファイルのCreation Dateが変更される* Description : This file implements device driver for SAU module.* Creation Date: 2021/05/19 ←この部分すべてのファイルに変更マークが付くので、Gitにコミットする際に戸惑います。(TortoiseGitを使っています)SAUの設定変更ならSAUのファイルだけ再生成というようにしてほしい...
運用の仕方がよくないのかなとも思いますが、こんな風に思う人もいるということで小耳に入れていただければ。
> CGを再生成すると、すべてのファイルのCreation Dateが変更される日付の出力を無効にする設定がどこかにあった気が。
ほやさん
ありがとうございます!設定ありますね。お恥ずかしい...