作業部屋のパソコン机を作る

作業部屋で、CNC、3Dプリンターなどを制御する為、以前に中古パソコンを買ってみたー、本当は自作PCを組むつもりだったけど、中古パソコンで性能がそこそこの物がかなり安く入手できる事を知ったのと、メーカー製PCを一台も持っていない事もある為で、HDD仕様だけど、余っている240GBのSSDを追加してシステム関係を移動、やはり余っていたメモリに交換して8GBにした、モニターは、以前メインPCで使っていた24インチを使った、性能的にも能力的にも、これでも十分(一応i7なので)となった。

パソコンを置く台だが、エレクタもどきで、適当な物が余っていたのでそれを組み立て(車輪付き)、キーボード台を自作して改造した。

キーボード台は、ホームセンターおなじみの「パイン集成材」を利用した、この板は、反りが少なく、頑丈で加工しやすい特徴がある。

また、スライドレールで長さが丁度良い物が余っていた(台所の引き出しに使うつもりで間違った長さを買った余剰品が沢山ある・・)ので、それを取り付ける為のガイドを作り、取り付けた、適当な板を張り合わせて、丁度良い大きさに加工した、エレクターへは、タッピングビスで固定した。

「木」は加工が簡単で、それなりに強度があり、適度に柔軟なので、DIYには都合の良い材料で助かる、ただ、切断時(電動丸ノコ)に切りくずが凄いので外で加工する事になり、「晴れていて昼」のみ加工できる。

エレクタもどきの天板は、そんなに重量のある物を置かないので、5mm厚のMDFを使ったが、湿気などを考慮して、何か塗る必要がありそうだ・・・

左右の取り付け位置が微妙で、多少「建てつけ」が悪いが、強度も十分でちゃんと使えそうだ。(このキーボード台も何か塗った方が良いだろうなぁ・・)
※このスライドレール、途中で止める機構が無いので何かストッパーが必要だな・・
※現状、キーボードを乗せた状態で引き出しを閉める事が出来ないので、要改修が必要なのに気がついた・・

旋盤を作業台に載せた話

以前に購入した入門用小型旋盤を使っていたが、主軸のベアリングが駄目になったようで、削った場合に「模様」が入るようになった。
分解して、ベアリング交換をしようと思っていた矢先、山梨に引越した。

本業が一段落したので、直そうかと思っていたが、「小型」(チャックが80mm)で、剛性が足りないと思っていた、そしたら、ヤフオクで少し大型の旋盤を売っているのを見つけてしまった。
通常このサイズ(チャックが125mm)は、120キロ以上なのだが、「振り」が短く80キロ程度だった、それに「送り」は金属ギヤーで、ブラシレスモーター、プーリー駆動(静か)、インバーター速度制御、かなり充実した内容だった。

このサイズと重さなら、何とか屋内に設置可能と思いポチッた(本来は、中古の本物旋盤が欲しいが、重量が少なくとも数百キロ以上あり、三相200Vなので普通の部屋に置くのは厳しい)、しかし、物が来たが、工作部屋の整理が進んでいないので、しばらく玄関に放置していた。
先日、ようやく、工作部屋のスペースを確保して、旋盤を設置した。

80キロだと大人二人なら何とか持ち上げられるが、知り合いをその為に呼ぶのも気が引ける、何とか一人で作業台に載せられないか・・
しばし考え、パソコン台用を向かい合わせにして、バイクを車で運ぶ際に使う、ラチェット式タイダウン、サブベルト、通常のタイダウンなどを駆使して、少しづつ引き上げ、作業台に載せる事ができた。

作業台は、「エレクター」もどき、ホームセンターではお馴染みのアイテムで、分解や組み立てが簡単で、高さや大きさ、板の枚数が自由に選べ、かなりの重さに耐える。(以前から持っていたものを再利用した)
ただ、天板は、骨構造なので、ホームセンターで購入したメラニンボードを適当に切り、載せている。(表面がスベスベで油が染み込まず、掃除が楽)

この旋盤の刃物台は、以前の物より少しばかり大きく、剛性も高い、そこで、以前使っていた10mm角より少し太い12mm角のホルダーを新たに購入した、海外ではかなり安く売っているが、送料が「重い」と高い・・、それでも国内で買うより十分安く、チップも一通りついている。

主軸の触れは問題なく、三爪の保持では0.05mmほどあるが、これは、三爪の特性と、このスクロールチャックの性能で、まぁ許容範囲だろうと思う。

