Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page

e2-studioでのdebug構成からrelease構成への変更方法

開発環境:e2-studio Ver7.60、コンパイラGCC ver4.8.4(2019/02) でRX65Nのサンプルプログラム(独自のもの)を作りました。基板は、RX65N Envision Kit基板です。e2-studioのプロジェクト作成ナビゲーションで、ハードウェアデバッグの構成をし、ハードウェアデバッグしてサンプルプログラムが動作するのを確認しました。デバッグが終了したので、”Release”モードのビルドをしたいのですが、現状の”ハードウェアデバッグ”構成から、どのような操作で”release”構成をつくれば良いでしょうか?もちろん、最初から(プロジェクト作成のナビゲーションで”Release”構成を)作り直せばできるとは思いますが、他に方法はないでしょうか?

 

 

 

  • Nonaka Toruさん、こんにちは。NoMaYと申します。

    一番手っ取り早いのは、コンパイラ設定の最適化設定を -O0(確かHardwareDebugは-O0だったと思います) → -O2(或いはコードサイズが増大するデメリットより実行性能の向上を重視したい場合には-O3) へ変更するだけで済ませること(ビルド構成はHardwareDebugのままで)かな、と思います。

    マイコンでは、ソースコードデバッグが終わった後に、リリースビルドしたプログラムをマイコンへダウンロードして実行させたい場合にもデバッガでダウンロードしてしまうのが手っ取り早いことが殆どですし、量産時に必要になるビルド生成物はMOTファイルだけの場合が殆どなのでELFファイルにデバッグ情報が含まれようが(←ELFファイルのサイズが大きかろうが)含まれまいが(←ELFファイルのサイズが小さかろうが)関係無い(どちらもMOTファイルのサイズは同じ(筈))ことが殆どだからです。

    また、debug構成とrelease構成の2重構成にするとインクルードパスやマクロ定義などのメンテが2度手間になることもあり、コンパイラ設定の最適化設定を変更して済ませる、というモチベーションになっていたりします。これは私だけではないらしくて、過去(HEWなどで)、debug構成とrelease構成の2つあるけれどもrelease構成ではまともにビルド出来ないプロジェクト、に幾つも遭遇しています。

    ただ、debug構成とrelease構成の切り替えをツールバーのドロップダウンリストからサッと切り替えたい人もいると思いますので、その場合は、確か、プロジェクトのプロパティのビルド設定を開いた時にダイアログの上の方に、ビルド構成の管理ダイアログを開くボタンがあったかと思いますので、そのダイアログでHardwareDebug構成のコピーをReleaseという名前にして作成して、そのRelease構成で最適化設定を変更すれば良い筈です。(最適化設定を変更するだけで充分な筈です。)

    [追記]

    なお、以下のようなデバッグ用printf出力の有効/無効の切り替えを行っている場合は、最適化設定以外に、マクロ定義の変更も行います。(ヘッダファイル内で#define NDEBUGと#define _DEBUGの片方をエディタで編集してコメントアウトして切り替えるやり方を取れば、ビルド構成でのマクロ定義の変更は不要です。)

    #if defined(NDEBUG) && !defined(_DEBUG)
    #define dbgprintf(...)
    #else
    #define dbgprintf(...) printf(__VA_ARGS__)
    #endif

     

  • In reply to NoMaY:

    NomaY様、情報をありがとうございました。その情報をもとに、コンパイル時の最適化とデバッグの設定について調べてみました。最適化はご指摘頂いたように-O0を変更すれば良さそうですね。それと、もしかして、-gを削除しないと最適化されないでしょうか(実際やってみないとわかりませんけれど)? 元々HEWで作業していたので、その時は、”DEBUG”と”Release"が予め準備されていたのであまり意識はしていなかったのですが、e2-studioを作業し始めて戸惑ってしまった次第です。改めてお礼を申し上げます。
  • Nonaka Toruさん、こんにちは。NoMaYです。

    > もしかして、-gを削除しないと最適化されないでしょうか(実際やってみないとわかりませんけれど)?

    -gは残しておいて構いませんよ。実際、私は、-g(及び-g関連)を残したまま-O2や-O3にしています。(そうやって切り替えて、性能やコードサイズが変化していますので、-O2や-O3は効いていますね。)

    例)

    TB-RX65N/TB-RX231/TB-RX130+CC-RX/GNURXでCoreMark®ベンチマークを動かせるようにしてみようと思います
    ↓-O3
    japan.renesasrulz.com/cafe_rene/f/forum21/6022/tb-rx65n-tb-rx231-tb-rx130-cc-rx-gnurx-coremark/33617#33617
    ↓-Og
    japan.renesasrulz.com/cafe_rene/f/forum21/6022/tb-rx65n-tb-rx231-tb-rx130-cc-rx-gnurx-coremark/33645#33645
     

  • ほや です。
    こんにちは。

    > 現状の”ハードウェアデバッグ”構成から、どのような操作で”release”構成をつくれば良いでしょうか?
    プロジェクト・エクスプローラでプロジェクト名の上で右クリックし、コンテクストメニューの「ビルド構成」から「管理...」を選ぶと管理画面が出てビルド構成の複製/削除や名称変更が行えます。
    またはプロジェクトのプロパティ画面の「C/C++ビルド」のトップにあるビルド構成の右側にある「構成の管理...」でも同じ画面に飛びます。

    プロジェクトのプロパティ設定画面でオプションを変更した時、設定が反映されるのは現在アクティブになっている(プロジェクト名の右側にカッコで表示されている名前の)ビルド構成(Build Configuration)です。
    プロパティ設定画面でビルド構成を選択するのを忘れてうっかり設定を変えてしまうとワケの分からない事になります。
    NoMaYさんが被害に会われたのもそういうことでしょう。

    ビルド構成の用途は、デバッグ用、リリース用の作り分けに限りません。
    複数組のオプションを使い分けたり、ビルド構成別に使用するファイルを選んだりして例えば一つのプロジェクトで複数の機種向けのアプリケーションを作り分ける事ができます。
    逆に言えば作り分ける必要がないならなるべく1つで運用した方が良いです。ビルド構成をむやみに増やすとロクな事になりません。

    もしリリース向けにデバッグ情報を含まないオブジェクトを作るにしても、
    最初からリリース用のビルド構成を作っておく必要はなく、
    最後の最後にデバッグ用のビルド構成からリリース用のビルド構成を派生させれば良いのですから。

  • In reply to ほや:

    ほとんどの場合でCPU能力とメモリに余裕を持つのでほやさんのやりかたで問題が無いと思いますが、途中で要求仕様が膨らんでメモリが足らなくなるという失敗したことがありその後は最適化有りを基本にしてます。テストで不合格になり印刷したソースコードとペンでバグが見つからない場合のみデバッグモードにしてチェックします。
    最適化ありでメモリやCPU能力が足らなくなるのは幸いにして私は経験してませんが、見たことはあります。

Top Page [◀◀]  2   3   4   5   6   7   8   9   ... [▶▶Last Page