RX62Nのフラッシュ書き換えツール実装でまた発見!

基板の提供ありがとう~

基板の提供を受けました、「Lathe」さん大変ありがとうございます。


RX62N の フラッシュ書き換えツール対応

RX62N の C++ フレームワーク対応も、ほぼ出来上がり、これで、本格的に使えるようになった感じ。

一番厄介だった、MTU 関係も、何とかなり、ブログに記事をまとめていたのだが、


とりあえず、フラッシュの書き換えは、「Renesas Flash Programmer V3.06.01(無償版)」を使って USB 接続で書き換えしていた。

しかし、書き換えの度に、USB 接続をしたり切ったりするのが何だかなぁーと思って、遅くてもシリアルで書き換え出来るようにしておこうと思い、SCI1 にコネクタを接続しておいた。

そして、フラッシュ書き換えツールも対応しておこうと思い、ブートモードの解説を観ていたら、どうやら、これは RX63T にかなり近い仕様だと判った。
RX63T のリソースを使い、それを改造すれば割と簡単に対応可能だと判り実装を始めた。


奇妙な事を発見

まず、最初は、

  • ブートモードで起動
  • 接続
  • シリアルの通信速度をキック
  • デバイス情報の取得
  • 書き換え

ざっと、こんな感じなのだが、その過程で、「デバイス情報取得」で奇妙な事が起こっていた。

 % rx_prog -d RX62N --verbose
# Platform: 'Cygwin'
# Configuration file path: 'rx_prog.conf'
# Device: 'RX62N'
# Serial port path: 'COM7'
# Serial port speed: 230400
# Erase Page Wait: 2000 [uS]
# Write Page Wait: 5000 [uS]
# Serial port alias: COM7 ---> /dev/ttyS6
# Serial port path: '/dev/ttyS6'
Connection OK. (RX62x)
#01/01: Device: RX600 Series
#01/01: Device ID: 0x35307936
#01/01: Clock Mode: 0x00
#01/02: Multiplier: 1, 2, 4, 8
#02/02: Multiplier: 1, 2, 4, 8
#01/02: Frequency Min: 8 MHz, Max: 100 MHz
#02/02: Frequency Min: 8 MHz, Max: 50 MHz
#01/01: Change baud rate: 115200
#01/01: Boot Area: FF7FC000, FF7FFFFF
#01/01: Area: FFF80000, FFFFFFFF
#01/54: Area: FFFFF000, FFFFFFFF
#02/54: Area: FFFFE000, FFFFEFFF
#03/54: Area: FFFFD000, FFFFDFFF
#04/54: Area: FFFFC000, FFFFCFFF
#05/54: Area: FFFFB000, FFFFBFFF
#06/54: Area: FFFFA000, FFFFAFFF
#07/54: Area: FFFF9000, FFFF9FFF
#08/54: Area: FFFF8000, FFFF8FFF

...

#50/54: Area: 00102000, 001027FF
#51/54: Area: 00101800, 00101FFF
#52/54: Area: 00101000, 001017FF
#53/54: Area: 00100800, 00100FFF
#54/54: Area: 00100000, 001007FF
#01/01: Program size: 256 Bytes
#01/01: ID Protect: false

このデバイスは、「R5F562N7」なので、「フラッシュ:384K、RAM:64K」品のハズなので、
「Area:」は、FFFA0000 から始まるハズなのだが・・・

ん??

これは、もしや・・・

物理的なデバイスは、全て「R5F562N8」と同じ物で、デバイスIDで識別しているだけなのでは?

そこで、Makefile のデバイス名を切り替えて、プログラムを書き換えると、普通に書き換え出来たーーー

# BlueBoard-RX62N_100pin
#DEVICE     =   R5F562N8
# FRK-RX62N (CQ出版)
#DEVICE     =   R5F562N7
DEVICE      =   R5F562N8
USER_DEFS   =   CQ_FRK
Memory Configuration

Name             Origin             Length             Attributes
RAM              0x00000000         0x00017a00         w
USTACK           0x00017e00         0x00000004         w
ISTACK           0x00018000         0x00000004         w
ROM              0xfff80000         0x0007ffd0         w

そして普通に動く!!!

やっぱりね・・

まぁ、そういう事なのだろう。

驚いた事に、ルネサス、フラッシュプログラマーでも、普通に書き換えが出来、動くようだ・・

とゆー事は、「刻印」が違うだけなのか・・・