貫通穴は、35mmの丸棒が余裕で通る。
※その為、MT3などのホルダーを取り付けたい場合は、アタッチメントを用意する必要がある。

モーターは回してみたが、何の問題もなくスムーズで静かだ、回転速度も安定しており、自動送りも問題なく機能している。

早速削ってみたいとこだが、切子を避ける板などや、照明を準備するのでそれが出来たら紹介しようと思う。

簡易二重窓を取り付ける

大月に越して、1年が経とうとしている。
12月に入って、寒い日が続くようになった、大月は、都内に比べると5度~10度は温度が低いと思う。
家があるのは、大月市内より山寄りで、少しだけ標高も高い、今日の朝は「-8度」くらいだった・・
一軒家は、以前に住んでいたアパートに比べて、機密性が低いのか、かなり寒く、暖房器具が欠かせない。
夜に作業をしていると、寒いのでファンヒーターやストーブを使うが、燃料代がバカにならないので、以前にホームセンターで提案していた、簡易二重窓を付けてみた。
中空のポリカーボ板と、それを囲う枠やレールなどで構成されていて、かなりお手軽に作る事ができて、それなりに安いコストでも効果は抜群と言う触れ込みだった。(どのくらい効果があるのかは、これから判ると思う)
ただ、普通に考えて、窓1枚では、機密性は最悪で、ガンガン暖かい空気が逃げてしまう、また、結露が凄い。

まず、計測。
しかし、メジャーで正確な計測は意外と難しい。
また、窓枠が厳密に長方形とは限らないし、角が直角とも限らないので、最終的には現物合わせとなる。
窓のレールは、上用の深い物と、下用の浅い物があり、ホームセンターのサンプルでは、左右のレールは、上と下のレールを囲う少しだけサイズが異なる物だったが、45度にカットして、共通の物とした。
※自分では正確に切断したつもりでも1mmくらいはずれてしまう場合があった、あんまし器用とは言えない・・
レールは、両面テープで貼るので、お手軽だ。
カットは、ジグソーで行った。
※ポリカーボの板はカッターで切れるが、長い直線を切るのはそれなりに難しい、工作用に買ったアルミのコの字アングルをガイドに使ったが、力加減が難しく、気を抜くと簡単にズレてしまう。

ホームセンターのサンプルでは、カットは垂直にして窓枠を組んでいたが、仕上がりを気にして、45度カットにして合わせたが、45度のカットが中途半端で正確性に欠け、隙間なく綺麗に合わさるまでには至らなかった・・
イマイチな仕上がりとなったが、まぁ、及第点としておこうw。

長方形に仕上げたつもりだが、微妙に台形となっており、イマイチだが、レールの深さがそれなりにあるので、隙間はほぼ無い。

外の窓は10.6度

中の窓は21.9度
と、10度くらい温度差があるので、かなり効果があるものと思う。

RXマイコン関係ソースコードを整理する

RX66T関係を追加する過程で、RX関連ソースコードを整理した。

今まで、RX24Tに始まり、RX64M、RX71M、RX65Nとサポートデバイスを広げてきたが、RX66Tを加えるにあたり、重複しているファイルや、醜い部分を整理した。
基本はRX64Mとなっている。
・RX64M、RX71Mはほぼ同じ
・RX651/RX65Nは、微妙に異なる
・RX24Tは別品種(割り込み関係が異なる)
・RX66Tは、RX24TとRX64M系の中間的
こんな感じだが、デバイスのレジスター関係は、全てにおいて共通部分が多く、共有出来る。
異なるのは、デバイス(自分のフレームワークでは、ペリフェラルと呼んでいる)の有無。
RX64M、RX71Mは非常に沢山のペリフェラルを持っているが、RX24Tなどは、それに比べて少ないが、中でも「割り込み」ベクターが大きく異なる。
これをどのように表現するかが大きな課題となっていたが、とりあえず、テンプレートにしておけば何とでもなる事が判った。
また、今までは、似ているけど少し異なるような場合は、「#if」などで、分けて凌いでいたが、基本的に各デバイスで、ファイルを分けて対応する事にした。
懸念事項としては、同じコードを全てのデバイス専用ファイルにコピーする必要があり、この場合、一つの修正が、他のデバイスのソースも同じように修正する必要が出てくる・・
一つのファイルで共有して「#if」で細かく分ける書き方だと、かなりトリッキーで読みにくくなる、どちらが良いかは、ケースバイケースで何とも言えないが、保守より読みやすさを優先した。

