ＲＸ６５Ｎには、描画をブーストするＤＲＷ２Ｄ描画エンジンがある。
ただ、ハードウェアーレジスタの詳細は公開されておらず、Ｃ言語による操作ライブラリが公開されている。
今までは、フレームバッファに対する描画は、ソフトウェアーによる描画のみを使っていたが、当然ハードウェアーの方がパフォーマンスは高く、描画中は、他の処理を実行出来る為、効率も良さそうだ。
また、ＤＲＷ２Ｄの描画機能は、アンチエリアス付の描画が行え、「線幅」の概念があるので、かなり柔軟で品質の高い描画が簡単に行える。

そこで、ＤＲＷ２Ｄライブラリの機能をＣ＋＋から呼び出すラッパーを実装してみた。
※ＤＲＷ２Ｄライブラリのバージョンは１．０２をベースにしている。

ＤＲＷ２Ｄの基本的な動作は、メモリー上に描画コマンド・リストを定義しておき、その先頭ポインタを描画エンジンに渡す事で描画を行う仕組みとなっている。

描画状況により、割り込みが起動でき、ＤＲＷ２Ｄライブラリでは、標準的に割り込みサービスを呼び出すように設計されている。

「drw2d_mgr」クラスでは、初期化で、割り込みベクターを登録している。
「void drw_int_isr(void);」はＤＲＷ２Ｄライブラリの割り込みサービスの入り口で、それを登録しておけば良い、ただ、この割り込みは、グループベクタＡＬ１になっていて、「icu_mgr」クラス内の AL1 dispatch クラスが、内部で振り分けを行うようになっている。
※割り込み関数アトリビュートを付けないようにしなければならない。

extern "C" {
    extern void drw_int_isr(void);
};
 //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    /*!
        @brief  DRW2D 制御／マネージャー
        @param[in]  DRW     DRW2D クラス
        @param[in]  XSIZE   X 方向ピクセルサイズ
        @param[in]  YSIZE   Y 方向ピクセルサイズ
        @param[in]  PXT     ピクセル・タイプ
    */
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <class DRW, int16_t XSIZE, int16_t YSIZE, glcdc_def::PIX_TYPE PXT>
class drw2d_mgr {

...

    icu_mgr::install_group_task(DRW::get_irq_vec(), drw_int_isr);

...

};

DRW2Dの初期化は、以下のように行うようで、「drw2d_mgr」クラスの初期化「start();」から呼んでいる。
この呼び出し後、DRW2Dエンジンを利用出来るようだ。

    d2_ = d2_opendevice(0);
    d2_inithw(d2_, 0);
    rb_ = d2_newrenderbuffer(d2_, dlis, stsz);

「d2_newrenderbuffer」のプロトタイプは以下のようになっている。
dlis: initialsize - number of displaylist entries in the first page (minimum is 3)
stsz: stepsize - number of displaylist entries in following pages (minimum is 3)

内部で「malloc」を使ってメモリを割り当てているので、固定長で使えるように改修する必要があるかもしれない・・

DRW2DライブラリのAPIは非常に豊富に用意されているが、とりあえず、良く使いそうな物だけラップした。
また、座標系のクラスなどを積極的に利用するようにした。
ＤＲＷ２Ｄライブラリの構成はＯｐｅｎＧＬのコマンドストリームの考え方に近いので（高速、柔軟性、機能性を追及すると、大体、このような構成になる）マネージャーを実装するのは比較的やりやすい。

とりあえず、基本が出来たので後は、スプライトなどテクスチャーの描画などだ、フォントが一通り描画できるようになったら、ソフトウェアーのエンジンと入れ替えたい・・・

drw2d_mgr.hpp

部屋をかたずけていたら、ＮＥＳのコントローラーが出てきた、本体は無い、多分これは、２０年くらい前のもので、その時務めていた会社（ライブプランニング）からＮＥＳのソフトと本体など借りた時（丁度「暴れん坊天狗」の NES 版「Zombie Nation」を作っていた頃だ）本体は返したがコントローラーだけ自宅に置き去りになったものと思う。

折角なので、RX65N Envision kit のＮＥＳエミュレーターのパッドとして使ってみた。

ネットを探して、コントローラーのピンアサインを探して、コネクタを付けた。

