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

RenesasさんからRXマイコンの低価格Target Boardが出たのでサンプルプログラムをCSplus projectへ変換してみようと思います

こんにちは。NoMaYです。

ウェブで調べ物をしていたら、ルネサスさんからRXマイコンの低価格ボードが出たことを知りました。でも、サンプルプログラムがe2 studioプロジェクト版しか無いようなのでCS+プロジェクトに変換して後で投稿してみようと思います。(もっとも、ボードが無くて動作確認は出来ないので、MOTファイルが同一になるようにしてみるところまでですが、、、) 30米ドル程らしいので3千円ちょっとぐらいかな。

拡充を続ける32ビットマイコン「RXファミリ」を容易に導入できるターゲットボードを発売
~家電製品、ビル用および産業用オートメーション機器向けなどに、「RX65N」「RX130」「RX231」用を用意。組み込み開発のスタートを支援~
www.renesas.com/ja-jp/.../news20180219.html

Target Board for RX family 製品ページ
www.renesas.com/ja-jp/.../rx-family-target-board.html
 

  • こんにちは。NoMaYです。

    今更ながらユーザーズマニュアルが昨年の夏(2018年7月)に改版されていたことに気付いたので目を通していたら、「RFPとの通信は未対応です」との記載が削除されていたことに気付きました。また、以下のようにRFPが使える旨の記載に変更されていたことにも気付きました。試してみたところ、無事にRFPと通信が成立しました。(ちなみに、初回通信時にオンボードエミュレータのファームもアップデートされたっぽいです。)

    Target Board for RX130 ユーザーズマニュアル Rev.1.01 2018.7
    www.renesas.com/jp/ja/doc/products/mpumcu/doc/rx_family/r20ut4169jj0101-rxtb.pdf

    Target Board for RX231 ユーザーズマニュアル Rev.1.01 2018.7
    www.renesas.com/jp/ja/doc/products/mpumcu/doc/rx_family/r20ut4168jj0101-rxtb.pdf

    Target Board for RX65N ユーザーズマニュアル Rev.1.01 2018.7
    www.renesas.com/jp/ja/doc/products/mpumcu/doc/rx_family/r20ut4167jj0101-rxtb.pdf

    旧(Rev.1.00 2017.10) 12頁

    5.2 USB コネクタ
    コネクタ形状はUSB mini-B で、用途はデバッグインタフェースです。...以後省略...


    新(Rev.1.01 2018.7) 12頁

    5.2 USBコネクタ
    コネクタ形状はUSB mini-Bで、用途は統合開発環境(IDE)とルネサスフラッシュプログラマ(RFP)を使用するためのインタフェースです。...以後省略...


    以下、プロジェクトを作成してブランクチェックした時の画面コピーです。(なお、RFPのメッセージ表示エリアを少し伸ばすように加工して、メッセージを一度に見られるようにしてあります。)

    プロジェクト作成




    ブランクチェック

  • こんにちは。NoMaYです。

    RFPを触っていて、オンボードエミュレータとの通信切断時に、オンボードエミュレータのリセット出力をHi-zにし、切断後も、そのままHi-zを継続する、ということが出来ることに気付きました。TBボードのマニュアルによると、USBから給電する場合、プログラムをフリーランさせるにはボードのジャンパピン(要半田付け)をショートさせてオンボードエミュレータをリセット状態にしなければならないのですが、この機能を使えば、ジャンパピンをオープンにしたまま、RFPで書き込んだ後にすぐにプログラムをフリーランさせることが出来ます。

    また、RFPには、サイレントモードというものがあり、GUIを表示することなしに、コマンドラインオプションでRFPの操作を制御することが出来るのですが、RFPの操作としてチェックサムコマンドを指定しておくと、DOSプロンプトから気軽にオンボードエミュレータのリセット出力をHi-z or Lowにすることが出来るようになります。(ただし、短時間だけLow⇔Hi-zのトグルがあります。とはいえ、マイコンはフラッシュプログラミングモードに入っていますので、ユーザプログラムは走りません。) DOSプロンプトから以外にも、Windowsショートカットを作成して、コマンドライン文字列を設定してやれば、WindowsデスクトップやWindowsツールバーに配置して、1クリック(or 1 ダブルクリック)で行えるようになります。

    他方、以前からTeraTermにTeraTerm Menuというランチャーソフトが同梱されていることに気付いていて何か機会があれば試してみようと思っていたのですが、ふと、これで試してみようという考えが思い浮かびました。そこで、以下の画面コピーのように、やってみました。そして、やって分かったのですが、RX231やRX130ではプログラムにIDコードが設定されていないとチェックサムコマンドでもフラッシュメモリが自動的/強制的に消去されます。ルネサスさんが公開しているTBボードのサンプルプログラムではIDコードが設定されていませんでしたので、サンプルプログラムを変更しましたが、その箇所も以下に書いておきました。(なお、RX65Nは少しフラッシュメモリの仕様が異なっており、IDコードを設定する必要は無さそうでしたが、どうせなので、IDコードを設定してみました。)

    ちなみに、そんなことをするよりジャンパを挿したり抜いたりした方が素早く出来るというのも確かなのですが、私のパソコンだとWindowsエクスプローラが暫く固まってしまったりとかして、あまり心地良いものでは無かったりしますので、こういったやり方を試してみました。

    RFPのエミュレータリセット出力の設定画面(本目的では速い通信速度は不要なので確実性重視で250Kbpsにしています)


    TeraTerm Menuの設定画面やメニュー画面
      

    TeraTerm Menuのドキュメントからの抜粋


    RFPのドキュメントのサイレントモードの記載
    www.renesas.com/jp/ja/doc/products/tool/doc/014/r20ut4307jj0200-rfp.pdf


    RFPの操作設定とIDコード設定の画面



    今回のRFPプロジェクトファイル一式(参考)
    rxtb_rfpproj_20190205.zip

    TerTerm Menuの設定(フォルダのパスは私の環境のものになってます)

    リスト項目: TB RX130 RES
    起動アプリ: C:\Renesas\Programming Tools\Renesas Flash Programmer V3.05\RFPV3.exe
    オプション: C:\Renesas\rfpproj\generic\e2lite-fine-res-rx100.rpj /silent

    リスト項目: TB RX130 RUN
    起動アプリ: C:\Renesas\Programming Tools\Renesas Flash Programmer V3.05\RFPV3.exe
    オプション: C:\Renesas\rfpproj\generic\e2lite-fine-run-rx100.rpj /silent

    リスト項目: TB RX231 RES
    起動アプリ: C:\Renesas\Programming Tools\Renesas Flash Programmer V3.05\RFPV3.exe
    オプション: C:\Renesas\rfpproj\generic\e2lite-fine-res-rx200.rpj /silent

    リスト項目: TB RX231 RUN
    起動アプリ: C:\Renesas\Programming Tools\Renesas Flash Programmer V3.05\RFPV3.exe
    オプション: C:\Renesas\rfpproj\generic\e2lite-fine-run-rx200.rpj /silent

    リスト項目: TB RX65N RES
    起動アプリ: C:\Renesas\Programming Tools\Renesas Flash Programmer V3.05\RFPV3.exe
    オプション: C:\Renesas\rfpproj\generic\e2lite-fine-res-rx65x.rpj /silent

    リスト項目: TB RX65N RUN
    起動アプリ: C:\Renesas\Programming Tools\Renesas Flash Programmer V3.05\RFPV3.exe
    オプション: C:\Renesas\rfpproj\generic\e2lite-fine-run-rx65x.rpj /silent

    サンプルプログラムの変更箇所(赤文字)

    RX231の場合: an-r20an0466jj0100-rxtb-rx231\Workspace\tb_rx231\src\cg_src\r_cg_vecttbl.c

    /*;0xffffffa0  ID */
        (void (*)(void))0x45ffffff,

    /*;0xffffffa4  ID */
        (void (*)(void))0xffffffff,

    /*;0xffffffa8  ID */
        (void (*)(void))0xffffffff,

    /*;0xffffffac  ID */
        (void (*)(void))0xffffffff,

    RX130の場合: an-r20an0468jj0100-rxtb-rx130\Workspace\tb_rx130\src\smc_gen\r_config\r_bsp_config.h

    /* Set your desired ID code. NOTE, leave at the default (all 0xFF's) if you do not wish to use an ID code. If you set 
       this value and program it into the MCU then you will need to remember the ID code because the debugger will ask for
       it when trying to connect. Note that the E1/E20 will ignore the ID code when programming the MCU during debugging.
       If you set this value and then forget it then you can clear the ID code by connecting up in serial boot mode using
       FDT. The ID Code is 16 bytes long. The macro below define the ID Code in 4-byte sections. */
    /* Lowest 4-byte section, address 0xFFFFFFA0. From MSB to LSB: Control Code, ID code 1, ID code 2, ID code 3. */
    #define BSP_CFG_ID_CODE_LONG_1          (0x45FFFFFF)
    /* 2nd ID Code section, address 0xFFFFFFA4. From MSB to LSB: ID code 4, ID code 5, ID code 6, ID code 7. */
    #define BSP_CFG_ID_CODE_LONG_2          (0xFFFFFFFF)
    /* 3rd ID Code section, address 0xFFFFFFA8. From MSB to LSB: ID code 8, ID code 9, ID code 10, ID code 11. */
    #define BSP_CFG_ID_CODE_LONG_3          (0xFFFFFFFF)
    /* 4th ID Code section, address 0xFFFFFFAC. From MSB to LSB: ID code 12, ID code 13, ID code 14, ID code 15. */
    #define BSP_CFG_ID_CODE_LONG_4          (0xFFFFFFFF)

    RX65Nの場合: an-r20an0464jj0100-rxtb-rx65n\Workspace\tb_rx65n\src\smc_gen\r_bsp\board\generic_rx65n\vecttbl.c

    #pragma address __OSISreg=0xFE7F5D50           /* OSIS register (ID codes) */
    const unsigned long __OSISreg[4] = {
            0xffffff45, ← 変更する場所が違うので注意
            0xffffffff,
            0xffffffff,
            0xffffffff,
    };

    [参考]

    以下、TBボードのユーザーズマニュアルの画面コピーとTBボードのジャンパピン位置の写真です。

    RX231
    www.renesas.com/jp/ja/doc/products/mpumcu/doc/rx_family/r20ut4168jj0101-rxtb.pdf




    [参考]

    以下、RX231とRX130とRX65Nのハードウェアマニュアルの画面コピーです。

    RX231
    www.renesas.com/jp/ja/doc/products/mpumcu/doc/rx_family/r20ut4168jj0101-rxtb.pdf





    RX130
    www.renesas.com/jp/ja/doc/products/mpumcu/rx100/r01uh0560jj0300-rx130.pdf

    ...以後、RX231と同様なので、省略します...

    RX65N
    www.renesas.com/jp/ja/doc/products/mpumcu/doc/rx_family/r01uh0590jj0210-rx651.pdf





    [参考]

    TeraTermプロジェクトのサイト
    ja.osdn.net/projects/ttssh2/
     

  • こんにちは。NoMaYです。

    TBボードのユーザーズマニュアルによると、以下の場合にはTBボードの部品面とハンダ面でパターンカットを行った上で外部電源で動作させるようにしないといけないのですが、外部電源を必要とするユースケースがひとつ想定外になっているような気がします。(恐らくRXマイコン学習基板という位置付けで開発されたからなのだと思いますが、、、)

    TBボードが想定している外部電源を必要とするユースケース

    (1) 評価MCUを任意の電圧で動作させる場合
    (2) USBの電流容量では不足する場合

    良くある外部電源を必要とするユースケースだと思うけれども想定外になっているもの

    (3) 近くにパソコンが無い場所で使用する場合

    そして、(3)では、機能追加やバグ修正を行おうとすると、パターンカットした箇所をリペアしてUSB接続で使えるように戻さないといけないのですが、機能追加やバグ修正の度にリペアするというのはさすがに面倒だと思います。(それより、E2Liteエミュレータを買ってしまうか、もう1枚TBボードを買ってしまうか、のが良い?) 回路図を見たところ、パターンカットした後にTBボードのオンボードエミュレータ側からVCC/GND/RESET/FINED/GND(及び5V/3.3V)を引き出せるようにピンヘッダ(又はピンソケット)を立てられるようになっていましたので、そことTBボードのマイコン側を繋ぐ経路を探して写真に書き込んでみました。幸い、VDD/GNDとRESET/FINED/GNDの2組に分けて、それぞれまとめて引き回せそうです。また、VDD/GNDの組だけでなくRESET/FINED/GNDの組も、繋ぐ先はRX231/RX130/RX65NのどのTBボードでも同じ箇所で済みます。



    [参考]

    以下、TBボードのユーザーズマニュアルの画面コピーです。また、図ではハンダ面カットパターンの様子が分かり難いですので、その部分のTBボードの写真も付けました。

    www.renesas.com/jp/ja/doc/products/mpumcu/doc/rx_family/r20ut4168jj0101-rxtb.pdf

  • こんにちは。NoMaYです。

    TBボードのサンプルプログラムを基にxxx_main.cをxxx_main.cppにしてスマートコンフィグレータが生成した関数を呼び出せるようにして動かしてみました。(Amazon FreeRTOS Renesas RX GR-ROSEのC++プロジェクトのやり方を真似ています。) プロジェクトのファイル一式は以下の通りです。なお、CC-RXはCS+プロジェクト(rcpeファイル同梱)(CS+ V8.01+CC-RX V2.03でビルド)、GNURXはe2 studioプロジェクト(e2 studio v7.30+GNURX 4.8.4.201803でビルド)、になっています。

    tb_rx65n_scfg_ccrx_cpp_csplus_20190228.zip
    tb_rx65n_scfg_gnurx_cpp_e2v730_20190228.zip
    tb_rx130_scfg_ccrx_cpp_csplus_20190228.zip
    tb_rx130_scfg_gnurx_cpp_e2v730_20190228.zip
    tb_rx231_scfg_ccrx_cpp_csplus_20190228.zip
    tb_rx231_scfg_gnurx_cpp_e2v730_20190228.zip

    以下はプロジェクトの画面コピーです。(BSPモジュールのヘッダファイルの事情でマクロ定義で無理矢理なことをやっていたり、ワーニングレベルを上げている一方でスマートコンフィグレータが生成したソースコードに対しては(CS+はカテゴリ単位で設定出来ないので諦めて)e2 studioでワーニング無しにしていたりします。)

    CC-RX CS+


    GNURX e2 studio




    今回はスマートコンフィグレータの以下の設定画面で先日の投稿と同じIDコードを設定しています。

    RX130とRX231


    RX65N

  • In reply to NoMaY:

    NoMaYさん

    シェルティです、こんにちは。
    ターゲットボードご活用ありがとうございます。

    企画者からコメントを貰ってきました。
    ---企画者コメント
     NoMaYさんのご指摘・ご推測の通りであり、他の製品にも考慮すべきユースケースですので、
     組込マイコンユーザの貴重な意見として受け止め、これからの製品仕様決定に生かしていきます。
    ---

    ここからは開発者側(正直ベース)のコメントです。
    ---開発者コメント
     ・製造原価を可能な限り下げてお客様の購入単価を下げたかった
     ・クロックと電源周りの設計はスタンドアロン動作/エミュレータ接続を見越してもう少し時間をかけるべきであった
      (早急にターゲットボードを市場投入したかった背景ありユースケースの想定が不十分だったように思う)
    ---

    今後とも情報交換させていただきますと幸いです。
    私も引き続きソフトウェア面から開発環境整備の支援をさせていただいております。

    以上です
  • In reply to シェルティ:

    シェルティさん、こんにちは。NoMaYです。

    こちらも、ご連絡有難う御座います。また何か気付いたことがありましたら、投稿しようと思います。(そういった話とは別に、ネタ用に(と言う訳では無いですが)秋月さんやマルツさんで入手したものが実は未消化だったり、投稿したサンプルプロジェクトの拙い点にここ何日かの間に気付いてしまったり、とかありますので、この後も、まだ、このスレッドは続きそうです。)

  • こんにちは。NoMaYです。

    以前(3ヶ月程前)に投稿した、TBボードのサンプルプログラムを基にxxx_main.cをxxx_main.cppにしてスマートコンフィグレータが生成した関数を呼び出せるようにしたプロジェクトですが、それらでBSPモジュールのヘッダファイルの事情でマクロ定義で無理矢理なこと(そもそもC++ソースでありながら__STDC__を定義すること(且つ値を199901Lとすること))をやっていたのが裏目に出てしまい、GNURXの場合にstdio.h等をインクルードするとstdio.h等の中の__strict(C99予約語)がC++ソースでコンパイルエラーを誘発することに気付きました。(下の画面コピーを参照して下さい。) そこで修正版を作成しました。

    また、その際に、以下のことも実施してみました。

    ・GNURXの場合はrx-elf-size.exeを実行してtext/data/bssのセクションサイズを表示させる
    ・e2 studio(GNURX/CC-RX)の場合はツールチェイン未設定だったらFAQのURLを表示させる
    ・別スレッドでのRXスマートコンフィグレータ生成コード不具合に対処する(RX65NだけでなくRX231/RX130でも)
    ・GNURXの場合もワーニングレベルを上げる(以前の投稿で意図的にワーニング無しにしたのは失策でした)
    ・GNURXの場合に出るワーニングで厄介なこと無く対処出来るものはワーニング解消コードを記述する
    ・別スレッドでGNURXでsprintf/snprintfのフォーマット文字列ワーニングがint32_t/uint32_tで出たので細工する
    ・別スレッドでGNURXでsprintf/snprintfを使うとスタックサイズがギリギリなことに気付いたので増やす
    ・xxx_main.cpp版だけでなくxxx_main.c版も追加する
    ・CS+プロジェクトにはe2 studio用.project/.cproject等も同梱する
    ・GNURXプロジェクトでもCS+プロジェクトと同様にDefaultBuildフォルダを使う
    ・RXスマートコンフィグレータをv2.1.0に変える
    ・e2 studio/GNURXをv7.40/2019q2(4.8.4.201902)に変える(CS+/CC-RXはV8.01/V2.03のまま同じ)

    以下、プロジェクトのファイル一式です。(zipファイル(CS+用はe2 studio用.project/.cproject等を同梱)はe2 studioに直接インポート可能です。) [追記] RX130版に別スレッド「RX130のFITのBSPで必ずサブクロック発振安定時間待ち(always wait sub-clock oscillation stabilization time ≒ 1.3sec)しているのは妥当なのかな?」の修正内容を反映させました。

    tb_rx65n_scfg_ccrx_c_csplus_20190506.zip
    tb_rx65n_scfg_ccrx_cpp_csplus_20190506.zip
    tb_rx65n_scfg_gnurx_c_e2v740_20190507.zip
    tb_rx65n_scfg_gnurx_cpp_e2v740_20190507.zip
    tb_rx231_scfg_ccrx_c_csplus_20190508.zip
    tb_rx231_scfg_ccrx_cpp_csplus_20190508.zip
    tb_rx231_scfg_gnurx_c_e2v740_20190507.zip
    tb_rx231_scfg_gnurx_cpp_e2v740_20190507.zip
    tb_rx130_scfg_ccrx_c_csplus_20190508.zip
    tb_rx130_scfg_ccrx_cpp_csplus_20190508.zip
    tb_rx130_scfg_gnurx_c_e2v740_20190507.zip
    tb_rx130_scfg_gnurx_cpp_e2v740_20190507.zip
    tb_rx130_scfg_ccrx_c_csplus_20190518.zip
    tb_rx130_scfg_ccrx_cpp_csplus_20190518.zip
    tb_rx130_scfg_gnurx_c_e2v740_20190518.zip
    tb_rx130_scfg_gnurx_cpp_e2v740_20190518.zip

    以下、画面コピーです。

    GNURXの場合にstdio.h等をインクルードするとstdio.h等の中の__strict(C99予約語)がC++ソースでコンパイルエラーに


    GNURXの場合はrx-elf-size.exeを実行してtext/data/bssのセクションサイズを表示


    e2 studio(GNURX/CC-RX)の場合はツールチェイン未設定ならFAQのURLを表示(コードページが932以外ならen-supportを)
    https://ja-support.renesas.com/knowledgeBase/18367361
    https://ja-support.renesas.com/knowledgeBase/17797630


    CS+の画面コピー:xxx_main.cpp (CC-RX) の場合


    CS+の画面コピー:xxx_main.c (CC-RX) の場合


    e2 studioの画面コピー:xxx_main.cpp+GNURX の場合





    e2 studioの画面コピー:xxx_main.c+GNURX の場合




    e2 studioの画面コピー:xxx_main.cpp+CC-RX の場合


    e2 studioの画面コピー:xxx_main.c+CC-RX の場合

  • こんにちは。NoMaYです。#前の投稿の続きです

    RXスマートコンフィグレータの設定は、以下の画面コピーの通り、[コード生成設定]→[生成条件]をデフォルトの[コンポーネントが存在する場合は何もしない]にしてコード生成して下さい。理由は、ワーニングを解消する為にr_bsp_config.hに記述した以下のコードが消失しないようにする為です。(別スレッドでのRXスマートコンフィグレータ生成コード不具合に対処するコードとは別ものです。)



    CC-RX  RX65N/RX231  r_bsp_config.h

    /* Workaround for compiler warnings when warning level is set to high */
    #define BSP_MCU_CPU_VERSION                         (2)

    GNURX  RX65N/RX231  r_bsp_config.h

    /* Workaround for compiler warnings when warning level is set to high */
    #define BSP_MCU_CPU_VERSION                         (2)

    /* Workaround for compiler warnings when warning level is set to high */
    void excep_supervisor_inst_isr(void) __attribute__ ((interrupt));
    void excep_access_isr(void) __attribute__ ((interrupt));
    void excep_undefined_inst_isr(void) __attribute__ ((interrupt));
    void excep_floating_point_isr(void) __attribute__ ((interrupt));
    void non_maskable_isr(void) __attribute__ ((interrupt));

    /* Workaround for compiler warnings when warning level is set to high */
    void r_undefined_exception(void);
    /*uint32_t*/ unsigned long get_iclk_freq_hz(void);
    /*uint32_t*/ unsigned long charget(void);
    void charput(/*uint32_t*/ unsigned long output_char);

    GNURX  RX130  r_bsp_config.h

    /* Workaround for compiler warnings when warning level is set to high */
    void excep_supervisor_inst_isr(void) __attribute__ ((interrupt));
    void excep_access_isr(void) __attribute__ ((interrupt));
    void excep_undefined_inst_isr(void) __attribute__ ((interrupt));
    void excep_floating_point_isr(void) __attribute__ ((interrupt));
    void non_maskable_isr(void) __attribute__ ((interrupt));

    /* Workaround for compiler warnings when warning level is set to high */
    void r_undefined_exception(void);
    /*uint32_t*/ unsigned long get_iclk_freq_hz(void);
    /*uint32_t*/ unsigned long charget(void);
    void charput(/*uint32_t*/ unsigned long output_char);

    なお、ワーニング解消コードとしては他にも以下のコードを記述していますが、Start user code ~ End user codeの区間に記述していますので、これらに関してはRXスマートコンフィグレータの設定が[既存のコンポーネントに上書きする]になっていても消失しません。

    CC-RX/GNURX  RX65N/RX231/RX130  r_cg_macrodriver.h

    /* Start user code for function. Do not edit comment generated here */

    ...略...

    /* Workaround for compiler warnings when warning level is set to high */
    void R_CGC_Create_UserInit(void);

    /* End user code. Do not edit comment generated here */

    CC-RX/GNURX  RX65N/RX231/RX130  Pin.c

    /* Start user code for include. Do not edit comment generated here */
    #include "Pin.h"
    /* End user code. Do not edit comment generated here */

    ちなみに、R_CGC_Create_UserInit関数に関しては、一応、以下の宣言があることにはあるのですが、CC-RXもGNURXも、ワーニングレベルを上げると、この宣言自体でワーニングが出てしまいます。

    CC-RX/GNURX  RX65N/RX231/RX130  r_smc_cgc.h

    void R_CGC_Create_UserInit();

    CC-RXの場合

    M0523076: Function declarations should have prototype

    GNURXの場合

    function declaration isn't a prototype [-Wstrict-prototypes]

    また、GNURXの場合は、int32_t/uint32_tの定義に以下の細工をしました。(またも愚策か?) 理由は、別スレッドでGNURXでsprintf/snprintfのフォーマット文字列ワーニングがint32_t/uint32_tで出た為です。(今回のプロジェクトではsprintf/snprintfを使っていませんが。) 例えば、%dをこれらの型の変数に適用するとフォーマット文字列ワーニングが出るのですが、適用するフォーマット文字列が%ldならばワーニングは出ない、というものでした。CC-RXの場合は、(そもそもそういうチェックをしていないので)%dでワーニングが出ることは無く、(ソース共有化の為にGNURXに合わせようとして)%ldとすることにはどうも違和感があります。そこで以下の細工をしてみました。(ただし、もともと%ldにしてあるソースですと、逆に、これがフォーマット文字列ワーニングを誘発してしまいますが、、、)

    GNURX(/CC-RX)  RX65N/RX231/RX130  RenesasRX.h/StdAfx.h

    #if defined(__GNUC__)

    /* A workaround for unexpected warnings because -Wformat option treats int32_t/uint32_t
     * not as signed int/unsigned int but as signed long/unsigned long.
     */

    #ifdef __INT32_TYPE__
    #undef __INT32_TYPE__
    #define __INT32_TYPE__ signed int
    #endif

    #ifdef __UINT32_TYPE__
    #undef __UINT32_TYPE__
    #define __UINT32_TYPE__ unsigned int
    #endif

    #endif

    あと、GNURXの場合は、リンカスクリプトでスタックサイズを以下のように増やしています。理由は、別スレッドでGNURXでsprintf/snprintfを使うとスタックサイズがギリギリなことに気付いた為です。(今回のプロジェクトではsprintf/snprintfを使っていませんが。) スタックサイズはCC-RXの場合のスタックサイズに合わせました。

    以前の版  GNURX  RX65N/RX231/RX130  linker_script.ld

        } > ROM
        .ustack 0x200: AT(0x200)
        {
            _ustack = .;
        } > RAM
        .istack 0x100: AT(0x100)
        {
            _istack = .;
        } > RAM
        .data 0x204: AT(_mdata)
        {

    今回の版  GNURX  RX65N/RX231/RX130  linker_script.ld

        } > ROM
        .ustack 0x4: AT(0x4)
        {
            . += 0x1000;
            _ustack = .;
        } > RAM
        .istack 0x1004: AT(0x1004)
        {
            . += 0x400;
            _istack = .;
        } > RAM
        .data 0x1404: AT(_mdata)
        {

    そして、以前に投稿したプロジェクトは、BSPモジュールのヘッダファイルの事情でマクロ定義で無理矢理なこと(そもそもC++ソースでありながら__STDC__を定義すること(且つ値を199901Lとすること))をやっていたのが裏目に出てしまい(これは愚策でした)、GNURXの場合にstdio.h等をインクルードするとstdio.h等の中の__strict(C99予約語)がC++ソースでコンパイルエラーを誘発してしまいますが、今回投稿したプロジェクトでは、BSPモジュールのr_typedefs.hというヘッダファイルの代替版を作って使うようにしました。(CC-RXの場合も同じやり方に合わせました。) r_typedefs.hは、C99モード以前のCの場合にBSPモジュールでインクルードされますが、本来BSPモジュール(とRXスマートコンフィグレータ)で想定されていないC++モードでもインクルードされます。ですが、その中にC++モードでは都合の悪い記述が含まれていますので、それらの記述をC++モードでは除外するようなやり方(以下の青文字箇所)にしました。

    オリジナル版  GNURX/CC-RX  RX65N/RX231/RX130  r_typedefs.h

    /******************************************************************************
    Macro definitions
    ******************************************************************************/
    #define bool _Bool
    #define false 0
    #define true 1

    /******************************************************************************
    Typedef definitions
    ******************************************************************************/
    typedef signed char int8_t;
    typedef unsigned char uint8_t;
    typedef signed short int16_t;
    typedef unsigned short uint16_t;
    typedef signed long int32_t;
    typedef unsigned long uint32_t;
    typedef signed long long int64_t;
    typedef unsigned long long uint64_t;

    代替版  GNURX/CC-RX  RX65N/RX231/RX130  r_typedefs.h

    #ifndef R_TYPEDEFS_H
    #define R_TYPEDEFS_H

    #if defined(__CCRX__)

    #ifndef __cplusplus
    #define bool _Bool
    #define false 0
    #define true 1
    #define NULL 0
    #endif

    typedef signed char int8_t;
    typedef unsigned char uint8_t;
    typedef signed short int16_t;
    typedef unsigned short uint16_t;
    typedef signed long int32_t;
    typedef unsigned long uint32_t;
    typedef signed long long int64_t;
    typedef unsigned long long uint64_t;
    #ifndef __cplusplus
    typedef unsigned int _Bool;
    #endif
    typedef unsigned long size_t;

    #elif defined(__GNUC__)

    #include <stdint.h>
    #ifndef __cplusplus
    #include <stdbool.h>
    #endif
    #include <stddef.h>

    #endif

    #endif

     

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