ペリフェラル:
各デバイスには、「peripheral.hpp」があり、このファイル内で、「enum class」により、「peripheral」型で、利用できるペリフェラルが列挙してある。
この「列挙型」の違いにより、ポートの設定、消費電力設定、割り込み制御など、大まかな動作を分けている、ペリフェラルを直接叩くドライバーは、たとえば割り込みベクター型の違いを考慮する必要が無いように実装してある。

RX24Tのペリフェラルでは、割り込みベクターは、通常ベクターに全て割り当てられているが、RX64Mなどペリフェラルが多いデバイスでは、通常ベクターの数が足りずに、グループベクター、選択型ベクターを新規に設け、それらに割り当てるように工夫されている為、そのままでは同じように扱う事が出来ない。
この違いを吸収して、デバイスドライバーを共通化する為、考えた結果、以下のような実装を行う事でかなりスマートに解決出来た。

//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
        @brief  CMT I/O クラス
        @param[in]  CMT チャネルクラス
        @param[in]  TASK    タイマー動作クラス
*/    //++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <class CMT, class TASK = utils::null_task>
class cmt_io {

...

};

上記はCMTの制御クラスの型だが、「CMT」は、CMTペリフェラルクラスで、CMTの制御レジスターを定義したものになっている、通常CMTは0~3まで4チャネルある。
RX64M、RX71M、RX65Nでは、CMT0、CMT1の割り込みは「通常」ベクターだが、CMT2、CMT3は「選択型」ベクターとなっていて、割り込みの設定手順が異なる。

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  CMT 定義基底クラス
    @param[in]  base    ベース・アドレス
    @param[in]  per     ペリフェラル
    @param[in]  INT     割り込みベクター型
    @param[in]  ivec    割り込みベクター
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <uint32_t base, peripheral per, typename INT, INT ivec>
struct cmt_t {

...

};
#if defined(SIG_RX24T) || defined(SIG_RX66T)
    typedef cmt_t<0x00088002, peripheral::CMT0, ICU::VECTOR, ICU::VECTOR::CMI0> CMT0;
    typedef cmt_t<0x00088008, peripheral::CMT1, ICU::VECTOR, ICU::VECTOR::CMI1> CMT1;
    typedef cmt_t<0x00088012, peripheral::CMT2, ICU::VECTOR, ICU::VECTOR::CMI2> CMT2;
    typedef cmt_t<0x00088018, peripheral::CMT3, ICU::VECTOR, ICU::VECTOR::CMI3> CMT3;
#elif defined(SIG_RX64M) || defined(SIG_RX71M) || defined(SIG_RX65N)
    typedef cmt_t<0x00088002, peripheral::CMT0, ICU::VECTOR, ICU::VECTOR::CMI0> CMT0;
    typedef cmt_t<0x00088008, peripheral::CMT1, ICU::VECTOR, ICU::VECTOR::CMI1> CMT1;
    typedef cmt_t<0x00088012, peripheral::CMT2, ICU::VECTOR_SELB, ICU::VECTOR_SELB::CMI2> CMT2;
    typedef cmt_t<0x00088018, peripheral::CMT3, ICU::VECTOR_SELB, ICU::VECTOR_SELB::CMI3> CMT3;
#endif

上記のように、テンプレートパラメータで「INT」(割り込みベクター型)を設ける事で、cmt_t クラスは、どの型のベクターなのかを意識しなくて済むようになっていて、「typedef」だけで対応できる。

cmt_io クラスでは、ベクターの型を元に、割り込み設定の方法を分ける事ができ、面倒な「#if文」から開放される。
また、C++ では、ベクター型の違いによる分岐は、コンパイル時に決定できるので、最適化により、余分の分岐一切が無くなるので、速度の面もリソースの面も好都合となる。
このような仕組みは、C言語だと、スマートに実現する事は難しい、C++ が組み込みマイコンのプログラムに向いた言語である事の一例であると思う。
※C言語プログラマは、#define で実現可能と思うかもしれないが、#define では、正確で厳密な「型」チェックは行われないし、構造的や論理的に誤ったコードをエラー無くコンパイルしてしまう可能性があり、テンプレートとは雲泥の差がある。

