かなり昔に、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
※一応、テストで使っているプロジェクト

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

デバイスは、主に、ＲＡＭが１２８ＫＢと６４ＫＢの製品があり（コードフラッシュは２５６Ｋ～１Ｍ）、多分、最初に出てくるのはＲＡＭが６４ＫＢの製品と思う、また、ＵＳＢも無しタイプが最初だろうと思う。
※コードフラッシュは２５６Ｋで十分だが、５１２Ｋ版との価格差は少ないものと思う。

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

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

ＲＸ６６ＴにはＵＳＢ内臓タイプがあるが、クロックレジスタの構成を考えると、ＵＳＢを使う前提だと、最大周波数の１６０ＭＨｚでは動かせないと思う。
※ＵＳＢで基準になる、２４ＭＨｚの倍数で動かす必要があると思うので、１５６ＭＨｚ動作になると思う（２４ＭＨｚ×６．５倍）。
ＲＸｖ３コアは、ＲＸｖ２コアに比べて、命令の効率が高いので、周波数が同じでもＲＸｖ２コアに比べてパフォーマンスが高いと思われる、どのくらい高いのか、早くデバイスを入手して試してみたい！
※多分、レイトレーサーを動かす事になると思う。

デバイスは、果たして、幾らで買えるのか？
ＲＸ２４Ｔと同じく、１０個購入程度で、それなりに安く買えるとありがたい・・
※上記ボードは、ルネサス純正ボードで、１３２００円（自分は高いのでスルー）

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

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

画面デザインから、画面の右端に２７２×２７２ピクセル（液晶の縦ピクセル）で表示させるのが良さそうだ。
ただ、タグ内の画像サイズは様々なので、適切にスケーリングする必要がある。
スケーリングの方法も重要だ、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_ クラスに対して、以下のように普通に描画すれば、設定された拡大、縮小比で描画される。
※ワークメモリを使わないのと引き換えに、描画する領域は、あらかじめ「０」クリアしておく必要がある。

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

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

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

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

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

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

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

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

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

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

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

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

ｇｃｃ の RXv2 の最適化に関しては、自分の考え方が少しある。
まず、ｇｃｃ のオフィシャルなソースコードを使う事を前提としているので、ルネサス社が、gcc に最適化のコードをコミットするまで待つしかない・・
現在ルネサス社は、独自にGNUツールを公開しているが、最新版は４．８系となっており、C++ の最新のコードをコンパイルする事が出来ない。
※ルネサス社が提供するGNUツールでコンパイルした場合、最適化「-O3」で、最大７～１５％くらい良いコードが出る場合があるようだが、これは今後検証してみたい。
※オフィシャルな ｇｃｃ では、「-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

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

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

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

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

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

以前に JPEG デコーダー「libjpeg」ライブラリーをポートしようと思ったものの、記憶割り当て不足で、実用的に使えなかった。
※libjpeg では、内部で画像サイズのRGBメモリを割り当てる為、当然のようにメモリ不足になってしまう。
ルネサスでは、オリジナルの JPEG（RXv2 DSP 命令で最適化した）ライブラリを公開しているようだが、肝心のコア部分ソースコードは未公開で、バイナリ化されており、ｇｃｃ からは使う事が出来ないようだった。
そこで、libjepg を改修して、記憶割り当てを何とかしようと思ったが、既に、JPEGのデコードを少メモリで実現する「PicoJPEG」がある事に気が付いた。
なので、このライブラリを使わせてもらう事にした。

ポートは簡単で、「picojpeg.c」をコンパイルしてリンクするだけだ。
ただ、コンパイルエラーが出たので、多少修正した。
※ sequence-point のエラー
※このエラーは、式の評価順番に関係するもので、オリジナルの書き方は、C 言語の規約では「未定義」となるもののようだ。
https://www.jpcert.or.jp/sc-rules/c-exp30-c.htm

    *pDstR++ = addAndClamp(pDstR[0], crR);

以下のように書き換えた。

    *pDstR = addAndClamp(pDstR[0], crR);
    pDstR++;

