スマートコンフィグレータにてコード生成を行うと、生成されたコードがバグだらけになります。画像のトランスミット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を軽くするという対策について考えたことがなかったので、調べてみようと思います。