C++ のテンプレートでは、構造的や論理的に誤った構造は、「ほぼ」エラーになるので、最初の設計が必要十分な要素を詰め込んであれば、自ずと正しい方向に誘導してくれる感じがある。
大雑把に言うと、コンパイルエラーが無くなったら、プログラムも正しく動く事が多いとも言える。

自分が実装したソースでは、「#define」でマクロ的な定義を行う事は一切していない。

RXv3コア使用、RX66Tが発表された

RXv3 コアを内臓した初めての製品が発表された。
予想ではRX71Mの上位製品が最初だと思っていたが、モーター制御系の低価格版が最初のようだー。
RX66Tは、RXv3以外にも面白い特徴がある。
その一つは、高分解能PWMだろう、マスタークロックも160MHz動作が可能な上に、位相制御で、「最小195ps(ピコセカンド)でタイミング調整が可能」となっている点が新しい、位相制御は以前には、RX62Gで採用されたが、インバーターでは、必要な機能だろう、デジタルSWレギュレーターなどを実現するのに欲しい機能だ。

デバイスは、主に、RAMが128KBと64KBの製品があり(コードフラッシュは256K~1M)、多分、最初に出てくるのはRAMが64KBの製品と思う、また、USBも無しタイプが最初だろうと思う。
※コードフラッシュは256Kで十分だが、512K版との価格差は少ないものと思う。

現段階では、デバイスの販売はされていないものの、ハードウェアーマニュアルはダウンロード可能になっているので、早速、ダウンロードして、フレームワークに必要な実装を始めた。

構成は、RX63Tの後継らしいが、レジスターの構成は、RX64MやRX65Nに近いと思う。
RXマイコンのソフトウェアー資産は、今となっては沢山あるので、自分にとっては非常にメリットがある。
また、シリアルポートからのコードフラッシュプログラムも、プロトコルはRX24Tとほとんど同じ仕様と思うので、少しの追加でサポートできるだろう。

RX66TにはUSB内臓タイプがあるが、クロックレジスタの構成を考えると、USBを使う前提だと、最大周波数の160MHzでは動かせないと思う。
※USBで基準になる、24MHzの倍数で動かす必要があると思うので、156MHz動作になると思う(24MHz×6.5倍)。
RXv3コアは、RXv2コアに比べて、命令の効率が高いので、周波数が同じでもRXv2コアに比べてパフォーマンスが高いと思われる、どのくらい高いのか、早くデバイスを入手して試してみたい!
※多分、レイトレーサーを動かす事になると思う。

デバイスは、果たして、幾らで買えるのか?
RX24Tと同じく、10個購入程度で、それなりに安く買えるとありがたい・・
※上記ボードは、ルネサス純正ボードで、13200円(自分は高いのでスルー)

CPが最高に高いRX24T

100円マイコンのR8Cは別格としても、安くても十分機能があり、それでいてパフォーマンス(馬力)があるマイコンが必要な場合がある。
ルネサス社が発表しているマイコンで、どれが、コスト、パフォーマンス、機能が優れているか、検討してみた。
※実際は、かなり前に検討したものだが、未だにCPの高さトップに君臨している。

ちょっとした物を作る場合でも、昔には戻れない・・
※ファミコンやゲームボーイの時代はROMが高かったので、より多くのリソースを積み込む為、データ圧縮や、手動による最適化を行ったものだ、ハードウェアーがアップグレードして、記憶媒体がROMから、RAMになってCD-ROMなどの光学媒体になってから、もう容量の事で悩むような事は少なくなり、開発環境もアセンブラから高級言語に移っていった。
※PS2、EEのようにアセンブラでチューニングしなければ性能が出なかった例外的なハードもあるのだけど・・

今は、時代が違う、それでも、組み込みマイコンの場合、容量は有限だし、価格の安いデバイスはRAMも少ない、それゆえ、小さな工夫はしないとならない。
「数」を沢山作るような製品とは異なり、DIYでは機能を実現できれば、コストは度外視しても良いが、開発がやりやすいとか、リソースの再利用とか、便利で短時間で完成させる事が出来る方が良い。
C++ のテンプレートライブラリを多様したペリフェラルフレームワークは、Arduino のスケッチを書くより簡潔で判りやすく、最適化されたコードを作る事が出来る。