まぁ、ROM が 384K から 512K に増えても、そんなに大きなプログラムを作らない限り変わらないかもしれないが、RAM が 64K から 96K だと、やはり使いかってが違うと思う。


まとめ

これは、今回のボードに載っているデバイス特有の事なのかもしれない・・

このボード、かなりの数を出荷したと思うが、当時、「7」の384K品が不足していた為、512K品を刻印だけ変えて出荷したとも考えられる。

他に試せるデバイスを持っていないので、判らないが・・・

まぁ、どちらにしても、うれしい誤算である事は言うまでもない。

このボードを持っている人は試してみる事を勧める~

R8C、RX開発環境のアップデート

R8C の開発環境が作れないとのツイートをもらう・・

先日、Twitter で 過誤出来ないツイートをもらった。

ツイートは短く、詳細は不明なので、実際にどんな事が起きているのか判らなかった。

何度かやりとりをする中で、どうやら、これは Linux 環境で発生している事が判った。

その要因は、最新の gcc 環境(Version 11)などで、gcc-4.9.4 の C++ ビルドで失敗する事が判った。

そういえば、Windows の MSYS2 環境もしばらくアップデートしていない、そこで、まずは、MSYS2 をアップデートする事から始めた。
※Linux 環境は、ノートPC にあり、古いので、新しい環境に入れ直す必要があり、確認するのも時間がかかる。

pacman -Sy pacman
pacman -Syu

この段階で、データベースの更新に失敗して、先に進まない・・

MSYS2 は、かなり更新しているようで、根本的にシステムが大幅に変わったようだ、そこで、インストールからやり直す事にした。

念の為、MSYS2 のコア部分、「C:\msys64」をリネームして、残しておいた。

最新版をインストールして、必要なツールをインストール。
※複数パッケージのインストールが、マルチスレッドで同時進行するようになっているw

MSYS2 はアイコンが少し新しくなり、大きな変更があったようだ。

また、新たな環境が二つ追加された:

  • MSYS
  • mingw32
  • mingw64
  • ucrt64(追加)
  • clang64(追加)

※追加された環境が、どのような特徴があるのか調べていない。(clang64 は何となく判る)

MSYS のカレント gcc は11系になっている。

gcc (GCC) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

次に、R8C 用 gcc のビルドにとりかかる。
gcc のビルドは、MSYS で行う。(この環境がもっとも Linux などに近い)

手順を進めていって、やはり、gcc C++ の構築でエラーが発生して止まる・・・

うーーん、これは、どうしたものか・・・

そもそも、gcc-4.9.4 は古すぎると以前から思っていた。
しかし、開発環境を変更する事で、発生する別の問題を恐れて「まぁ動いているから枯れた方がいいかな」とも思っていた。

この機会に、手始めに R8C の開発環境をアップデートして、gcc-11 でエラー無くコンパイル出来るようにした方が建設的ではと思った。
この段階で、エラーを報告してくれた人は、ネットの情報を精査して、configure で生成された Makefile に、C++11 のオプションを付ける事で回避したようだ。
※なるほど、その回避もあるよなぁーと思ったが、やはり、gcc のビルドで特別な事を行うのは少し抵抗がある。


RX マイコンの開発環境では、最近は GNU-RX(魔改造されている)を使っている為、素の gcc を使う事が無くなっている。

RX のツールチェインは、以下の組み合わせとなっている。

binutils-2.34
gcc-7.5.0
newlib-2.4.0

組み合わせは重要で、リリースが同じくらいのパッケージを組み合わせないと、ビルドが通っても、コンパイル中にインターナルエラーで止まったり、
出来たコンパイラで作ったバイナリーをマイコンに焼いても動作しないなど、色々なトラブルが起こったりする。

そこで、R8C(m32c-elf)のビルドを上記組み合わせで作ってみた。

ビルド途中で、エラーで、失敗する・・・

うーーーん・・・

この組み合わせは、m32c-elf では相性が悪い・・・

そこで、少し古いバージョンの組み合わせで、色々試してみた。
m32c-elf は多分、メンテナンスされていないので、欲張らずにそこそこ新しい物で我慢する方が安全と考えた。
SSD(1TB) と、大きな主記憶(32GB)で武装された、最新の PC(Rizen7) でも、gcc のビルドは、そこそこの時間を要する。

色々、試して:

  • binutils-2.28.1.tar.gz
  • gcc-6.4.0.tar.gz
  • newlib-2.4.0.tar.gz

この組み合わせで、ビルドが通った。


boost 問題・・・

r8cprog など、一部のコードは、boost を使っている。

