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

残ってた「根」をほぼ抜き取った
抜きとった状態
さらに、周辺に残ってた「根」などを除去
これで、ほぼ完了だが、折角なのでもう少し広げる為に作業を続行

以前の物置をゴミ処理場(まるたの森クリーンセンター)に運んだら、これは、鉄屑なので、ここでは受け取れないとの事、それで、「綿半Jマート都留店」そばの金属回収業者「田村リサイクル」を紹介してもらった、丁度お昼どきで責任者が食事に出かけていないとの事、このくらいの鉄屑だと数百円になると言われたが、そのまま置いてきた。

次の日、残っていた「根」を取り除く為作業をした。
根の周辺をある程度掘って、鉄棒を差込み、色々な方向から「こじった」ら、あれだけ頑丈でビクともしなかった根が、部分的に折れて、何とか抜き取る事が出来た、多分、深い所にまだ残っているようだが、それは放置する事にした。

根のあった所に土を埋め戻して、固めているが、沈下しないように強く固めておかないと後々問題が起こると思うので、少し慎重に作業している。

木製の大きなハンマーとかあると良いのだが、以前にホームセンターで見た時は、それなりの値段だったので、花壇を囲っていたレンガを使って、地ならしをしている。

これだけ苦労して抜いたが、30センチくらいしか広がっていない感じで、それだと不十分なので、もう少し邪魔な植木を抜いて、広げたい。

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

切り株の除去に難儀してる。
とにかく「硬い」!

最初、5~6センチだけ削ろうと思ったが、ここまできたら、とことん除こうと思った、どんなふうに「根」が伸びているのかも気になった。(何でこんなに強力なんだとは思ったが、考えてみれば、この切り株の木が上に数メートルあるのなら、かなり頑丈に根を生やしていないと簡単に倒れてしまう。)

2時間だけ作業・・、手が痛い・・
天気が悪く、2日おいて作業、腕が限界でここまで・・
壊した木屑w

ある程度壊してしまうと、土台が緩くなって、木が硬い事もあり、ノミが入っていかない、横から叩いたり、方向を色々工夫すると、入って行きやすい角度があり何とかなる感じ・・

土を掘っていたら何故か、鉄の棒が出てきたので、それを使ってテコで根を掘り出したり、折っている。
木の生命力は凄い!、複雑に入り組んで、強靭な根を伸ばしてる。

何故か地中に埋まっていた「鉄棒」
残すは右側の切り株(この状態ではビクともしない・・)
左側から掘り出した「根」

あと、もう少しだ・・・
今回はここまでー

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

最初、切り株はそのままにして、ギリギリまで寄せるつもりだったが、最近天気が良い日が続いていて、時間もある事から、切り株を取り除こうと思い作業を開始した。
まず、切り株の周りを掘ってみたー、それなりに掘ったら、末広がりで、頑丈な根があり、とても全体を取り除く事は出来ない事が判った。

また、この「木」は何の木か知らないけど、目が詰まって、非常に堅い。
とりあえず、ノコギリを買ってきて、切ってみようとしたが、硬くて、手動では到底無理で断念したー、次に電動ドライバーに木工ドリルを付けて穴を開けてみたが、硬くて、崩せる程穴あけするには無理がある、次に丸ノコで切れそうな部分を切ってみたが、丸ノコでは、中心部まで刃が届かないので、これも駄目、本来ならチェーンソーが必要なとこだが、切り株を一つ処理するだけなのにチェーンソーを買うのも気がひける・・

最後は、地道にノミとトンカチで少しづつ切り崩してみた。
どうやらこれが「正解」のようで、時間と手間がかかるが、そこそこの労力で何とかなる事が判った。

切り株の周りを少し掘った状態

ノコギリで根を少し分解する過程で、「石」を噛んだ根をノコで引いてしまい、一瞬で刃が鈍ってしまったようだー(切れ味が一瞬で悪くなった・・・)

とりあえず、地道ではあるが少しづつ崩して(30センチ弱は崩した)、ここまでになったが、あと7センチくらいは崩さないと・・・
トンカチを振り下ろすのは、それなりに大変なので、1日数時間くらい作業をしている。(3日くらい)
とりあえず、ここまでー

RX65N Envision Kit、DRW2D エンジンの仕様?不具合?

先日、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_);

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

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

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

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

    {  // メインバス2優先順位設定(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エンジンが描画を行っている・・

12トン油圧プレスの設置

去年の年末、ヤフオクで12トンの油圧プレスを購入、それに関する出来事を記しておく。

実際に来たものは上記の写真と異なるが「中華」にはありがちだし、気がつくのが遅く、交換してもらう手続きとか面倒なので、あきらめている・・・
・シリンダの固定方法が異なる。(写真の方が組み立てが簡単)
・高さ調整の穴が、異なる、写真の物はより実用的な穴位置のようだ・・(自分で穴をあければ何とかなる)
とにかく価格が安いし、使えれば文句は無いので、あまり細かい事は言わない事にする、価格には通常送料も含まれているが、離島などでは追加料金が発生する。
本当は「20トン」仕様が欲しかったが、重すぎるので見送った。

12月の中頃に、荷物が届いたー、だが、細長い柱が二本のみだった、「これだけですか」と佐川の配達に聞くと、「これだけです」と言い切った(嫌な予感)。
その時は、後に他が届くのだろうくらいに考えていたが、1週間たっても配達されなかった、既に正月休みで、連絡も取れない。

年が明けてから連絡を取ると、二小口の一つが破損して、それだけ戻った事が判った。
そこで、届かない分をもう一度届けるように手配したと連絡があり、3日後くらいに届いた。
「早速組み立てるゾ!」と開封したら、明らかに部品が足りない・・・
一応入っていたパーツリスト(間違いが多く、不鮮明)を見ながら足りない部品リストを作り、問い合わせた。
間違いが無いように数回やりとりして、足りない部品を再度配送したと連絡があり、やはり三日後くらいに到着。
少し不安になりながら確認して、何とか部品は揃ったようだった。(結局1.5ヶ月くらいかかった・・)

早速組み立て、簡単なテストをしてみて、何とか使えるようだー、ただ「12トン」となっているが、実際には6~8トンくらいが実用範囲のように思う。
※5トンくらい加重をかけるとハンドルがかなり重い。
流石「中華」製だ!、まぁでも自分の利用範囲ではこれでも十分と思う。
※油圧シリンダ?を支える構造が弱すぎのように思う、板圧は倍くらいほしい。(今後剛性が足りないようなら補強しようと思う)
※12トンで、もっと安い製品もあるが、そちらは、自動車の油圧ジャッキを逆さまにしたような構造で、加圧メーターも無く使い勝手がイマイチと思って避けた。(半額以下で買えるのだが・・)

安全の為、角を丸めておいた

中古住宅リホーム(物置)その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
※一応、テストで使っているプロジェクト