以前の物置をゴミ処理場（まるたの森クリーンセンター）に運んだら、これは、鉄屑なので、ここでは受け取れないとの事、それで、「綿半Ｊマート都留店」そばの金属回収業者「田村リサイクル」を紹介してもらった、丁度お昼どきで責任者が食事に出かけていないとの事、このくらいの鉄屑だと数百円になると言われたが、そのまま置いてきた。
次の日、残っていた「根」を取り除く為作業をした。
根の周辺をある程度掘って、鉄棒を差込み、色々な方向から「こじった」ら、あれだけ頑丈でビクともしなかった根が、部分的に折れて、何とか抜き取る事が出来た、多分、深い所にまだ残っているようだが、それは放置する事にした。
根のあった所に土を埋め戻して、固めているが、沈下しないように強く固めておかないと後々問題が起こると思うので、少し慎重に作業している。
木製の大きなハンマーとかあると良いのだが、以前にホームセンターで見た時は、それなりの値段だったので、花壇を囲っていたレンガを使って、地ならしをしている。
これだけ苦労して抜いたが、３０センチくらいしか広がっていない感じで、それだと不十分なので、もう少し邪魔な植木を抜いて、広げたい。
切り株の除去に難儀してる。
とにかく「硬い」！
最初、５～６センチだけ削ろうと思ったが、ここまできたら、とことん除こうと思った、どんなふうに「根」が伸びているのかも気になった。（何でこんなに強力なんだとは思ったが、考えてみれば、この切り株の木が上に数メートルあるのなら、かなり頑丈に根を生やしていないと簡単に倒れてしまう。）
ある程度壊してしまうと、土台が緩くなって、木が硬い事もあり、ノミが入っていかない、横から叩いたり、方向を色々工夫すると、入って行きやすい角度があり何とかなる感じ・・
土を掘っていたら何故か、鉄の棒が出てきたので、それを使ってテコで根を掘り出したり、折っている。
木の生命力は凄い！、複雑に入り組んで、強靭な根を伸ばしてる。
あと、もう少しだ・・・
今回はここまでー
最初、切り株はそのままにして、ギリギリまで寄せるつもりだったが、最近天気が良い日が続いていて、時間もある事から、切り株を取り除こうと思い作業を開始した。
まず、切り株の周りを掘ってみたー、それなりに掘ったら、末広がりで、頑丈な根があり、とても全体を取り除く事は出来ない事が判った。
また、この「木」は何の木か知らないけど、目が詰まって、非常に堅い。
とりあえず、ノコギリを買ってきて、切ってみようとしたが、硬くて、手動では到底無理で断念したー、次に電動ドライバーに木工ドリルを付けて穴を開けてみたが、硬くて、崩せる程穴あけするには無理がある、次に丸ノコで切れそうな部分を切ってみたが、丸ノコでは、中心部まで刃が届かないので、これも駄目、本来ならチェーンソーが必要なとこだが、切り株を一つ処理するだけなのにチェーンソーを買うのも気がひける・・
最後は、地道にノミとトンカチで少しづつ切り崩してみた。
どうやらこれが「正解」のようで、時間と手間がかかるが、そこそこの労力で何とかなる事が判った。
ノコギリで根を少し分解する過程で、「石」を噛んだ根をノコで引いてしまい、一瞬で刃が鈍ってしまったようだー（切れ味が一瞬で悪くなった・・・）
とりあえず、地道ではあるが少しづつ崩して（３０センチ弱は崩した）、ここまでになったが、あと７センチくらいは崩さないと・・・
トンカチを振り下ろすのは、それなりに大変なので、１日数時間くらい作業をしている。（３日くらい）
とりあえず、ここまでー
先日、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）などもあり、ＲＸマイコンは色々な場面で有用だと思える。
| 型番 | 動作周波数 [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
※一応、テストで使っているプロジェクト