本来なら、MSYS 環境に boost を入れるのが良いと思うが、mingw64 などには対応しているが、MSYS 環境には無い。
そこで、mingw64 環境に入れた boost を間借りする形で使っていた。
しかし、新しい MSYS2 ではそのやり方では問題が発生する事が判った。

そこで、boost_1_74_0 のアーカイブを取ってきて、C ドライブのルートに展開し、そのパスを食わせる事で解決した。

この変則的なやり方は、あまりスマートとは言えないが、手順は難しく無いので、まぁ及第点だろうか・・


R8C のプロジェクトを全ビルド

新しく出来たツールチェインを使って、R8C のプロジェクトを全てビルドしてみた。

エラー無くビルドが通った。

とりあえず、「UART_sample」を動かしてみて、ちゃんと動作するバイナリーが出来る事も確認した。


RX 関係も確認

RX 関係も、一応確認した。

RX の gcc ビルドは問題無く通ったので、「良し」としたが、boost のパスは、R8C と同じく変更した。


RL78 環境

RL78 も、R8C と同じ環境にして、gcc をビルドしてみた。
これも、順調に通り、構築出来た。

しかし、プロジェクトをビルドすると、gcc がインターナルエラーで停止する・・・

rl78-elf-g++ -c  -std=c++17 -Wall -Werror -Wno-unused-variable -Wno-exceptions -Wno-unused-function -Os -mmul=g13 -DSIG_G13 -DF_CLK=32000000  -I. -I../ -I../G13  -o release/main.o main.cpp
In file included from main.cpp:15:0:
../common/format.hpp: In member function 'void utils::basic_format<CHAOUT>::out_fixed_point_(VAL, uint8_t, bool) [with VAL = long long unsigned int; CHAOUT = utils::stdout_chaout]':
../common/format.hpp:589:3: internal compiler error: in push_reload, at reload.c:1348
   }
   ^
unrecognized DWARF version in .debug_info at 6
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [Makefile:112: release/main.o] Error 1

うーーーん、これは痛い・・・

そーいえば、ルネサスさん、RL78 用に LLVM ベースのコンパイラをリリースしているんだよなぁー、アレ試してみたいんだよなぁー

今ここ。


まとめ

とりあえず、R8C、RX 関係は、何とかなったので、RL78 も何とかしたいけど、時間切れ。
Linux 環境も試しておく必要があるし、まだ、時間がかかる。

R8C の教材も中途だし、中々先に進まない。

しかし、Windows の最新環境にマッチするように改修したのは、大きな進歩と思える。

RXマイコン、RX621/RX62N のサポート

※昔に購入した RX62N が載った格安ボード、確か2000円くらいで買った覚えがあるが、現在は5000円くらいする。


古い、RX621/RX62N のサポート

RX621/RX62N は、そこそこ古いRXマイコンのグループで、C++ フレームワークの出発点となった記念すべきCPUでもある。

しかし、新しいグループがリリースされ、使わなくなり、機能的に見劣りするのと、新規に購入するのもコスト的に見合わないので、ある時期から「レガシー」として、サポートをやめてしまった。

ところが、現在、政治的な動きに係る半導体不足から、最近リリースされた新しいデバイスの購入が殆ど出来なくなっており、いつ解消するかも不透明となっている。
RX621/RX62N は、かなり昔のデバイスで、そこそこ流通しており、かなり昔に、本の付録として流通した事もあるし、秋月では、未だに販売もされている。
なので、持っている人で肥やしになってる人も少なからずいるのではないか?

最終的には、RXマイコン全制覇を目論んでいるので、そろそろ、仕組みを考えておくのも必要だと考えていたので今回のサポートは丁度良いタイミングとなっている。

速度的には、100MHz 動作で、浮動小数点演算器も持っているデバイスなので、パフォーマンス的には、現在でもそんなに悪くなく、機能もそこそこあるので、何か作る場合でも、そんなに困らないのではと思う。

それでも、新規に購入しようとするとそこそこの価格だが、秋月で購入も可能なので、入手性など考えると、サポートしない理由はない。


構成を部分的に考え直して修正

この頃のRXマイコンは、現在の豊富な機能と比べると、かなり見劣りする。

C++ フレームワークでは、機能的に異なる部分を隠蔽するような仕組みを多数使っているので、「#if」などコンパイルの制御文を駆使しなくても、かなり綺麗に実装が可能となっている。
それでいて、最適化後のコードには、余分な部分が殆ど残らないので、速度低下もなく、上位の層(アプリケーション部分)は、ほぼそのまま再利用が可能となっている。