8/16ビットマイコンは、CPが高いと思うかもしれないが、実際はそうでは無い(ルネサス社のラインナップでは・・)、また、個人で数個単位で扱う場合と、大手が数百個、数千個、数万などスケールが異なる場合は、全く異なる価格帯になると思われるが、実際、数個のオーダーで個人が買う場合には、状況が異なる。
また、8/16ビットマイコンは、通常ポインターが16ビットで、大きな容量にアクセスする場合は、その都度、「方法」を選択してトリッキーなコードを実装しなければならない。
意外な盲点として、RXのような32ビットマイコンに比べて、同じプログラムでも、コードサイズが大きくなってしまうケースは良くある、又、内部レジスターは16ビットなので32ビットの演算では、さらに遅くなるので、場合により汎用のクラスは改修する必要もある。
32ビットマイコンは、プログラミングにおける基本的な制限はほぼ無いので、開発のしやすさや、リソースの再利用性から、少々コストが高くなっても選択したい理由となる、それでも@1000くらいだと、少し考えてしまう・・

マイコンの選択は、単純に、フラッシュの容量と内臓RAMサイズ、動作周波数などだが、マイコンの販売価格を見るに、非常にCPの高い製品がある事に気がつく。
※ARMやPIC32の価格には到底太刀打ち出来ないのだが、自分は、RXマイコンのソフトウェアー資産が豊富にあるので、ARMやPIC32よりも、RXマイコンを選択する事は十分メリットがある。
※まぁ、AVR、ARM、など各社マイコンは使った事もあるにはあるが、ルネサス社のマイコンだけにフォーカスしている人は少ないかもしれない。

RX24Tは、ブラシレスモーターのベクトル制御に特化した製品のようで、多分、エアコンや冷蔵庫などに使う目的でデザインされラインナップされた物と思う、イーサーネットやUSBは内臓していないが、他のペリフェラルが豊富で高機能なマイコンだ、そしてそれなりに安い。
※コード256K、RAM16K、データフラッシュ8K、LQFP100(10個購入時@594)
chip1stop「R5F524TAADFP#30」
※10個購入時だけど、DIY用でも10個くらいは使うだろって事で勘弁してほしい~
※RL78の256K版(@400)と比較しても、馬力を考えるとお得感がある。
※32MHzでFPU無しのRX220より安い。
※RXマイコンは、意外と命令効率が高いので、128KBの製品でも十分かもしれないが、価格差が僅かなので、256Kの製品リンクを張った。
※最近、Bバージョンが発売され、CANが使えて、RAM容量が2倍の32Kになった製品もある。(自動車向けか?)
#コード256K、RAM32K、データフラッシュ8K、LQFP100(10個購入時@657)
chip1stop「R5F524TBADFP#31」

  • RXv2コア
  • 80MHz動作(80MHz動作では、プログラムフラッシュにはウェイトが入る)
  • DSP命令(有効に使うには、アセンブラで実装する必要がある・・)
  • FPU(各種32ビットの浮動小数点命令)
  • ベクトルの正規化に威力を発揮するFSQRT(平方根)命令
  • 2.7V ~ 5.5V の単一電源動作
  • 普通に低消費電力
  • 12ビットA/D(最大1uS、3ユニット)
  • RSPI(1チャネル)※SDカードもかなり高速にアクセス可能
  • SCI(3チャネル、簡易SPI、I2Cが使える)
  • I2C(1チャネル)
  • DTC(データトランスファーコントローラー)
  • 高速で、豊富なタイマー郡(最大80MHz動作)
  • コンパレーター(4チャネル)
  • 必要十分なI/Oポート数
  • BバージョンのみCANインターフェースを備える
  • コードフラッシュの書き換え回数(1000回と少し少ない・・)

これだけの特異な特徴があり、他のRXマイコンと基本的にペリフェラルは共通。
ちょっとした用途ならこれで十分と思う、また、フラッシュROMの書き込みはシリアルで行うが(J-TAGはサポートしないが、エミュレーター専用端子FINEを持っているので、対応したE1でも当然書き込めるしデバッグもできる)、何故か、RX64Mなどと異なり、かなり高速に書き込めるので、シリアル書き込みでも開発ではあまり不自由しない。
※自分の開発スタイルでは、コードのブレークは必要としない。
※Apple、Linux、Windowsで開発出来る。
この価格帯にしては、浮動小数点がかなり強力なので、ジャイロや加速度センサーを使った姿勢制御(ロボットなど)にも、かなりマッチすると思う。
タイマーも非常に多く使えるので、RCサーボを沢山動かすのにも向いている。
多少残念なのは、コードフラッシュの書き換え回数が1000回と少し少ない。
それでも、ちょっとしたDIYボードに最適と思う。

