RX66Tが発表になり、デバイスが入手出来るのを待っていたが、なかなかデバイス単体で購入できる状態にならないので、RX65Nのボードを先に作ろうかと思い作業を始めた。
※169ピンのRX65Nを５個購入した（＠１５６０）
※ついでにPFCコンバーター専用ICなども購入、こちらは、CNC用インバーターなどの前段に使う予定でいる。

RX65N Envision Kit はまぁ良いのだが、惜しい部分がある。
・バッテリーバックアップがない
・RTCのクリスタルが接続されていない
・付属LCD（480x272）の視野角が狭く、表示品質がイマイチ
・無線LANがない
・SDRAMがない
・オーディオ出力がない
・バッテリー駆動系の部品などが無い
・後載せ部品など基本的な仕様
などで、本当は 最高速で動作する 240MHz の RX71M の方も捨てがたいが、DRW2Dコントローラーが魅力なので、とりあえずRX65Nで進める。
ピンアサインは RX71M、RX64M とほぼ同一なので、少し工夫すれば乗せかえる事も出来そうだが、RX71M用は、また基板を作れば良いだろう。

無線LANは、コストで有利な ESP8266 や ESP32 を繋げておけば良さそうだが、天邪鬼なので、マイクロチップ社の WiFi モジュール ATWINC1500 を乗せられるようにしておく予定でいる。
※スピードを評価したい事もあるし（ESP8266より高速に通信できると思う）、SPI 接続の代表的な物を使いたい、ただ、コストは ESP に比べると３倍くらい高い。（個数を沢山買えば、１．５倍くらいにはなりそう・・）

EDA ツールは KiCAD を使っているのだが、最新バージョン（５．０２）をインストールしたら、非常に機能が追加されており、シンプルで使いやすくなっていて驚いたー（素晴らしいとしか言い様がない！）
※ただ、４．ｘ系とファイルの互換で問題がありそうで、４．ｘ用ファイルを読み込めない場合があるようだ・・

ボードのコストは、Wifi、SDカードインターフェース、100BaseEthernet、256Mbit SDRAM、LCD などなど乗せても、部品代だけなら Envision Kit と同等くらいで収まる。

ただ、問題もある。
実際に設計を始めて問題になったのはピン定義だ、SDRAM（１６ビットバス）、SDHI（SDカード）、Ethernet、LCDなど、１６９ピンデバイスで、これらを全部使うピン定義を考えたが、信号が被って、同時利用は出来ないようだ・・・

LCD のバスを「８ビットシリアル」にする事で何とかアサイン出来る事が判った、ポートは余っているのに、そこにアサイン出来ない（定義が無い）のは「何で」ってなる・・
※８ビットシリアルを通常の RGB バスに変換するのに８ビットラッチを２個は用意する必要があると思う。

将来的にはマイクロコントローラのピン定義は、全てのピンで全てのペリフェラルを自由に割り当て出来るような構成になるものと思うが、ＬＳＩの設計段階で、それが大きなハードルになる場合もあるのだろう、現状では、そのような柔軟な設定が出来るマイクロコントローラは少ない。
そこまでの柔軟性は必要無くても、最低限、主要な機能を使う為の標準的定義が仕様として出来ないのは如何なものか・・・

KiCADのシンボルや footprint は、ネットを探すと自分の欲しい物はほとんど入手できる場合が多いが、部分的に気に入らない場合や、ライセンスなどの問題があったりして、一つや二つなら自分で作っても大した手間ではない。
また、５．ｘ系の為、４．ｘ系のライブラリが読めない事があるようだ。
※秋月電子とかで、そのような物を集めて、またはサービスとして作成して公開して欲しいと思う。
自分が使う部品は、GitHub に上げてある。
https://github.com/hirakuni45/RX/tree/master/KiCAD_lib

回路設計と言っても、ルネサス社が出しているサンプルボードの回路図で必要な部分を流用すれば良い、最近は基板を作るハードルが下がっているので、失敗しても気軽に作り直しが出来る、ただ、やはり４層基板で作りたいので、それほど安くは出来ないかもしれないが、日本国内の基板屋に比べて１／４～１／１０程度だろうと思う。

