中古住宅リホーム(物置)その1

住宅を買った時に物置は付いていたものの、床が錆で朽ち果てており、大きさも微妙に小さく、タイヤを置くと他にほとんど何も置けない状況だった・・
※山梨は、冬、スタッドレスタイヤは必須なので、タイヤ保管しないとならない。

今年は仕事が忙しくない日が多いので、物置をリニューアルする事にした。

まず、古い物置を解体する。
※元の状態を撮り忘れた・・
パーテーション、柱など、タッピングビスで固定されており、上から下へ順番に外していく、錆でネジ山が潰れていて外せないものもあり、ディスクグラインダーで頭を飛ばした。
不思議なのは、「背面」のネジ、背面は、隣の家でブロック塀があり、空間が無い。
組み立ての時、手前にずらして組み立てて背面のネジを全て止めて、押し込んだと思うが、ある程度組み立てた状態だと、かなりの重量になるので、可能なのか?
背面にデッドスペースを作りたく無いので、そうしたいが、重くて動かせないとか、中途半端な状態で動かして、柱が曲がったりしないかとか、ネジの締め忘れとか、色々、不安材料がある・・

とりあえず、地面を整地する必要があるので、おいおい考えるとして、新しい物置のスペースを作る為、芝生を切り取ったりしたが、この作業が思いのほか大変で、空間を作っただけで1日終わってしまった。
芝を切り取る作業、「鎌」を使うのだが、2時間も作業すると、握力が無くなり、鎌を持てなくなる・・・

解体した物置
整地途中

物置は、もう少し右に寄せたいのだが、切り株がある、最初切り株を撤去しようと考えたが、斧やチェーンソーなど道具が必要なので、何とか、出ている「根」だけ取り除いたーー
大体整地出来たのでブロックを置いてみた。

ここで今日は終了。
※やっぱ切り株邪魔だなー・・・
※次の日ブロックを並べる作業をしようと思ったが、寝違えて首が痛い・・、なのでこのまま放置・・・

RX65N Envision Kit 、DRW2Dエンジンを使う

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

そこで、DRW2Dライブラリの機能をC++から呼び出すラッパーを実装してみた。
※DRW2Dライブラリのバージョンは1.02をベースにしている。

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

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

「drw2d_mgr」クラスでは、初期化で、割り込みベクターを登録している。
「void drw_int_isr(void);」はDRW2Dライブラリの割り込みサービスの入り口で、それを登録しておけば良い、ただ、この割り込みは、グループベクタAL1になっていて、「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ライブラリの構成はOpenGLのコマンドストリームの考え方に近いので(高速、柔軟性、機能性を追及すると、大体、このような構成になる)マネージャーを実装するのは比較的やりやすい。

アンチエリアスされた「線」と「サークル」の描画

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

drw2d_mgr.hpp

NESのパッドを付けてみたら・・

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

NESパッド

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

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

白:Vcc(電源、通常+5V)
茶:GND(電源、0V)
橙:P/S(パラレル、シフト切り替え)
赤:CLK(クロック)
黄:OUT(シリアル出力)

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

これは多分、クロックの遅延が足りないものと思い、クロックの遅延ループを6回から20回にして動作するようになった。
この純正パッドはC-MOS「4021B」を使っているが、互換パッドに使われているICは、4021Bの互換ICで、クロックの許容範囲が広いものと思う。

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_;
}

上記のように、ループ数を「6」から「20」に変更した。
※120MHz動作の場合なので、もっとCPUクロックが速い場合は調整する必要がある。

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

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

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

FAMIPAD.hpp

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

RXマイコン別性能(レイトレースによる)

RX66Tは、まだデバイスが入手できていないので評価はまだだが、RX24T、RX65N、RX71M(RX64M)の全般的な性能評価を行った。
※RX64Mは最大動作周波数がRX71Mの半分で、他はRX71Mと同等なので、スルーしている。
又、最大動作周波数でベンチマークしている。

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

RX200シリーズなどのFPUを持たないマイコン(RXv1コア)は、手持ちが無いので評価していないが、コストの問題から下位のシリーズを使う場合でも、CPの高いRX24Tの存在があり(RX220とあまりコストが変わらないと言うのは言い過ぎだと思うが・・)低価格路線では、それを目安にする事ができる。
※自分としては、RX200シリーズはFPUを持たないし、動作周波数も低く、あまりメリットを感じない。
これは多分、RL78などの8/16ビットマイコンとの差別化で、同じような価格帯で、性能差が大きすぎると差別化が難しい為と思われる、それでも、32ビットコアのメリットは大きい。
※RXマイコンが、ARM、PIC32、ESP32に比べて割高感があるので、「敬遠」している人がいるかもしれないが、たとえば、RX65Nと同等の機能を持った、ARMと比べた場合、同等の性能を出す事が出来るシリーズは無かったり、価格もそれほど変わらない場合も多い。
今回評価していないものの、RX630(100MHz)などもあり、RXマイコンは色々な場面で有用だと思える。

RX24T、8ビットバス、I/Oポート制御
RX65N、フレームバッファ制御
RX71M、フレームバッファ制御
型番 動作周波数 [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もそれは同様なようだ)

RX71MにLCDを接続してみる。

かなり昔に、Aitendo でセールしてたTFT-LCDをRX71Mに接続してみた。

2.2インチ、320x240、64Kカラー、コントローラーは、R61505

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

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

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

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

何で?
8ビットバス接続では、DB8~DB15 を使う、16ビットバスでは、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 動作では、320x240のレイトレースベンチマークは上記のように0.63秒だった。
ただ、ピクセルの描画コマンドをコントローラーに送る際のオーバーヘッドが大きいので、実際には、もっと速いと思うが、素晴らしいパフォーマンスだ!
RXマイコンは、本当に優秀なマイコンだと思う、使わない理由が無い、逆に何故ARMやPICを使うのか問いたいくらいだ。

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