おなじみ、レイトレーサーを走らせてみたが、約1.2秒くらいでレンダリングする。
これは、160MHz動作のESP32の10倍以上高速となっている、FPU内臓は伊達では無い。
※ピクセルの描画コストを5マイクロ秒としている。
※ESP32でのレイトレーサー速度は、ネットでの記事を参考にしており、RXマイコンに比べてあまりに遅い、ESP32はFPUを内臓しているので、ベンチマークの方法に問題があるかもしれず、単純に比較するのはフェアではないかもしれない事を付け加えておく。
200MHz動作のARMでは0.6秒との事なので、妥当なスピードと思う。

デバイスは以前に10個ほど買った(Aバージョン)ので、自分用にでも汎用ボードを作ろうと思っている。
又、折角のDSP命令も使わないのは勿体無いので、gcc 向けアセンブラ・ライブラリを実装しようと思っている、これはRXマイコン全般で使えると思う。

GitHub の「主要言語」

GitHub のホームを開くと、各プロジェクトに主要言語が表示されるー

自分の場合、以前は「C」、「C++」などで、どのようなロジックで表示されてるのか疑問だった。
調べると、コミットしてあるファイルの拡張子などから、集計を取り、一番多い「言語」を表示している事が判った。
「主要言語」が「C++」でも、「C」のライブラリなどがプロジェクトにコミットされていて、単純にCのソース数がC++ソース数を上回ると、「C」と表示されてしまう・・
※自分のプロジェクトでは、C++はヘッダーのみの場合がほとんどで、ソースは必要無いので、ソースの数は1/2で、評価が意図と異なる。
githubの検索などでは「言語」をキーに検索する事もできるので、これは、意図と違う結果になってしまう。
そこで、調べると、「.gitattribute」ファイルをプロジェクトのルートに置いて、このファイルで、集計を除外する事で、「主要言語」の評価を変えられる事が判った。

RTK5_NESEMU/emu/* linguist-vendored
ff12b/src/* linguist-vendored
zlib/* linguist-vendored
libmad/* linguist-vendored
jpeg-6b/* linguist-vendored
RX65x/drw_2d_ver1.02/* linguist-vendored

たとえば、「RX」プロジェクトは↑のように、ライブラリを除外してある。

これで、「主要言語」の評価を「C++」に出来た。

※上記の「バー」をクリックすると、ファイルと言語のプロパティが表示される。

さらに、「言語」をクリックすると、どのファイルがその言語と認識されているか詳細が表示できるので、「意図」と合わないファイルは、「.gitattribute」で、細かく指定できる。

RX65N Envision Kit オーディオプレイヤー(その2)

picojpeg デコーダーのポーティングが出来たので、ID3 タグ内のジャケット画像などを格納するタグ「APIC、PIC」内データ(JPEG)をデコードして画像表示は出来たのだが、画面サイズにフィットさせるのは後回しになっていた。

まず、仕組みを考える・・

画面デザインから、画面の右端に272×272ピクセル(液晶の縦ピクセル)で表示させるのが良さそうだ。
ただ、タグ内の画像サイズは様々なので、適切にスケーリングする必要がある。
スケーリングの方法も重要だ、RX65Nの内蔵メモリはあまり大きく無いので、画像のような大きなデータを扱う場合、出来れば、一時メモリを使用しない(利用できない)方が良い。

それらを踏まえて、画像のデコーダーテンプレートは、直接画像の操作を扱うAPIを叩かないで、中間に「スケーリング」を行うオブジェクト(クラス)を入れる事にした、こうしておけば、レンダリングを行う対象がどんな場合にも対応可能となる。

    typedef graphics::render<uint16_t, LCD_X, LCD_Y, AFONT, KFONT> RENDER;
    RENDER      render_(reinterpret_cast<uint16_t*>(0x00000000), kfont_);
    typedef img::scaling<RENDER> PLOT;
    PLOT        plot_(render_);
    typedef img::picojpeg_in<PLOT> JPEG_IN;
    JPEG_IN     jpeg_(plot_);

C++ では、「ファンクタ」と呼ばれる方法(通常「()」オペレーターを使う)で、クラスに対しての操作を一般化できる。

//-----------------------------------------------------------------//
/*!
    @brief  描画ファンクタ
    @param[in]  x   X 座標
    @param[in]  y   Y 座標
    @param[in]  r   R カラー
    @param[in]  g   G カラー
    @param[in]  b   B カラー
 */