LCD は秋月で売っているものの、タッチパネルが付いていないので、AliiExpress でタッチパネル付きの物を購入した、送料入れて２２ドル程度だったが、表示品質は高そうだ、秋月で売っているものとバックライトLEDの仕様が異なるが、「CAT4238」を使えば、流れる電流値の設定変更だけで対応出来そうではある、LCDのピンアサインは共通のようだ。

SDRAM は、秋月で１２８メガビット品を＠３００で入手出来るが、２５６メガビット品「IS42S16160-7TL」を購入、＠４２３だった。（１６ビットバス）
RX65Nは内臓RAMはそこそこあるものの、グラフィックスなど、容量の大きいオブジェクトを扱う場合、SDRAMは必須と言える。
※外部に接続されたSDRAMの速度は、内臓RAMに比べてかなりスローダウンすると思えるのだが、実メモリが数十メガバイトあるのは、本当に有利だ、C++ の標準ライブラリや boost も気兼ねなく使え、PC 環境と遜色無く、プログラムを実装できると思える。
また、Minix のような実行環境も揃えられるだろう。
※ gcc を動かしたいが、完全な POSIX 環境を作るのは簡単では無いだろうな・・

先日、RX65N に内臓の描画エンジンを使ってみたが、描画の管理を色々テスト、評価する段階で暗礁に乗り上げた。
RX65Nの場合、内臓メモリは限られているので、ダブルバッファとフリッピングによる手法を行うには無理がある。
そこで、とりあえず、シングルバッファによる方法で、描画と表示を最適化して、何とかならないかと試行錯誤してみたが、「問題」に当たった。

予定では、画面表示と描画を細かく管理する事で、高速な描画エンジンとの連携で何とかなると思っていたが、思っていたように動作せず、悩んでいる。

まず、問題をシンプルにする為、簡単な描画シーケンスを実行してみた。

    d2_startframe(d2_);
    d2_clear(d2_, 0x000000);
    d2_setcolor(d2_, 0, col);
    d2_rendercircle(d2_, 480/2*16, 272/2*16, rad*16, 0);
    d2_endframe(d2_);

上記のプログラムでは、画面全体を消去して、中心に円を描画する、描画の半径は、フレーム毎に変えるようにしている。
※実際に描画にかかる実時間は、半径が最大でも１ｍｓ程度と思われる。

普通に考えると、「描画中」は、描画アクセスが優先されるので正しい表示にならないのは判る。
しかし、実際にこのプログラムを走らせると、描画が終わってからも、正しい表示がされない。
※正しい表示がされるのは、次のフレームからになり、毎フレームこの処理を繰り返すと、ほとんど何も表示出来ない常態になってしまう。
ここからは想像なのだが、DRW2Dエンジンにディスプレイリストを渡して描画すると、DRW2Dエンジンがメモリバスを奪い取って放さず、GLCDCの読み出しが無効になってしまい、表示の読み出しが失敗しているように見える。
DRW2Dのキャッシュをフラッシュするとか、描画領域を変更するとか色々考え付く方法を試したが、一旦描画を始めてしまうと、描画の終了に関わらず、メモリバスを占有して離さないようだ、この状態は、垂直同期信号のトリガーでリセットされる。
これは、参った、この状況では、いくらパフォーマンスが高くても、リアルタイム性を要求するような描画を行えない。

何か不足している設定があるのでは？

もしかして、「バス」の優先度を設定するレジスターがあるのでは？
ハードウェアーマニュアルを良く見て、「あーーー」と唸ってしまった、「拡張バスマスタ優先度制御レジスタ (EBMAPCR)」というのがあった・・・
ヨクヨク、サンプルソースコードを見ると、GLCDC、DRW2Dの初期化時にこのレジスターにプライオリティーを設定してる・・

    {  // メインバス２優先順位設定（GLCDC、DRW2D）
        device::BUS::EBMAPCR.PR1SEL = 0;
        device::BUS::EBMAPCR.PR2SEL = 3;
        device::BUS::EBMAPCR.PR3SEL = 1;
        device::BUS::EBMAPCR.PR4SEL = 2;
        device::BUS::EBMAPCR.PR5SEL = 4;
    }

それに習って、上記のように優先順位を設定してみたら、思った通りの表示が行えた～

この問題解決に随分時間をかけてしまったようだ・・・

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

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

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

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

「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）などもあり、ＲＸマイコンは色々な場面で有用だと思える。

備考：
・コンパイラは「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もそれは同様なようだ）