お世話になります。
RXコンパイラcc-rxにおいてプリプロセッサ命令には下記のような物はないと認識したので宜しいですよね?
これらはGCCの場合に有効なプリプロセッサ命令ですよね。
DTERMFCN=1 -DONESTEPFCN=1 -DMAT_FILE=0 -DMULTI_INSTANCE_CODE=0 -DINTEGER_CODE=0 -DMT=0 -DCLASSIC_INTERFACE=0 -DALLOCATIONFCN=0 -DTID01EQ=0 -DMODEL=NassFCM -DNUMST=1 -DNCSTATES=0 -DHAVESTDIO
マイコンの変更に伴うコード移植をしております。前マイコンはTIのRM46 ARM系出会ったため、GCCでした。
どうぞ宜しくお願いします。
NoMaYさん、ほやさん
コメント有難うございます。ご推察の通りMathworks社のSimulink,Matlab,EmbddedCorderを利用して、ブロックからC原語を出力し、Makeファイルを作製して実行ファイルを作成しようとしている段階です。これまでTIマイコンでしたが、ルネサス製マイコンへのリプレースを試みています。
この過程においてmakeファイルを作成するのですが、EmbeddedCorderがーDではじまるオプションを呼び出すため、CC-RXがーDを認識できず、今回の質問?となりました。
ただ、TIマイコンでのコンパイラは-Dオプションを認識していたのでした。
どなたかMathworks社のEmbeddedCoderを利用してRXマイコンの実行ファイルを作製している方をご存知ないでしょうか。
経験をお借りしたく。。。。
とっさん さん、こんにちは。NoMaYです。> EmbeddedCorderがーDではじまるオプションを呼び出すこの部分の意味が分からないです。というか、コンパイラが異なればオプションの指定方法が異なるのは普通の事態ですので、どういう経緯で-Dオプション(GNUARM)とほやさん指摘の-defineオプション(CC-RX)の違いの件がクローズアップされているのか分からないのです。自分が想像出来るのは、MATLABでソースコードと一緒にmakefileも生成されるけれども、そのmakefileがGNUARM用になっているのをCC-RX用に書き換えようとしている、ところまでしか想像出来ないのです。すみません。それでも、一般的にはそのような場合は以下の何れかの対処をするものだと思うのです、、、(1) makefileを手作業で書き換える。もし、生成される度に差異が生じるのであれば、毎回書き換える(2) 毎回書き換えるのが煩雑で、且つ、スキルがあれば、何らかのスクリプト言語で書き換えを自動化するスクリプト言語としては、Linuxであれば古典的にはsed,awk,perlなどがあり現代的にはruby,pythonなどかと思いますし、WindowsであればVBSscript,JScript,PowerShellとかだと思うのです。[追記]Embedded Coder組込みシステム用に最適化された C コードと C++ コードの生成jp.mathworks.com/products/embedded-coder.htmlGoogle検索: Embedded Coderwww.google.com/search?q=Embedded+Coder[追記2]こういうやり方をする人はあまりいないと思いますが、私は過去に以下のような芸当をしたこともありました。(A) Windows(あるいはDOS時代だったかも)のコンソールアプリケーションとして、渡された引数を、あるコンパイラのものから別のコンパイラのものへ変換して、変換後のオプションで最終的にコンパイラを起動するラッパーアプリケーションを自分で書く[追記3]そういえば、昔、HEW+KPIT GCC環境で、HEWが渡して来たコマンドオプションファイルを引数にベタに展開してコンパイラを起動するwrapperコマンドが使われていた、という記憶が蘇って来ました。それだったかも、、、
macrx.exe はアセンブラソース(*.src)を入力に要求するコマンドなので、コンパイラが出力した中間のアセンブラソースをアセンブラに渡すために呼ばれたのかと。いずれにせよコマンドが実行できないと言っているので、実行環境がコンパイラの要件を満たしていないのかもしれません。CygWinとか使ってますか?
同じものをビルドするプロジェクトをCS+で作り直した方が早そうに思えますが...
ほやさん
リプライありがとうございます。
CygWinは使っておりません。
わたしも「コンパイラが出力した中間のアセンブラソースをアセンブラに渡すために呼ばれたのかと。」と同じ認識です。
ccrxはできても、macrxが実行できない場合って、どんなケースがあるのでしょうか。
どうぞよろしくお願いいたします。
とっさん さん、こんにちは。NoMaYです。> ccrxはできても、macrxが実行できない場合って、どんなケースがあるのでしょうか。それを探るために、私の場合、Windowsのコマンドプロンプトウィンドウを開いてMATLAB Embedded Coderが実行しようとしたコマンドを手入力してみると思います。
"C:\Program Files (x86)\Renesas Electronics\CS+\CC\CC-RX\V3.03.00\Bin/ccrx" -isa=rxv2 -fpu -endian=big -dbl_size=8 -signed_char -signed_bitfield -auto_enum -bit_order=left -pack -lang=c99 -output=obj -define=TERMFCN=1 途中省略 -include=C:/PROGRA~1/MATLAB/R2017A~1/rtw/c/ert "AirByp.c"
咄嗟に思い浮かんだ可能性としては以下のものがあります。確度は不明ですが、、、・環境変数PathにCC-RXのパスが追加がされていないといけない?・環境変数Pathが削除されていてはいけない?(MATLABが環境変数Pathを子プロセスに引き継いでいない?)・環境変数TEMPやTMPが削除されていてはいけない?(MATLABが環境変数TEMPやTMPを子プロセスに引き継いでいない?)・(そもそも)AirByp.cが余りに巨大でコンパイル出来ない・(MATLABを起動していると)メモリ不足でコンパイル出来ないなど。
NoMaYさん
御教示ありがとうございます。
Windowsのコマンドプロンプトウィンドウの手法を試してみます。
また、ご示唆頂いた可能性について、Matlab側にも確認してみます。
どうも有難うございます。
とっさん さん、こんにちは。NoMaYです。> また、ご示唆頂いた可能性について、Matlab側にも確認してみます。むしろ、F0553200:Error occurred in executing 'macrx.exe'に関しては先にルネサスさんに問い合わせた方が見通しが良くなるかも知れません。(既に問い合わせているかも知れませんが、、) 私が挙げた可能性は、どちらかというと、CC-RX側に起因する可能性が主、ですので、、、
ルネサスさんに質問してみたのですが、ゴールに近ずく回答は得られませんでした。(質問が悪かったのかもしれませんが、)
環境変数について教えて貰えないでしょうか。
コマンドラインでCC-RXを利用する時は環境変数を下記リンクの様に書くことが必要とありました。
http://csps.hitachi-solutions.co.jp/rx-c/faq/index.html
コンパイラのユーザーズマニュアルを見ても同様な環境変数(PATH, BIN_RX, INC_RX, TMP_RX, CPU_RX)が有るのですが、
これらはcc-rxが参照するものなのでしょうか?環境変数とはCS+の場合にはどの設定が該当するのでしょうか?
また、これらはcc-rxをコールする前に記載しておく必要が有るのでしょうか?
知識が無く教えていただけたらと存じます。
set PATH=C:\Program Files\Renesas Electronics\CubeSuite+\CC-RX\V2.00.00\bin;%PATH% set BIN_RX==C:\Program Files\Renesas Electronics\CubeSuite+\CC-RX\V2.00.00\bin set INC_RX=C:\Program Files\Renesas Electronics\CubeSuite+\CC-RX\V2.00.00\include set TMP_RX=%TEMP% set CPU_RX=RX600どうぞ宜しくお願いいたします。
CC-RXが使う環境変数は、マニュアルに書いてありますね。http://tool-support.renesas.com/autoupdate/support/onlinehelp/ja-JP/csp/latest/CS+.chm/Compiler-CCRX.chm/Output/ccrx02c0300y.htmlCS+で、「ビルド前に実行するコマンド」(ビルド後の方でもいいんだが)に、set コマンド (パラメータなし) を書いておき、ビルドを実行してみればビルド時に設定されている環境変数がコンソールに出力されます。それを参考にすれば良いのではないかと思います。
とっさん さん、こんにちは。NoMaYです。ほやさん指摘のウェブページを見て、BIN_RXという環境変数がlbgrxコマンド利用時は省略不可である、ということを初めて知りました、、、ところで、先日の件、コマンドを手入力したらどうなりましたでしょうか?
とっさん さん、こんにちは。NoMaYです。まだ解決していないのですよね。私の認識は、こんな感じなのですけれども、、、(1) TIのARMマイコンよりルネサスさんのRXマイコンを使った方が、市場競争力の高い自社製品を開発出来そうだと感じている(よって、マイコンを乗り換えたい)が、MATLAB Embedded Coderを使うのが社内では当たり前になっているので、それが使えないのでは社内の賛同を得ることは難しい。(2) MATLAB Embedded Coderが、自身が生成したソースコード中の条件コンパイル文に対して、どういう場合にどんなdefineを有効にしてくるのか分からないので、MATLAB Embedded Coder上でビルドすることを早々に諦める訳にはいかない。(3) 理屈の上では(ドキュメント上は)、MATLAB Embedded Coderのコンパイラ対応機能を活用することでMATLAB Embedded Coder上でビルド出来る筈であるが(出来る筈だと思われるのだけれども)、何故か謎のエラーが発生してCC-RXの実行に失敗してしまう。(なお、まだ、仮にビルド出来るようになったとしても、ちゃんと動作するかどうか、ちゃんと動作するようにするにはどうすれば良いか、といった話は、まだまだ、これからである。) ちなみに、TIのARMマイコンでは、GNUARMがちゃんと実行出来て、ビルドも出来て、動作する物も出来ていた。(4) CC-RXの実行に失敗してしまう原因は、ルネサスさんにも心当たりが無い。(環境変数がどうのこうの話の発端は私のリプライの中の環境変数の話が発端なだけなのかも?、、、)基本的なアプローチは以下なのだとは思うのですが、、、(A) MATLAB Embedded Coderで、動作するかどうかは別問題として、まずは最小限のコードを生成するように設定して、MATLAB Embedded Coder上でビルド(しようと)して、実行される(筈の)ビルドコマンドの一覧 or makefileを入手する。ここで、場合分けがひとつ、発生します。(B-1) そうしたらビルド出来てしまった、とか?(B-2) それでもビルド出来ないことに変わり無し --> たぶん、こちらかな、と仮定しておきます(C) 同じコマンドをコマンドプロンプト上で実行するとどうなるか? --> たぶん、今ここですねここで、場合分けがひとつ、発生します。(D-1) それでもビルド出来ない --> 空のmain()程度のmain.cをコマンドプロンプト上でCC-RXでビルド出来るか?(D-2) そうしたらビルド出来てしまった --> とっさに私が思い付くのは環境変数TEMP/TMPぐらいだったけれども、、、可能性的には、makefileベースのオープンソースソフトウェアでPCを変えたらビルド出来なくなった、というあたりのトピックスと同レベルではないかなぁ、という考えはあるものの、今まで自分は過去どうやってきたのか、いざとなると思い返せないのが申し訳無いですね、、、どうやっていたっけなぁ、、、
ご教示ありがとうございます。CS+の場合で試してみます。