スマートコンフィグレータにてコード生成を行うと、生成されたコードがバグだらけになります。画像のトランスミットFIFOデータ数トリガを０→１に変更したので、コード生成を行いました。
そうするとソースコードにバツ印が付き、プログラム内で下記のようなエラーメッセージが出ます。
原因わかりますでしょうか。コンポーネントの設定を変えたタイミングで何度かコード生成していますが、今回の症状が出たのは初めてです。現在のコンポーネントのバージョンは下記画像です。
使用しているのはe2studioの2023-7、CCRX-V3.00 です。
下記ＵＲＬを参考にファイルサイズを大きくしましたが、解決していません。
ja-support.renesas.com/.../17797612
そもそも、スマートコンフィグレータでコンポーネントの設定を変えただけで、ファイルサイズがオーバーすること等あるのでしょうか。
何かわかる方いればよろしくお願いします。
これ、ビルドが通るならスマートコンフィギュレータのバグではないです。EclipseベースのIDEではよくあることで参照名のインデックスを作成するときメモリ制限を超えると起こります。制限を増やすか気にしない。もしくはコード生成後に再度インデックスの再構築を実行するといいです。生成前のインデックスが残っていて新規に作ったものでインデックスが増えてメモリを使い果たした可能性もあります。私はクリーンアップしてプロジェクトを一度閉じて、再度開いた後にインデックスを再構築したりします。
Yamamoto様ビルドしてもエラーもワーニングも起きず、挙句デバッグも普通に出来ていました。インデクサーの再ビルドでも治らなかったので、原因不明でした。EclipseベースのIDEではよくあることなのですね。何か理由があって生成前のインデックスが残っていしまい、結果としてすべてのインデックスが２重になっていた可能性がありますね。昨日はずっとプロジェクト立ち上げたままで治せるか試していましたが、今朝プロジェクトを立ち上げると、エラーがすべて消えていました。ご指摘の通り、「一度プロジェクトを閉じる」がもっとも手っ取り早い解決方法だったかもしれません。ご回答ありがとうございました。
ちなみにですが、Eclioseで起きる問題が確認できる日本のコミュニティなどあるのでしょうか。e2studioで解決策を考えるよりも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名も生成できるように依頼したいと思います
以上、よろしくお願い申し上げます。
Yamamoto様
今回の問題とは切り離して考えます。再利用性が無いのは難点ですね。ついにプロジェクトを再起動してもエラーが消えなくなったので、既にあきらめてしまっていますが、とりあえずはビルドなどに影響しないのでネット上で解決策を引き続き探してみます。
鈴木様定義が被る可能性があるので今数値が埋め込まれているところをコンポーネント名に置き換えるのが落としどころかなと思います。政治的な理由・・・とても残念な理由の一つですね。ユーザーには関係ない。そして離れて行くとなってしまう。
初様これは現状インデックスのためのメモリを上限を増やすしか解決できません。「ウィンドウタブ」の中にある「設定」からe2studio全体の設定ダイアログを開いて「C/C++」の「インデクサー」設定を変更してなるべくエラーの出ない設定に変更するしかありません。自動更新を止めて、自分で任意のタイミングでインデックス作成もできますよ。今回の場合ですと「型およびマクロの参照をスキップ」を有効化すると無駄に増えるマクロ宣言のインデックス作成がなくなるかもしれません（未確認）。
1000MBほどに増やしたのと、「型およびマクロの参照をスキップ」を使用しましたが、やはり変化はなかったです。今後コンポーネントを増やしていく際に自動更新を止める方法も試してみます。自分の環境だとプロジェクトのクリーンも効果をなさないので、インデクサーの設定の組み合わせを試してみます。うまくいった方法があればまたここに記載します（記載がない場合はお察しください...。）
> インデクサーの設定の組み合わせを試してみます他にはインデックスされていないと困るファイルを指定しておくという方法もあります。(Index all variants of specific headers: 欄にヘッダファイル名を記述)https://stackoverflow.com/questions/10095295/why-cant-codan-find-size-t/10095683#10095683「気にしない」という無敵の対策もありますが。
ほや様
ヘッダファイルを直接記述して指定していくやり方ですね。増えるたびに設定するのは面倒ですが、エラーを消すために最適化する手段としては確実ですね。
まさしく「気にしない」でこういうもんだと思えばよいのかもしれませんね。