//-----------------------------------------------------------------//
void operator() (int16_t x, int16_t y, uint8_t r, uint8_t g, uint8_t b) noexcept
{
・・・
}
まず、plot_ クラスに対して、スケールを設定する。
※スケールは、「整数比」で設定する。
※画像全体を収める為、縦か横で長い方を基準にする。

    auto n = std::max(ifo.width, ifo.height);
    plot_.set_scale(272, n);

jpeg_ クラス内から、plot_ クラスに対して、以下のように普通に描画すれば、設定された拡大、縮小比で描画される。
※ワークメモリを使わないのと引き換えに、描画する領域は、あらかじめ「0」クリアしておく必要がある。

    plot_(x, y, r, g, b);

また、描画時にオフセットを与えられるようにしてある。

    plot_.set_offset(vtx::spos(480 - 272, 0));

最初、縮小をさせる場合に、エイリアシングを考慮しない簡易的な実装を行ってみたのだが、当然のように描画品質はあまり良くない。
※ジャギジャギしてる・・

そこで、ピクセルの加重割合を考えずに平均化してみる事にした。
・フレームバッファはRGB565となっている。
・フレームバッファを読み出して、「0x0000」なら、初期に書き込むピクセルとして、そのまま書き込む。
・もし、新規に書き込むピクセルが「0x0000」なら、「0x0001」に直して書き込む。
・フレームバッファを読み出して、「0x0000」以外なら、既に書き込まれている値なので、新規に書き込む値との平均(1/2)を求めて書き込む。

この実装は、厳密な意味では正確ではないものの、「ジャギー」感が減り、かなりマシに見える。
とりあえず、これで良しとした、ピクセルサイズによる厳密な加重平均や、フィルタ的要素は、次の課題とする。

※現状では、「拡大」する場合は、簡易的なものになっていて「ジャギー」が目立つ。

RXマイコンの最適化に対する知見

RX65N Envision Kit が発売されてもうじき1年がたとうとしているが、アプリケーションを作っている人は非常に少ないように感じる・・
サーチエンジンで探しても、あまり有益な情報を探せない、現在、秋月では売り切れとなっており、それなりに購入している人はいると思うのだが、何か面白いアプリを作って発表し、ソースコードを公開している人はほとんどいないように感じる。
何がハードルになっているのか?・・・
それに比べて、M5Stack、ESP32、ARMなど海外のマイクロコントローラーは、非常に沢山あるようなのだが・・・
※何かあったら、リンクを教えて下さい。

さて、以前に「Arduino 用レイトレーサー」を実装している人がいて、コードが公開されていたので、RX65Nにポートしてみた。
その過程で、ルネサス公式のフォーラムにそのリンクを張った。
しばらくして、色々な指摘を受けた。
※自分のブログにも同じような指摘が返信されていたが、検証の材料が無く、ほぼスルー状態だった。
※自分の間違った知見もある・・

ルネサスのフォーラムでは、具体的な実験を行い、検証を行ってくれた。(感謝)
※単に思いつきで返信するだけじゃなく、このような、有益な内容のある濃い情報が重要だ、言うだけなら誰でもできる、何か発信するなら、せめて、自分で「手」を動かして、検証可能な情報を返して欲しいものだ。

そこで、指摘された事についてまとめておきたい。

  • gcc では RXv2 コアの最適化が不十分
  • double 定数を使っているのが余計
  • std::sqrt はdoubleの関数なので、sqrtf を使った方が良い
  • RXv2には、fsqrt 専用命令が用意されている
  • ESP32 などで公開されているベンチマークは、レイのサンプリングは「1」で行っているがRXでは、「4」で行っていて条件が異なる

gcc の RXv2 の最適化に関しては、自分の考え方が少しある。
まず、gcc のオフィシャルなソースコードを使う事を前提としているので、ルネサス社が、gcc に最適化のコードをコミットするまで待つしかない・・
現在ルネサス社は、独自にGNUツールを公開しているが、最新版は4.8系となっており、C++ の最新のコードをコンパイルする事が出来ない。
※ルネサス社が提供するGNUツールでコンパイルした場合、最適化「-O3」で、最大7~15%くらい良いコードが出る場合があるようだが、これは今後検証してみたい。
※オフィシャルな gcc では、「-mcpu=rx64m」など専用デバイスのオプションは無いが、標準で、RX600 系のコード出力となっている。