白：Ｖｃｃ（電源、通常＋５Ｖ）
茶：ＧＮＤ（電源、０Ｖ）
橙：Ｐ／Ｓ（パラレル、シフト切り替え）
赤：ＣＬＫ（クロック）
黄：ＯＵＴ（シリアル出力）

ところが・・・
ボタンを押しても反応が無い・・・
配線を確認したが、問題無さそう、ファミコン互換パッドでは問題無く動作する。

これは多分、クロックの遅延が足りないものと思い、クロックの遅延ループを６回から２０回にして動作するようになった。
この純正パッドはＣ－ＭＯＳ「４０２１Ｂ」を使っているが、互換パッドに使われているＩＣは、４０２１Ｂの互換ＩＣで、クロックの許容範囲が広いものと思う。

uint8_t update(uint32_t cnt = 20) noexcept
{
    P_S::P = 0; // seirial
    uint8_t d = 0;
    for(uint8_t i = 0; i < 8; ++i) {
        d <<= 1;
        if(!OUT::P()) ++d;
        CLK::P = 1;
        utils::delay::loop(cnt);
        CLK::P = 0;
        utils::delay::loop(cnt);
    }
    P_S::P = 1; // parallel
    data_ = d;
    return data_;
}

上記のように、ループ数を「６」から「２０」に変更した。
※１２０ＭＨｚ動作の場合なので、もっとＣＰＵクロックが速い場合は調整する必要がある。

static void loop(uint32_t cnt)
{
    while(cnt > 0) {
        asm("nop");
        --cnt;
    }
}

loop 関数は上記のように「nop」を実行するだけのものだ。

RX65N Envision Kit には、上記のように接続してある。

FAMIPAD.hpp

今回の話とは関係無いが、写真の圧着工具、安い割りにはなかなかに良い！
この小さいコネクタの圧着では、まともにできずに、ラジオペンチで修正したり、最悪ハンダ付けしたりと苦労してきたが、この工具なら、ほぼ間違いなく綺麗に圧着できる。
専用の工具は非常に高価で、たいてい１種類のピンにしか対応しないので、DIYでは買う機会は無いのだが、この工具ならそれに匹敵する、すばらしい！

ＲＸ６６Ｔは、まだデバイスが入手できていないので評価はまだだが、ＲＸ２４Ｔ、ＲＸ６５Ｎ、ＲＸ７１Ｍ（ＲＸ６４Ｍ）の全般的な性能評価を行った。
※ＲＸ６４Ｍは最大動作周波数がＲＸ７１Ｍの半分で、他はＲＸ７１Ｍと同等なので、スルーしている。
又、最大動作周波数でベンチマークしている。

今回の評価では、「レイトレース・プログラム」を使った。
現実的には、このベンチマークでは不十分とも思えるが、浮動小数点演算が混在したプログラムを走らせるようなアプリの評価では、整数演算とのバランス（浮動小数点の比率が高めだけど・・）で、十分参考になると思える。
※整数演算のみの評価では、他のマイコンと比べるとＲＸマイコンは、ＣＩＳＣ系で、ルネサスが独自に工夫しており、実行効率が優れている為、評価するまでもなく速い。
※現状では、消費電力辺りの能力、強力な各種ペリフェラルなど、色々な面で、敵ナシだと思う。（gcc を使わない場合の開発環境が有料、又、やはりコストは多少高い、その点で、他より劣る）

ＲＸ２００シリーズなどのＦＰＵを持たないマイコン（RXv1コア）は、手持ちが無いので評価していないが、コストの問題から下位のシリーズを使う場合でも、ＣＰの高いＲＸ２４Ｔの存在があり（ＲＸ２２０とあまりコストが変わらないと言うのは言い過ぎだと思うが・・）低価格路線では、それを目安にする事ができる。
※自分としては、ＲＸ２００シリーズはＦＰＵを持たないし、動作周波数も低く、あまりメリットを感じない。
これは多分、ＲＬ７８などの８／１６ビットマイコンとの差別化で、同じような価格帯で、性能差が大きすぎると差別化が難しい為と思われる、それでも、３２ビットコアのメリットは大きい。
※ＲＸマイコンが、ＡＲＭ、ＰＩＣ３２、ＥＳＰ３２に比べて割高感があるので、「敬遠」している人がいるかもしれないが、たとえば、ＲＸ６５Ｎと同等の機能を持った、ＡＲＭと比べた場合、同等の性能を出す事が出来るシリーズは無かったり、価格もそれほど変わらない場合も多い。
今回評価していないものの、RX630（100MHz）などもあり、ＲＸマイコンは色々な場面で有用だと思える。