「#if」を多用して、細かい動作を切り替えているソースを読んだ事がある人は、判ると思うが、非常に読みにくく、デバッグも困難になる。
C++ では、そんな実装方法をとらなくても、最小限の分岐だけで、かなり複雑で柔軟な構成にできる。


FIRST_sample

まずは、LED 点滅から・・・

RX62x は、クロック生成部分が、非常にシンプルで、構成が大きく異なるので、専用のクラスとし、新規に書き直した。

ポートの構成も、大きく異なるので、専用のクラスとした。

各ファイルのインクルード制御は、common/device.hpp、common/renesas.hpp で行っている。

  • なので、アプリケーション側は、「common/renesas.hpp」をインクルードするだけで良い。

また、オシロスコープを使って波形を計測、ソフト遅延のパラメーターを適正な値に調整した。

この部分、「#if」で別けているので、定数を clock_profile に定義して参照するようにしないと駄目だな・・・
※今後改修する予定。


SCI_sample

  • SCI を動かすには、割り込みが必要なので、まずは、割り込み関係をサポート
  • 構成は、RX24T に近く、部分的に流用した
  • ついでに、他マイコンで、割り込み関係に係る部分を修正した

SCI 関係のペリフェラルは、現行のRXマイコンと、初期のRXマイコンでは、かなり異なる。

大きく異なるのは、ボーレートクロック生成の仕組みとなっている:

  • 倍速モードの追加
  • ボーレート変調レジスタの追加(比較的高いボーレートの場合に、クロックを間引いて、なるべく正確なレートになるように調整)
        //-----------------------------------------------------------------//
        /*!
            @brief  シリアル拡張レジスタ (SEMR)
            @param[in]  ofs     レジスタ・オフセット
        */
        //-----------------------------------------------------------------//
        template <uint32_t ofs>
        struct semr_t : public rw8_t<ofs> {
            typedef rw8_t<ofs> io_;
            using io_::operator =;
            using io_::operator ();
            using io_::operator |=;
            using io_::operator &=;

            bit_rw_t<io_, bitpos::B0> ACS0;
            bit_rw_t<io_, bitpos::B2> BRME;       // sci[g]

            bit_rw_t<io_, bitpos::B4> ABCS;
            bit_rw_t<io_, bitpos::B5> NFEN;       // sci[g]
            bit_rw_t<io_, bitpos::B6> BGDM;       // sci[g]
            bit_rw_t<io_, bitpos::B7> RXDESEL;    // sci[g]
        };

上記は、SEMR レジスタの定義だが、「sci[g]」は、新しいRXマイコンにはあるが、RX62x には存在しない。
現行の SCI 制御クラス(sci_io.hpp)では、全てを使ってボーレートを生成しているので、そのままでは、機能の無いマイコンには使えない。

RX62x に無いフラグやレジスタを定義から外す事も可能だが、それを行うと、sci_io.hpp のコンパイルが出来なくなってしまう。

  • なので、利用しているフラグビットは、常に存在するようにしないとならない(使う、使わないだけで別ける)
  • より厳密に行うには、そのビットにアクセスしても、無意味になるように出来るけど、それはやり過ぎと思ったので・・