サンプルを参考に C++ から簡潔に呼べるようにラッパーを実装した。
ラッパーは、テンプレートライブラリで、描画クラスを「参照」で与える仕様とした。
※BMP のデコーダーと同等の仕様。

ただ、PicoJPEG デコーダーは、「プログレッシブ」でセーブされたフォーマットをサポートしておらず「ベースライン」のみとなっている。
※「プログレッシブ」は、ブラウザなどで、最初荒く、後、詳細に表示するもので、通信速度が遅かった昔の名残で、最近のネット速度を考えると、ほぼ使う必要が無いモードと言える。
※プログレッシブ・エラーが出た場合には、フォームを確認して、「ベースライン」でセーブする必要がある。

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  PicoJPEG デコーダー
    @param[in]  RENDER  描画ファンクタ
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <class RENDER>
class picojpeg_in {
.....
};

※描画を行うクラスを「RENDER」で渡す。
※「RENDER」クラスでは、「plot」APIを通して描画を行う。
picojpeg_in.hpp

今回、RX65N Envision Kit （AUDIO プレイヤー）でデコードと描画のテストを行った。
https://github.com/hirakuni45/RX/tree/master/RTK5_AUDIO_sample
※ターミナルからの「jpeg」コマンドでJPEGファイルを描画できる。

また、ID3 に含まれるPIC、APIC タグで埋め込まれたJPEG画像をデコードして表示させるようにした、ただ、適切なスケーリングをしていない為適切な大きさで表示されない。
※これは、今後対応する事にする。
又、PNG 画像もサポートされない・・

少し落ち着いたので（実際は、やるべき事が山済み状態だけど・・）気になっていた部分をクリーンナップしている。
現在、俺俺フレームワークは、リアルタイムＯＳの助けを借りない方法で実装を行っているので、一連の長い処理を書く場合などにはコールバックの仕組みを与えている。
C++11 以降、STL には、そのような場合便利で安全な方法が多数用意されている。
しかし、その場合、通常は「stdc++」をリンクする必要があり、その場合、許容出来ない程大量のワークエリアを消費し、実用的では無い場合があった。

さて、コールバック機能を実装する場合、どうしても、「std::function」を使いたい。
・このテンプレートは、非常に強力かつ高機能だが、詳しい使い方は、検索してほしい。
・このテンプレートにする最大の理由は、ラムダ式が使える事で、コールバックの中身を「直」で実装できる。

しかしながら、これを使うとなると、関連する例外処理など他の機能を利用している為、stdc++ ライブラリのリンクが必須となってしまう。
しかし、よく調べると、g++では、「supc++」ライブラリが分離されておりこれをリンクすれば、最低限の消費で済む事が判った。
※「supc++」は「stdc++」ライブラリのランタイム部分のみ。
※例外の外部関数を実装する必要がある。

namespace std {
    void __throw_bad_function_call()
    {
        abort();
    }
}

※コンパイラオプションで例外を禁止していても、これだけはリンクする必要があるようだ。
※これは、「common/stdapi.cpp」に分離してあるので、Makefile にこのソースを追加する必要がある。

コールバック関数の登録で、重要となるのは、たとえば、クラス内からコールバックを設定するような場合だが、普通に書いた場合、「static」な関数しか登録できない。
※それでも別の逃げ方が無い訳では無いが、少し面倒・・
static だと、クラス内の public メンバーなどにアクセス出来ない。
そこで便利なテクニックとして、ラムダ式によるキャプチャー機能を利用する事で、以下のようにクラス内メソッドを呼び出す事が可能となる。

void play_loop_(const char* root, const char* start)
{
    static loop_t t;
    t.start = start;
    if(strlen(start) != 0) {
        t.enable = true;
    } else {
        t.enable = false;
    }
    sdc_.set_dir_list_limit(1);
    sdc_.start_dir_list(root,
        [&](const char* name, const FILINFO* fi, bool dir, void* option) { play_loop_func_(name, fi, dir, option); }, true, &t);
}

上記コードは、オーディオプレイヤーのコードで、ディレクトリーを巡って、オーディオファイルを再生する。
「sdc_.start_dir_list()」で、ファイル情報アクセス時に、設定されたコールバックが起動する。
「play_loop_func_」は、ラムダ式のキャプチャー「[&]」が あり、クラス内のリソースにアクセスする事が出来る。（これは本当に便利だ！）