型番	動作周波数 [MHz]	FPU	ROM	RAM	実時間 [ミリ秒]	価格 [円]
R5F524TAADFP RX24T	80	○	256K	16K	1670	974 (572/10)
R5F565NEDDFB RX65N	120	○	2M	640K	812	1910 (1320/10)
R5F571MFDDFC RX71M	240	○	2M	512K	410	2600 (1940/10)
ESP32（参考）	160	○	4M	520K	13000	550
STM32F4（参考）	72	×	1M	192K	52000	320
STM32F756BGT6（参考）	216	○	1M	320K	620	1820 (1250/10)

備考：
・コンパイラは「rx-elf-gcc 6.4.0」で、最適化「-O3」でバイナリーを作成。
・ESP32 の結果が悪すぎるのは、LCD とのインターフェースに問題があるように思う。（描画のオーバーヘッドが大きいものと思う）
・内臓メモリのサイズと値段は相関があるので、単純にCPを比べる事は出来ない。
・ESP32、STM32F4、STM32F7 の結果は、ネット情報による。
・RX65NのCPが意外に高い、LCD接続が容易で、トータルで考えた場合、バランスが良い。
・RX71M、RX65Nは、フレームバッファを使い、描画コストが低い、STM32F7も同様の方式と思われる。
・RX24Tは、RAMが少ないので都度描画を行っている、描画コストがそれなりにある。
・ベンチマークに使ったソースは、Arduino 向けの物なので、細かい部分で、動作が微妙に異なり、条件も違う。
・RX マイコンでは、float の平方根を求める専用命令（FSQRT）を使っている。（STM32F7もそれは同様なようだ）

かなり昔に、Aitendo でセールしてたＴＦＴ－ＬＣＤをＲＸ７１Ｍに接続してみた。

２．２インチ、３２０ｘ２４０、６４Ｋカラー、コントローラーは、Ｒ６１５０５

ＬＣＤコントローラーのバスをデータラインに直接接続するのがゴールだったが、動作しない・・

ＲＸマイコンのバス設定は面倒なので、最初、Ｉ／Ｏポート制御でコントローラーの初期化を実験してみた。
しかし、何をやっても、思ったように動作しない・・
※初期化コードは Arduino 用をネットで拾ってきて、適当に改造して実験していた。

相当、色々やったが、不安定で動作しない・・・
※数回に１回、初期化だけ動作する事はあるが、ピクセルの描画では、おかしな動作をしてまともに動作しない。

それで、しばらく放置してた、２０１９年になって、そーいえば８ビットバスで試して無かったなぁーってふと思い、「IM」ピンをGNDからVCCに変更（８ビットバス）して、１６ビットバス用から８ビットバス用に修正して試してみたら、普通に動作する。

何で？
８ビットバス接続では、DB8～DB15 を使う、１６ビットバスでは、DB0～DB15 を使う。
以前に、DB0～DB15 の結線に誤りがあるのかと思い、調べたが問題無い・・

再度、DB0～DB7 の結線を調べたら、DB6 の結線が間違っていた・・
※PD6(145) に繋ぐべきところが、PG0(146) に接続していた・・・
最近、視力が落ちて、細かい配線が見難い（車の運転には支障無い視力）事が大きな要因と思うが、「メガネ」を作りにいくのが億劫で、先延ばしにしていた。

Start TFT sample
ID: C505
Probe TFT OK to start...
Render time: 630ms (1)

ところで、RX71M の 240MHz 動作では、３２０ｘ２４０のレイトレースベンチマークは上記のように０．６３秒だった。
ただ、ピクセルの描画コマンドをコントローラーに送る際のオーバーヘッドが大きいので、実際には、もっと速いと思うが、素晴らしいパフォーマンスだ！
ＲＸマイコンは、本当に優秀なマイコンだと思う、使わない理由が無い、逆に何故ＡＲＭやＰＩＣを使うのか問いたいくらいだ。

https://github.com/hirakuni45/RX/tree/master/rx71m_LCD
※一応、テストで使っているプロジェクト