double の定数や、double 専用 API は、指摘を受ける前に既に、変更済みで、それで、ほんの少し高速になっていた。

標準の数学ライブラリでは、平方根を求める「sqrt、sqrtf」はニュートン法を使っており、RXv2 に備わっている、fsqrt 専用命令とは微妙に計算結果が異なっているものと思うので、標準では使わないのだと思っていた。
だが、この命令に切り替えた場合、倍の速度でレンダリングするようなので、この知見を素直に受け入れた。

#if defined(SIG_RX64M) || defined(SIG_RX71M) || defined(SIG_RX65N) || defined(SIG_RX24T)
static inline float sqrtf_(float x)
{
    __asm __volatile(
        "fsqrt %0, %0\n" \
        : "+r"(x) \
    );
    return x;
}
static inline int ceilf_(float x)
{
    int y;
    __asm __volatile(
        "pushc fpsw\n"
        "mvtc #0b10, fpsw\n"
        "round %0, %0\n"
        "popc fpsw\n"
        : "=r"(y) \
        : "r"(x) \
    );
    return y;
}
#else
static inline float sqrtf_(float x) { return sqrtf(x); }
static inline int ceilf_(float x) { return ceilf(x); }
#endif

レイのサンプリング数に関しては、全くノーマークだった、元ソースでは、標準「4」だったので、素直に「4」で行っていたが、ベンチマークを行っている Arduino のスケッチでは、「1」にして API を呼んでおり(卑怯なのではw)、大体4倍のレンダリング時間となっていた。
※「STM32F7 200MHz」では、0.62秒と非常に高速なので、この違いは、何なのか、疑問に思っていた・・・

以上の知見を受け、RX65N Envision Kit でレンダリングすると・・・

約0.83秒と、STM32F7 200MHz と比較しても、十分戦闘力のある値となったw
元は7.7秒とかだったので、素晴らしいパフォーマンスアップとなった。
※ESP32(160MHz)は、13秒みたいだが、これは、他にバリアとなる事象があるように思う
※このような有益な情報を提供してくれた「fujita nozomu」氏に感謝したい!

全ソースコードは以前から公開しているが、コンパイル環境を作り、フレームワークなどをチェックアウトする必要があるので、実行バイナリーも公開している。
・裏にあるスイッチを押す毎に、フルスクリーン(480×272)、レイのサンプリングを変更してのレンダリングを行う。

「raytracer.hpp」は、かなり柔軟性があり、ベンチマークには最適なので、PIC32や、他のマイコンでも十分実行できる、別のマイコンで試した人がいれば、是非情報を公開して欲しい~

WR250Xのバッテリー交換

昨日、大月から談合坂SAへ昼飯を食べに近くのにバイクに乗ったら、セルの回りが凄く弱っていると感じたー
これは、かなりヤバイレベル。
※山梨は、都心に比べて寒いので、バッテリーの劣化は注意を要すると思う。
※出先で、セルが動かなくなったら、WR250の場合、押しがけでエンジンを始動するのは凄く難しいと思う。
※ニュートラルにしないとオートデコンプが機能しない?(実際はやった事無いので、判らないが、あの高圧縮比のエンジンはクランクが相当重そうだ)

リチウムイオン系バッテリーは、2年前に買っていたが、元々のシールドバッテリーがまだ元気だったので、交換しないでいた・・(2年も持つとは・・)

リチウムイオン系バッテリーは同等の容量でも小さく軽い、今回買ったのは、容量的にはリッターバイクでも使えるものだが、それでも小さく軽い。
※LFX14L2-BS12
※バッテリーは、容量(大きい分には問題無い)の他、+、-端子の向きや位置が異なるものがあるので、十分適合を確認しておく必要がある。

パッケージには、サイズを合わせる為スポンジシートが色々入っていて、適当に切り貼りして、大きさを合わせる事が出来る。

交換は簡単で、10mmのソケット(シートを固定しているボルト)、5mmのスクリューキャップ、+ドライバー、カッター
交換して、元気にセルが回るようになったー
※サイドカバーは、シートを外さないと、外しにくい

チェーン、スプロケも交換用に買ったのだが、もう少し大丈夫な感じだ・・