スマートコンフィグレータにてコード生成を行うと、生成されたコードがバグだらけになります。画像のトランスミットFIFOデータ数トリガを0→1に変更したので、コード生成を行いました。
そうするとソースコードにバツ印が付き、プログラム内で下記のようなエラーメッセージが出ます。
原因わかりますでしょうか。コンポーネントの設定を変えたタイミングで何度かコード生成していますが、今回の症状が出たのは初めてです。現在のコンポーネントのバージョンは下記画像です。
使用しているのはe2studioの2023-7、CCRX-V3.00 です。
下記URLを参考にファイルサイズを大きくしましたが、解決していません。
ja-support.renesas.com/.../17797612
そもそも、スマートコンフィグレータでコンポーネントの設定を変えただけで、ファイルサイズがオーバーすること等あるのでしょうか。
何かわかる方いればよろしくお願いします。
これ、ビルドが通るならスマートコンフィギュレータのバグではないです。EclipseベースのIDEではよくあることで参照名のインデックスを作成するときメモリ制限を超えると起こります。制限を増やすか気にしない。もしくはコード生成後に再度インデックスの再構築を実行するといいです。生成前のインデックスが残っていて新規に作ったものでインデックスが増えてメモリを使い果たした可能性もあります。私はクリーンアップしてプロジェクトを一度閉じて、再度開いた後にインデックスを再構築したりします。
Yamamoto様ビルドしてもエラーもワーニングも起きず、挙句デバッグも普通に出来ていました。インデクサーの再ビルドでも治らなかったので、原因不明でした。EclipseベースのIDEではよくあることなのですね。何か理由があって生成前のインデックスが残っていしまい、結果としてすべてのインデックスが2重になっていた可能性がありますね。昨日はずっとプロジェクト立ち上げたままで治せるか試していましたが、今朝プロジェクトを立ち上げると、エラーがすべて消えていました。ご指摘の通り、「一度プロジェクトを閉じる」がもっとも手っ取り早い解決方法だったかもしれません。ご回答ありがとうございました。
ちなみにですが、Eclioseで起きる問題が確認できる日本のコミュニティなどあるのでしょうか。e2studioで解決策を考えるよりもEclipseで検索したほうが良いと聞いたことがあるのですが.....。何か知っているものがあれば教えていただくことは可能でしょうか。
まず一点、スマートコンフュギュレータの生成コード自体はバグコードを吐き出さないですが、仕様として「ダメ」な点(あくまで私の主観です)。例えば顕著なのがタイマー系のコンポーネントの生成コードの生成ルールの仕様で生成したコードのマクロ宣言に値そのものを含んだマクロ名が生成されるという謎な仕様を持っている点です。具体的には三相モーター用のコンポーネントの生成コードでTCNT値が生成されますが、ツールの使用者(主観としての私)としてはコンポーネント設定で与えた周期設定がTCNT_VALUE_みたいなマクロ名でそれが値として参照できることを期待するのになぜか、_XXXX_3TCNT_VALUE (3はMTU3なのでまぁ仕方なしでしょうけど)というふうにXXXXに設定値が書かれたマクロ名で実態はXXXXそのものです。つまり0x00F0Uを設定したら
#define _00F0_3TCNT_VALUE (0x00F0U) /* MTU3.TCNT value */
というのが生成されるわけです。なので値を変更してコード生成すると参照名としてのマクロがどんどん追加されるんでインデックス生成用のメモリがどんどんなくなるというわけです。一度クリーンアップしてインデックスを再構築する必要があるというのはこれが主たる原因です。ほんとこの謎仕様、そろそろこの生成方法を考えた人は責任を感じてほしい。これを「ヨシ!」としている人はいたら私と議論しましょう。こんな生成なら自分で数値を直埋めします。Index作成で完了しなかったり完了しなくて参照できなくてエラーになるのはJavaの頃から(EclipseはもともとJavaようIDEとして開発された後CDTというプラグインを入れてC・C++開発に対応できるようになっています)ですので、まぁ、そういうものなんです。e2studioはそれにルネサスマイコンに特化したプラグインを一式揃えたIDEなので警告などが出た時、何が起因しているか?って切り分けは初学者にはちょっと難しいかもです。
Yamamoto様
クリーンアップというのは「プロジェクトをクリーンにする」というメニュー内の操作の事でしょうか。設定値がかかれたマクロが毎回生成されて蓄積されるのは本当に謎仕様ですね。値だけ変えれば済むはずのマクロの良さがなくなっていますね。メモリがどんどんなくなる原因が分かりました。
まさに問題の切り分けが壁として立ちはだかっていますね。これはもう片っ端から解決してなれるしかないですね。
インデックスがやり直しになるのはコード生成時にフォルダごとファイルが作り直されるからだと思います。余計なプロジェクトがオープンされていると重くなると思います。インデックスはプロジェクトごとに持っているので。余分なビューを閉じておくとか、eclipseを軽くするための一般的な対策は知っておくと良いです。
ほや様
コード生成時に元々生成済みのファイルの差分だけ治ってくれると良いのですが、そういう事ではないのですね。
eclipseを軽くするという対策について考えたことがなかったので、調べてみようと思います。
遅い返信ですみません。鈴木と申します
いろんなところからの要求に応じているうちに謎設定になってしまっています。
今はレジスタに直値が入るようなオプションがあるので、ご利用ください
鈴木様、試してみました。教えていただいたように設定変更して生成すると初期化APIは数値が直で出力されているのですが、そう言うことじゃないです。だめですね。要望の動作ではないです。残念です。これはモーター用のコンポーネントの出力例です#define _00F0_3TCNT_VALUE (0x00F0U) /* MTU3.TCNT value */#define _00F0_TDDRA_VALUE (0x00F0U) /* MTU.TDDRA value */#define _0BB8_TCDRA_VALUE (0x0BB8U)#define _0BB8_TCDRB_VALUE (0x0BB8U)#define _0BB8_TCDRA_VALUE (0x0BB8U) /* MTU.TCDRA value */#define _0654_3TGRB_VALUE (0x0654U) /* MTU3.TGRB value */#define _0654_4TGRA_VALUE (0x0654U) /* MTU4.TGRA value */#define _0654_4TGRB_VALUE (0x0654U) /* MTU4.TGRB value */#define _0CA8_SUM_VALUE (0x0CA8U) /* Timer General Register (TGR) value */こういうのが出るのがダメだと言うの私の考えです。以下のような出力形式がいいと言うことです。#define _3TCNT_VALUE (0x00F0U) /* MTU3.TCNT value */#define _TDDRA_VALUE (0x00F0U) /* MTU.TDDRA value */#define _TCDRA_VALUE (0x0BB8U)#define _TCDRB_VALUE (0x0BB8U)#define _TCDRA_VALUE (0x0BB8U) /* MTU.TCDRA value */#define _3TGRB_VALUE (0x0654U) /* MTU3.TGRB value */#define _4TGRA_VALUE (0x0654U) /* MTU4.TGRA value */#define _4TGRB_VALUE (0x0654U) /* MTU4.TGRB value */#define _SUM_VALUE (0x0CA8U) /* Timer General Register (TGR) value */
なぜ現状の仕様はマクロ名に値が埋め込まれているような仕様にしたんでしょうか?と使うたびに不思議な気持ちになります。マクロとしての意味ないですよね。値参照したいというのにそれができないので別途、別ファイルを作成して設定値を定義する必要が出てきて生産性が低いです。ツール上の設定値変更と別途用意したファイルの定義値の連動を手動でするのはナンセンスです。
鈴木様
ご回答ありがとうございます。教えていただいたオプションを使用しましたが、ソースコードの×印は消えなかったです。今のインデクサーの設定は、「100MBより大きなファイルをスキップ」「100MBより大きなincludeをスキップ」としております。これ以外にこのエラーを回避する方法が現状では分からないですが、他に方法ありますでしょうか。
初様鈴木様のアドバイスはこの件では役に立ちません。値を変えるとマクロが別名で生成されると言うのはそのままであるためです。やっていることはR_XXX_Create (XXXはコンポーネント名)関数の中でマクロの代わりに数値を直書しているだけで、マクロ生成自体の手法が変わらないのでインデックス作成であまりに多いシンボル情報によって起こっている今回の問題が解決されないためです。私が書いたようなマクロ生成手法の仕様を見直してマクロ名に数値自体を埋め込まないようにすることくらいでしか解決しません。今の仕様だとマクロ生成されてても再利用性がないのでいっそ、生成しなくていいって気すらします。
Shoji様
マクロ名に関しては私も同意見です。書き換わる数値をDefine名に使うのは、可読性としても落ちます。
政治的な理由で仕様が決まってすまうこともありますが、全体としては使いやすいようになるよう
目指していきたいと思っています。数値名を省いたDefine名も生成できるように依頼したいと思います
以上、よろしくお願い申し上げます。
今回の問題とは切り離して考えます。再利用性が無いのは難点ですね。ついにプロジェクトを再起動してもエラーが消えなくなったので、既にあきらめてしまっていますが、とりあえずはビルドなどに影響しないのでネット上で解決策を引き続き探してみます。
初様これは現状インデックスのためのメモリを上限を増やすしか解決できません。「ウィンドウタブ」の中にある「設定」からe2studio全体の設定ダイアログを開いて「C/C++」の「インデクサー」設定を変更してなるべくエラーの出ない設定に変更するしかありません。自動更新を止めて、自分で任意のタイミングでインデックス作成もできますよ。今回の場合ですと「型およびマクロの参照をスキップ」を有効化すると無駄に増えるマクロ宣言のインデックス作成がなくなるかもしれません(未確認)。
1000MBほどに増やしたのと、「型およびマクロの参照をスキップ」を使用しましたが、やはり変化はなかったです。今後コンポーネントを増やしていく際に自動更新を止める方法も試してみます。自分の環境だとプロジェクトのクリーンも効果をなさないので、インデクサーの設定の組み合わせを試してみます。うまくいった方法があればまたここに記載します(記載がない場合はお察しください...。)
> インデクサーの設定の組み合わせを試してみます他にはインデックスされていないと困るファイルを指定しておくという方法もあります。(Index all variants of specific headers: 欄にヘッダファイル名を記述)https://stackoverflow.com/questions/10095295/why-cant-codan-find-size-t/10095683#10095683「気にしない」という無敵の対策もありますが。
ヘッダファイルを直接記述して指定していくやり方ですね。増えるたびに設定するのは面倒ですが、エラーを消すために最適化する手段としては確実ですね。
まさしく「気にしない」でこういうもんだと思えばよいのかもしれませんね。