まとめ：
「std::function」を使う事で、関数オブジェクトの利便性が強化された、これは、C++11以降の恩恵で、かなり大きなトピックと言えるが、組み込みマイコンのような制限されたリソースでもそれを活用できる事が判った事は大きい～

かなり昔にデバイスは購入してあったのだが、中々試せないまま、ＲＸ６５Ｎなどに寄り道していたのだが、２４０ＭＨｚの実力を評価したくて、一応試してみた。
ＲＸｖ３
の発表があり、「ＲＸ７１Ｍ」も最高性能のＲＸマイコンでは無くなってしまったが、それでも、２４０ＭＨｚは１２０ＭＨｚ版に比べてどのくらいの性能があるのか試しておきたい。

１６９ピンのユニバーサル基板も手持ちが最後なので、次は基板を起こす方が良さそうだ・・（この基板、安くて小さくて便利なのだが、販売終了しているぽぃ）
以前にＲＸ６４Ｍの試作では、ＳＤＲＡＭの３２ビットバスを試したが、あれは、ちょっとマズイ・・、３２ビットのデータ幅を割り当てると、他に使うペリフェラルが極端に制限されてしまい、イーサーネットやＳＤＨＣに割り振る事が難しくなる、なので、今回は１６ビットバスでＳＤＲＡＭを載せようと思う。
※このデバイスは「もらった」もので、ＳＤＨＣ未対応なのだが・・・
ＲＸ６５ＮのEnvisionキットでファミコンエミュレーターなどを試して、やはり外部メモリーは必須だ・・（内臓メモリが１Ｍバイトくらいあれば・・）
ＲＸ７１Ｍには、ＲＸ６５ＮのようなＬＣＤ制御機能は無いが、単純に接続するだけなら、ＥＸＤＭＡ転送で代用できそうだし、ＳＳＩ（シリアルサウンドインターフェース）など、デジタルオーディオ系にも強そうだ。

今回試作して判った事として、電源ラインの重要性だった、面倒なので、アナログの電源は接続しなかったのだが、それが原因で、ブートモード（ＳＣＩインターフェース）でデバイスのコネクションが正常に終了せず、接続できなかった、電源は全て接続してパスコンも付けていたのだが、原因がわからずにいたが、関係無いと思うけど的な感じで、アナログ電源を接続したら、あっけなく正常動作した。

２４０ＭＨｚ動作は、既に実績があると（依然にＲＸ７１Ｍを使ったボードを設計して、納入した実績があり、その時は問題なかった・・）思っていたが、何か怪しい動作をする。
具体的には、２４０ＭＨｚで動かすと、ＳＣＩ関係で文字化けを起こす・・
ＣＰＵのクロック以外は、１２０ＭＨｚ版と変わらないので、原因が判らない・・
プログラムは暴走する訳ではなく、動いているようだ。
１２０ＭＨｚであれば問題無い・・
どうも、２４０ＭＨｚ動作時は、最大で２４０ｍＡの電流が必要らしいので、そのせいかと思ったが違うようだ・・
ただ、ＵＳＢから供給する電源の品質はあんまし良くないのと、瞬間的に大きな電流を「引く」とかなりドロップする。

オシロで、ＳＣＩの信号を確認して、やっと解決、ベースクロックのＰＬＬ定数を求めるソフトのバグだった・・、240MHzと思っていたら１８０ＭＨｚだった。
※そりゃー文字化けするよなぁーｗｗｗ
クロック設定クラスは、以前に収めた機器では、２４０ＭＨｚ固定だったのだが、最近テンプレート化して、色々柔軟性を求める仕様に拡張した過程で、マズイ実装を行っており、１２０ＭＨｚだけは正確に機能していた・・・
ハードの問題だと思って色々対策して、結局ソフトのバグとゆーのは、まぁ良くある話なのだがー、最近視力が落ちて、配線の質が落ちており、ハードに自信が無いと思っているのもある・・
さらに、鉛フリーハンダは、温度に敏感で、少し低いと綺麗に付かない。