CC-RXで独自(non standard)sectionのbss/dataの初期化をdbsct.cを修正せずに(without modification)行うやり方を試してみた

こんにちは。NoMaYです。

先日、以下のスレッドで独自セクションのBSSやDATAの話題に関わったのですけれども、FITのBSPモジュール内のdbsct.cというソースを変更しないと対処出来ないのが今ひとつすっきりしないなぁ、と我ながら思っていました。(プロジェクトジェネレータが生成した素のCC-RX向けプロジェクト内のdbsct.cであれば、それを変更することは何とも思わないのですが、なんやかんやで毎年数回程バージョンアップが行われるBSPモジュール内のdbsct.cは、出来れば触らずにおきたいという思いがあります。) そう思っていたところ、変更せずに対処するやり方が思い浮かびましたので試してみたところ、うまくいきましたので投稿することにしました。

関わったスレッド: (FITのBSPモジュール内のdbsct.cというソースを変更した)

RX651内部拡張RAMについて
japan.renesasrulz.com/cafe_rene/f/forum5/7443/rx651-ram/39468#39468

初期値あり変数の利用に必要なセクション
japan.renesasrulz.com/cafe_rene/f/forum5/7637/thread/40273#40273

FITのBSPモジュール内のdbsct.cというソースを変更せずに対処するやり方: (以下の赤文字のような記述を自前のソースに記述する)

#pragma section C C$DSEC
const struct {
    uint8_t *rom_s, *rom_e, *ram_s;
}
_DTBL_user[] = {
    { __sectop("D_APP_CAL"), __secend("D_APP_CAL"), __sectop("R_APP_CAL") },
    { __sectop("D_APP_CAL_2"), __secend("D_APP_CAL_2"), __sectop("R_APP_CAL_2") },
    { __sectop("D_APP_CAL_1"), __secend("D_APP_CAL_1"), __sectop("R_APP_CAL_1") }
};
#pragma section

#pragma section C C$BSEC
const struct
{
    uint8_t *b_s, *b_e;
}
_BTBL_user[] = {
    { __sectop("BEXRAM"), __secend("BEXRAM") },
    { __sectop("BEXRAM_2"), __secend("BEXRAM_2") },
    { __sectop("BEXRAM_1"), __secend("BEXRAM_1") }
};
#pragma section

#pragma section _APP_CAL
volatile float pRWPmpLL_C = 10.0F;
volatile char just_for_future_1_byte_data_use = 0xAB;
volatile short just_for_future_2_byte2_date_use = 0xCDEF;
#pragma section /* Restore section names to standard section names. */

#pragma section EXRAM
uint8_t exram[256 * 1024];
#pragma section /* Restore section names to standard section names. */

 
このやり方でも以下の画面コピーの通り意図したように独自セクションのBSSやDATAが初期化されました。



念の為、独自セクションの変数やメモリ領域を書き換えてリスタート(Reset&Go)させてみましたが大丈夫でした。



 

Parents
  • こんにちは。NoMaYです。

    すみません、今日、別スレッドにて気付いたのですが、関数をRAMに配置する場合に漏れがありますね。CC-RXはコードに関して Pセクション の他に W*セクション(分岐テーブル) も生成する場合があるからです。(それから、コードではありませんけれども、そのプログラムでconst変数を使用していれば C*セクションも無縁というわけでは無いです。なお、const変数に関しては普通の変数にすることを考えるのが良さそうだと思いますけども。)

    関数をRAMに配置する場合の1つの目的であるフラッシュセルフ書き込みでは、諸々込みでRAMに配置する必要があります。ただ、FITのR_FLASH_RXモジュールの場合、今のところ、分岐テーブルを生成するようなソースにはなっていませんので、問題にならないようです。

    他方で、その場合にユーザがユーザ作成の割り込みルーチンもRAMへ配置するとなると、この話の可能性が出てきます。(更にRAMに配置した割り込みルーチンからC言語標準ライブラリや自作ライブラリその他を呼び出している場合には呼び出されているライブラリもRAMに配置するといった処置も必要になります。)

    それで、ライブラリの話は脇へ置くことにして、W*セクションに関してですが、実は、CC-RX V3.04でも以下のような記述は出来ません。ですので、コンパイルオプションに以下を設定して対処するのが簡単かと思います。

    以下の#pragmaは記述出来ない(個別コンパイルオプションで設定することは出来ますがファイル全体が対象になります)

    #pragma section W WRAM

     
    以下のコンパイルオプションをプロジェクト全体で設定するのが簡単かと思います(統合開発環境上で設定出来ます)

    -case=ifthen

     
    [関連リンク]

    A.1.1 配置領域を変更する - top > コンパイラ編 > クイック・ガイド > 変数(C言語) > 配置領域を変更する
    tool-support.renesas.com/autoupdate/support/onlinehelp/ja-JP/csp/V8.07.00/CS+.chm/Compiler-CCRX.chm/Output/ccrxaac0101y.html
     

Reply
  • こんにちは。NoMaYです。

    すみません、今日、別スレッドにて気付いたのですが、関数をRAMに配置する場合に漏れがありますね。CC-RXはコードに関して Pセクション の他に W*セクション(分岐テーブル) も生成する場合があるからです。(それから、コードではありませんけれども、そのプログラムでconst変数を使用していれば C*セクションも無縁というわけでは無いです。なお、const変数に関しては普通の変数にすることを考えるのが良さそうだと思いますけども。)

    関数をRAMに配置する場合の1つの目的であるフラッシュセルフ書き込みでは、諸々込みでRAMに配置する必要があります。ただ、FITのR_FLASH_RXモジュールの場合、今のところ、分岐テーブルを生成するようなソースにはなっていませんので、問題にならないようです。

    他方で、その場合にユーザがユーザ作成の割り込みルーチンもRAMへ配置するとなると、この話の可能性が出てきます。(更にRAMに配置した割り込みルーチンからC言語標準ライブラリや自作ライブラリその他を呼び出している場合には呼び出されているライブラリもRAMに配置するといった処置も必要になります。)

    それで、ライブラリの話は脇へ置くことにして、W*セクションに関してですが、実は、CC-RX V3.04でも以下のような記述は出来ません。ですので、コンパイルオプションに以下を設定して対処するのが簡単かと思います。

    以下の#pragmaは記述出来ない(個別コンパイルオプションで設定することは出来ますがファイル全体が対象になります)

    #pragma section W WRAM

     
    以下のコンパイルオプションをプロジェクト全体で設定するのが簡単かと思います(統合開発環境上で設定出来ます)

    -case=ifthen

     
    [関連リンク]

    A.1.1 配置領域を変更する - top > コンパイラ編 > クイック・ガイド > 変数(C言語) > 配置領域を変更する
    tool-support.renesas.com/autoupdate/support/onlinehelp/ja-JP/csp/V8.07.00/CS+.chm/Compiler-CCRX.chm/Output/ccrxaac0101y.html
     

Children
No Data