そこで、SCI の定義クラスに、どのビットが有効なのかを宣言しておく。

  • sci_io クラスは、それを参照して利用するか、しないかを決定する。
  • 無効なビットに書き込む場合は、「0」を必ず書くようにする。
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    /*!
        @brief  SCIa 定義クラス
        @param[in]  base    ベース・アドレス
        @param[in]  per     ペリフェラル型
        @param[in]  txv     送信ベクター
        @param[in]  rxv     受信ベクター
        @param[in]  tev     送信終了ベクター
        @param[in]  pclk    PCLK 周波数
    */
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    template <uint32_t base, peripheral per, ICU::VECTOR txv, ICU::VECTOR rxv,
        typename INT, INT tev, uint32_t pclk>
    struct scia_t : public sci_core_t<base> {

        static constexpr auto PERIPHERAL = per; ///< ペリフェラル型
        static constexpr auto TX_VEC = txv;     ///< 受信割り込みベクター
        static constexpr auto RX_VEC = rxv;     ///< 送信割り込みベクター
        static constexpr auto TE_VEC = tev;     ///< 送信終了割り込みベクター
        static constexpr auto PCLK = pclk;  ///< PCLK 周波数

        static constexpr bool SEMR_BRME = false;    ///< BRME(ボーレート微調整)
        static constexpr bool SEMR_BGDM = false;    ///< BGDM(ボーレート倍速)

最近のRXマイコンでは:

    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    /*!
        @brief  SCIg クラス
        @param[in]  base    ベース・アドレス
        @param[in]  per     ペリフェラル型
        @param[in]  txv     送信ベクター
        @param[in]  rxv     受信ベクター
        @param[in]  tev     送信終了ベクター
        @param[in]  pclk    PCLK 周波数
    */
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    template <uint32_t base, peripheral per, ICU::VECTOR txv, ICU::VECTOR rxv,
        typename INT, INT tev, uint32_t pclk>
    struct scig_t : public sci_core_t<base>, sci_core2_t<base> {

        static constexpr auto PERIPHERAL = per; ///< ペリフェラル型
        static constexpr auto TX_VEC = txv;     ///< 受信割り込みベクター
        static constexpr auto RX_VEC = rxv;     ///< 送信割り込みベクター
        static constexpr auto TE_VEC = tev;     ///< 送信終了割り込みベクター
        static constexpr uint32_t PCLK = pclk;  ///< PCLK 周波数

        static constexpr bool SEMR_BRME = true; ///< BRME(ボーレート微調整)
        static constexpr bool SEMR_BGDM = true; ///< BGDM(ボーレート倍速)
    };

RXマイコングループの違いは、以下のようになっている(#if が必要な部分)

  • SCI の基準クロックは、clock_profile に定義してあり、それを参照している。
  • RX62x の場合は「clock_profile::PCLK」、RX24T の場合は「colock_profile::PCLKB」となる。
  • SCI ハードウェアーの開始アドレスも大きく異なる。
  • RX72N などでは、割り込みの「型」も異なる。
#if defined(SIG_RX621) || defined(SIG_RX62N)
    typedef scia_t<0x00088240, peripheral::SCI0, ICU::VECTOR::TXI0, ICU::VECTOR::RXI0,
        ICU::VECTOR, ICU::VECTOR::TEI0, clock_profile::PCLK> SCI0;
    typedef scia_t<0x00088248, peripheral::SCI1, ICU::VECTOR::TXI1, ICU::VECTOR::RXI1,
        ICU::VECTOR, ICU::VECTOR::TEI1, clock_profile::PCLK> SCI1;
    typedef scia_t<0x00088250, peripheral::SCI2, ICU::VECTOR::TXI2, ICU::VECTOR::RXI2,
        ICU::VECTOR, ICU::VECTOR::TEI2, clock_profile::PCLK> SCI2;
    typedef scia_t<0x00088258, peripheral::SCI3, ICU::VECTOR::TXI3, ICU::VECTOR::RXI3,
        ICU::VECTOR, ICU::VECTOR::TEI3, clock_profile::PCLK> SCI3;
    typedef scia_t<0x00088268, peripheral::SCI5, ICU::VECTOR::TXI5, ICU::VECTOR::RXI5,
        ICU::VECTOR, ICU::VECTOR::TEI5, clock_profile::PCLK> SCI5;
    typedef scia_t<0x00088270, peripheral::SCI6, ICU::VECTOR::TXI6, ICU::VECTOR::RXI6,
        ICU::VECTOR, ICU::VECTOR::TEI6, clock_profile::PCLK> SCI6;
#elif defined(SIG_RX24T)
    typedef scig_t<0x0008A020, peripheral::SCI1, ICU::VECTOR::TXI1, ICU::VECTOR::RXI1,
        ICU::VECTOR, ICU::VECTOR::TEI1, clock_profile::PCLKB> SCI1;
    typedef scig_t<0x0008A020, peripheral::SCI1C, ICU::VECTOR::TXI1, ICU::VECTOR::RXI1,
        ICU::VECTOR, ICU::VECTOR::TEI1, clock_profile::PCLKB> SCI1C;
    typedef scig_t<0x0008A0A0, peripheral::SCI5, ICU::VECTOR::TXI5, ICU::VECTOR::RXI5,
        ICU::VECTOR, ICU::VECTOR::TEI5, clock_profile::PCLKB> SCI5;
    typedef scig_t<0x0008A0A0, peripheral::SCI5C, ICU::VECTOR::TXI5, ICU::VECTOR::RXI5,
        ICU::VECTOR, ICU::VECTOR::TEI5, clock_profile::PCLKB> SCI5C;
    typedef scig_t<0x0008A0C0, peripheral::SCI6, ICU::VECTOR::TXI6, ICU::VECTOR::RXI6,
        ICU::VECTOR, ICU::VECTOR::TEI6, clock_profile::PCLKB> SCI6;
    typedef scig_t<0x0008A0C0, peripheral::SCI6C, ICU::VECTOR::TXI6, ICU::VECTOR::RXI6,
        ICU::VECTOR, ICU::VECTOR::TEI6, clock_profile::PCLKB> SCI6C;

sci_io クラスでは、SCI に定義してある、値を参照して処理を切り替えている。

            // BGDM が使える場合、1/8 スタート
            uint32_t mtx = 8;
            uint32_t limit = 1024;
            if(!SCI::SEMR_BGDM) {  // BGDM が使えない場合 1/16 スタート
                mtx = 16;
                limit = 512;
            }
            uint32_t brr = SCI::PCLK / mtx / baud;
            uint8_t cks = 0;
            while(brr > limit) {
                brr >>= 2;
                ++cks;
                if(cks >= 4) {  // 範囲外の速度
                    port_map::turn(SCI::PERIPHERAL, false, PSEL);
                    power_mgr::turn(SCI::PERIPHERAL, false);
                    return false;
                }
            }

            // BGDM フラグの設定
            bool bgdm = true;
            if(SCI::SEMR_BGDM) {
                if(brr > 512) { brr >>= 1; bgdm = false; mtx <<= 1; }
            } else {
                bgdm = false;
            }
            bool abcs = true;
            if(brr > 256) { brr >>= 1; abcs = false; mtx <<= 1; }

C++ を知らない人は、最適化されても、余分なコードが含まれると思うかもしれないが、C++ の最適化では、参照先の状態に応じて、必要無い部分は、全て消してくれる。
テンプレートクラスでは、それが、究極的に行われる。
そして、必要な部分だけが、残る、コンパイル時に計算出来る部分は、計算され、定数が直接使われる。
※なので、constexpr などが重要な要素となる。


GNU-RX 8.3.0 の対応

今まで、RXv2 コアは、コンパイルオプション、「-misa=v2」を使っていたのだが、RXv2 コアは、昔と今では、多少異なるようだ・・・

RX62x で、「-misa=v2」でコンパイルすると、浮動小数点の計算で例外が出るようだ。
※RX24T、RX65x などでは問題無い。
結局、RX62x では、「-mcpu=RX600」とする事で、適合するコードが生成される事が判った。

以下、makefile の共通部分:

ifeq ($(RX_DEF),SIG_RX62N)
  RX_CPU = RX62N
  RX_CHOOSE = -mcpu=RX600
  LDSCRIPT  =   ../../RX62x/$(DEVICE).ld
endif

ifeq ($(RX_DEF),SIG_RX24T)
  RX_CPU = RX24T
  RX_CHOOSE = -misa=v2
  LDSCRIPT  =   ../../RX24T/$(DEVICE).ld
  PROG_VERIFY =
endif

RAYTRACER_sample

少し大きいアプリを試しておく必要があるので、浮動小数点演算などが多く含まれたプログラムを走らせてみた。

RX62x は、RXv2 コアだが、fsqrt などの命令をサポートしないようだ・・
これが利いて、96MHz ではあるが、一番遅い・・

マイコン core fsqrt 命令 周波数 [MHz] 描画方式 時間 [ms]
RX62N RX600 X 96 8 bits, port-bus 1860
RX24T RXv2 O 80 8 bits, port-bus 1224
RX65N RXv2 O 120 Frame Memory 784
RX64M RXv2 O 120 16 bits, port-bus 751
RX66T RXv3 O 160 8 bits, port-bus 602
RX72T RXv3 O 192 8 bits, port-bus 464
RX71M RXv2 O 240 16 bits, port-bus 439
RX72N RXv3 O 240 Frame Memory 361
  • 単に動かしただけで、生成した画像を観ていないが、ストールせずに走るので、ちゃんと計算しているものと思う。
  • 余裕が出来たら LCD を接続して確認したい。

まとめ

RX62x のサポートがスムーズに出来たので、頃合いをみて、次は手持ちの RX63T をサポートしようと思う。
その前に、各サンプルで、RX62x のプロジェクトを追加する必要があるけど・・

それと、rx_prog で RX62x のフラッシュを書けるようにしたいが、これは、かなり昔のプロトコルなので時間がかかりそうだ・・・


雑誌付録の RX62N 基板を持っていて、譲っても良い人は連絡をくれると助かります。