ＲＸマイコンのフラッシュ書き込みでは、自分は、シリアルインターフェースによる書き込みが基本だ。

Ｅ１も持ってはいるが、ＯＳ－ＸやＬｉｎｕｘでは使えないし、１４ピンのコネクタを繋ぐのも億劫だ。
それに、エミュレーターをほとんど使わないので、フラッシュの書き込みにしか用途が無い。
そうなるとＵＳＢシリアルを使って、シリアル通信で書き込む方が簡単だと思う。
※書き込みツールも独自に対応している。

最近まで、アマゾンで買える格安の中華ＵＳＢシリアルとしてＣＰ２１０２を押していたが、状況が変わってきている。
問題として、以下の事項がある。

• 使っているデバイスは古いＣＰ２１０２（現在はＣＰ２１０２Ｎが主流、古いデバイスを使っているのが安い理由なのかもしれない）
• 複数のＣＰ２１０２を一旦接続するとＣＯＭポートの移り変わり現象が発生してまともに使えなくなる。
• 複数接続するには、専用ツールで、内部シリアルＩＤを変更して、固体識別をさせる必要があるようだ。
• ＣＰ２１０２では、専用ツールが正常に機能しないし、ツールのインストールからしてハードルが高い。
• 色々やったが、ＣＰ２１０２では内部シリアルＩＤを変更する事が出来なかった。（理由が不明）

そこでやっぱり正統派ＦＴＤＩだと思い、ＦＴＤＩでも格安なＦＴ２３１ＸＳを使おうと思ったが、これには別の問題がある事が判った。（以前に自作したもの）

通信速度が明らかに遅い！

RX66T にレイトレーシングのプログラム（バイナリーで４７K程度）を書き込んだ場合の時間：
※２３０４００ボー、８ビット、１ストップビット
FT231XS: 16.6 秒
CP2102:   6.6 秒
上記のように、同じボーレートで条件は同じなのに、３倍近く通信速度が違う。
FT231XSは安い廉価バージョンなので、高級バージョンのFT232RLの場合も確かめてみた。
FT232RL:　18.1 秒
驚きだ、FTDIのデバイスは値段に関係無く、シリコンラボ製に比べてかなりパフォーマンスが劣るようだ・・・
※以前にシリアル通信を使った機器を作った時に感じたが、詳しく評価しなかった。（そんな事が起こるとは思ってない）
J-TAGなどの代用によく使われる、FT232HLも手元にあったので、試してみた。
FT232HL:　17.5 秒
※全然ハイスピードじゃねぇ・・・

上記書き込み時間は、イレース時間、書き込み時間、比較時間などが組み合わさったもので、送信、受信をかなり頻繁に行い、目安なのだが、単純な送受信ではないアプリケーションレベルでの利用なので、逆に、ベンチマークには適しているとも思う。

そこで、今度は、CP2102Nを評価してみたい（主にシリアルＩＤの変更）と思ったが、調べてみると、CP2102Nを使ったモジュールは少ないようで、入手出来ていない。
※CP2102Nを使った、メーカーの標準キットが１０００円くらいなのだが、送料がかかるのが痛いとこだ（同時購入品が何かないと・・・）

現状は、そんな状態だ、進展があったらまた報告するが、どちらにしてもFTDIを使う理由は無いだろうな・・・

多少複雑なアプリなどを実装する場合、動作の推移を行う管理機構が必要になる事が多い。
やり方は色々だが、組み込みシステム向けに、シンプルな機構を実装したので紹介する。
平行処理にする程でも無い場合など、少し大きい単位で処理を分けて、影響範囲を限定的にする事が出来る。
※この方法は既に色々なシステムで利用しているが、多少アレンジした点として、以下のトピックがある。

• シーンオブジェクトによる推移管理。
• 可変引数テンプレートの利用。
• std::tuple テンプレートを使い、シーンオブジェクトを管理。
• 記憶割り当てを使わない。

まず、一つの推移単位をシーンクラスとして、インターフェースクラスを継承させている。
インターフェースクラスは以下のようなものとなっている。
※C++ では「= 0; 」とする事で「純粋仮想関数」とする事が出来る。（薄い皮のような物）
※デストラクタを「仮想」として実装しておく必要がある。

struct scene {
    virtual ~scene() { }        ///< デストラクタ
    virtual void init() = 0;    ///< シーン開始前処理
    virtual void service() = 0; ///< シーン・サービス
    virtual void exit() = 0;    ///< シーン終了処理
};

• シーンを開始する前に必ず「init()」を呼び出す。
• シーン中は「service()」が呼ばれ続ける。
• シーンが切り替わる時、シーンを終了するタイミングで「exit()」が呼び出される。

シーン作成時、上記「scene クラス」を継承させて実体を実装する。
以下は「title」クラス。

class title : public scene {

public:
    void init() override
    {
    }

    void service() override
    {
    }

    void exit() override
    {
    }
};

通常シーンは複数あり、シーン管理機構で管理される、アプリケーション側は、各シーンの中身を実装する。

シーン管理クラス（scene_director）では、個々のシーンの実体をstd::tuple で保持しており、切り替えの操作や手順を提供する。
scene_director は、可変引数テンプレートを使って、ユーザー定義のシーンクラスを複数受け取る。

 template<class... Args>
 class scene_director {

    typedef std::tuple<Args...> SCENES;
    SCENES  scenes_;

    scene*  cur_scene_;
    scene*  new_scene_;

public:
    scene_director() noexcept : scenes_(), cur_scene_(nullptr), new_scene_(nullptr)
    { }

    template <class T>
    void change() noexcept
    {
        auto& news = std::get<T>(scenes_);
        new_scene_ = &news;
    }

    void service() noexcept
    {
        if(new_scene_ != nullptr) {
            if(cur_scene_ != nullptr) cur_scene_->exit();
            new_scene_->init();
            cur_scene_ = new_scene_;
            new_scene_ = nullptr;
        }

        if(cur_scene_ != nullptr) {
            cur_scene_->service();
        }
    }
};

このテンプレートを使い、以下のように全体を定義する。

#include "scene_director.hpp"
#include "title.hpp"
#include "menu.hpp"
#include "setup.hpp"

typedef scene_director<title, menu, setup> SCENES;
SCENES   scenes_;

これで大体全てなのだが、大きな問題がある、通常シーンの切り替えは、scene_director の change メソッドを使うのだが、各シーンから、scene_director にアクセスするには、scene_director のインスタンスと定義、各シーンの型などが必要で、それにアクセスする手段を設けるのは難しい。
そこで、かなり冗長でシンプルでは無いが、各シーンに通し番号を振っておき、この番号で切り替える機構を設けて、この関数呼び出しを extern しておく事にした。
各シーンの切り替えは「整数」なので、定義がシンプルでどこからでも呼び出せる。
※ただ、シーンとIDを二重に管理しなければならず、かなり痛い・・・

void change(scene_id id)
{
    switch(id) {
    case scene_id::title:
        scenes_.change<title>();
        break;
    case scene_id::menu:
        scenes_.change<menu>();
        break;
    case scene_id::setup:
        scenes_.change<setup>();
        break;
    }
}

※他の注意点として、インスタンス化の順番を理解しておく必要がある。
scene_director がインスタンス化されるタイミングで、各シーンのコンストラクターが呼び出されるので、各シーン中で何かをインスタンス化している場合、それが関わるクラスは、事前にインスタンス化されておかなければならない。
システムが複雑になると、忘れがちなので注意する必要がある。

※ソースコードは、「RX/common/scene.hpp」にある。

ＲＸ６６Ｔを入手したので、レイトレースを実行してみた。

その中で、RX65N Envision kit のコードを標準的にして、他のデバイスも評価していたが、LCDへの転送は、ポートバスによるソフトウェアー書き込みになっている。
水平ライン毎に、レンダリング時間を描画しているが、ポート経由だと、フォント描画がボトルネックになっている事実などがあり、コーディングを整理した。

まず、各マイコン別のタイムを表にしたので参考にしてもらいたい。
※今回、RX64M も加えた。

型番	動作周波数 [MHz]	ROM	RAM	実時間 [ミリ秒]	価格 [円]
R5F524TAADFP RX24T	80	256K	16K	1224	974 (572/10)
R5F565NEDDFB RX65N	120	2M	640K	784	1910 (1320/10)
R5F564MFCDFC RX64M	120	2M	512K	751	2120 (1570/10)
R5F566TEBDFP RX66T	160	512K	64K	602	900（参考）
R5F571MFDDFC RX71M	240	2M	512K	439	2600 (1940/10)

RX66Tの価格は、RSコンポーネンツで１個購入時のもので、チップワンストップで扱うようになれば、多少異なると思う。

描画ハードに関して、RX64M、RX66Tは、実際にはLCDを接続していないが、RX64MはRX71M、RX66TはRX24Tと同一のインターフェースがあるものとしているので正確だと思う。
※ポート経由の描画オーバーヘッドは、RX66Tで１１８ミリ秒もある。（ただRAMに書くだけだと４８４ミリ秒）

通常、描画時間は、ライン毎に％表示されるが、ソフトによるポートバスでは、オーバーヘッドがかなり大きいので、その部分をコメントアウトして、描画後に１回だけ表示するようにしている。

RX66TのRXv3コアの評価は、この結果からはイマイチ判らないが、RX71MやRX64Mの値からすると、やはり少し効率が高いようだ、ただ、浮動小数点演算が多いので、イマイチ参考にならない。

現段階でも、CPはRX66Tがもっとも優れていると言える。

ソースコードなどは、Github のRX/RAYTRACER_sample に全てある。

---

EMLE 端子のプルダウンを入れてから、フラッシュの書き込みは一度も失敗しないようになった。

ルネサスＲＸマイコンを購入する場合、自分の場合「チップワンストップ」がほとんどで、他ではほぼ買わない（値段が一番安く、種類が豊富、個数割引もあるので）。

ＲＸ６６Ｔは、発表されてからかなりたつものの、未だにチップ単体での販売はされていない。

ところが、ツイッターで「ＲＸ６６ＴでＬチカした」とゆーツイートを見つけた・・
※変換基板だったので、デバイス単体で入手したようだった。
ツイートした人はマイクロマウスをやってる人のようで、「どうやって入手したの？」と聞いたが連絡は取れず、色々調べたら「ＲＳコンポーネンツ」で販売している事を見つけた。
１個９００円と少し高いと思ったが、早く試してみたかったので、早速１個購入した。
※それにＲＸマイコンも１０周年らしぃのでｗ
※現在（４月９日）、ルネサスのＨＰでも、ＲＸ６６Ｔの販売先としてはどこも登録されていない。
※次の日には届いて、変換基板にハンダ付け。
※購入した型番は「R5F566TEBDFP」で、PGA 差動入力なし、USB なし、100 ピン、プログラムフラッシュ 512K、RAM 64K、データフラッシュ 32K

写真のハンダ付けはちょっと汚いが、一応ブリッジや接触不良は無いものと思う。（よく確認した）
いつものように「直付」する為、裏側をカプトンテープで保護する。

ユニバーサル基板に直接乗せ、ガイドとして、適当なヘッダーピンを刺しておき、対角のピンにハンダを流して、変換基板と、下のユニバーサル基板を固定する。
後は、電源ライン、ＭＤ端子、クリスタル関係、リセットＳＷ、シリアルラインなど、最低限必要な線だけ配線する。

---

• (20) PD5/RXD1 <--- TXD (USB Serial)
• (22) PD3/TXD1 ---> RXD (USB Serial)
• (6) MD L：Boot、H：Run
• (1) /RES
• (5) VCL GND 間に 0.47uF
• (11) XTAL 10MHz、GND間に 8pF
• (13) EXTAL 10MHz、GND間に 8pF
• (2) EMLE 4.7K で プルダウン（エミュレーターイネーブル）
• (15) PE2/NMI 10K でプルアップ

rxprog も、RX66T 用にプロトコルを追加して、LED 点滅は直ぐに動作した。
RX66T関係のデバイス定義は、発表と同時くらいに、ハードウェアーマニュアルをダウンロードして、実装していたので、ソフトの準備はそれなりに出来ていた。
RX66T の内部構成は、RX24T よりRX64M 系に近い。
今回入手したデバイスは、USB は内臓していないバージョンだが、ラインナップには USB 付きもある、その場合、内臓クロックは１２の倍数にする必要があり、144MHz 動作になってしまうと思う（最高速は160MHzなので少しもったいない）。

static void micro_second(uint32_t us)
{
    while(us > 0) {
#if defined(SIG_RX64M) || defined(SIG_RX63T) || defined(SIG_RX71M)
        for(uint32_t n = 0; n < (F_ICLK / 4285714); ++n) {
            asm("nop");
        }
#elif defined(SIG_RX65N)
        for(uint32_t n = 0; n < (F_ICLK / 4444444); ++n) {
            asm("nop");
        }
#elif defined(SIG_RX24T)
        for(uint32_t n = 0; n < (F_ICLK / 4444444); ++n) {
            asm("nop");
        }
#elif defined(SIG_RX66T)
        for(uint32_t n = 0; n < (F_ICLK / 3346666); ++n) {
            asm("nop");
        }
#else
#  error "delay.hpp requires tune dummy operations"
#endif
        --us;
    }
}

RX66T は、RXv3 コアとなっており、実測による簡単なソフトループだが、今までのRXコアより１５～２０％くらい速いようだ。
※同じバイナリーでこれだけ高速なのは、驚くべき性能だと思う。
※ちゃんとしたベンチマークは後ほど行う予定

現在の問題として、フラッシュプログラム中に停止する症状がある。
これは、原因を特定出来ていない・・・
とりあえず、rx_prog.conf のシリアル速度を、２３０４００から１１５２００に落としたら、多少安定して書き込めるようなので、当面そうしておく。
※RX64M、RX71M、RX24T では、問題無いのだが・・・

とりあえず
FIRST_sample/RX66T（LED 点滅）
SCI_sample/RX66T（シリアル通信）
は、動作する事を確認した。

※RX66T では、SCI のベースクロックは、PCLKBを利用するが、このクロックの最大は60MHzで、内臓クロックを160MHzで動かす場合、最大では40MHzとなる。

---

フラッシュ書き込み時にハングアップする原因が判ったと思う。
ＲＸ６６Ｔでは、ＥＭＬＥ端子が増設された、「１」でエミュレーターイネーブルなので、とりあえずＧＮＤに落としておいたが、これが原因のようだ、４．７Ｋでプルダウンしたら、安定して書き込めるようになった。
多分、フラッシュ書き込み時などに一瞬出力になる場合があるのだろう・・
※ボーレートは関係無かった。

既に、「glfw_app」などで行っていたのだが、ＲＸマイコンの開発環境でも、boost を使うようになった為、Makefile の修正を行った。
※プロジェクトの数が多いので、主要な部分のみ行った。

boost は、パッケージマネージャーでインストールするのが標準的となったので、環境毎にパスを追加で指定しなければならない。
そこで、以下のようなスクリプトで、環境を識別して、内部変数を設定している。

# Include path for each environment
ifeq ($(OS),Windows_NT)
SYSTEM := WIN
LOCAL_PATH  =   /mingw64
else
  UNAME := $(shell uname -s)
  ifeq ($(UNAME),Linux)
    SYSTEM := LINUX
    LOCAL_PATH = /usr/local
  endif
  ifeq ($(UNAME),Darwin)
    SYSTEM := OSX
    OSX_VER := $(shell sw_vers -productVersion | sed 's/^\([0-9]*.[0-9]*\).[0-9]*/\1/')
    LOCAL_PATH = /opt/local
  endif
endif

INC_SYS     =   $(LOCAL_PATH)/include

これで、Windows(MSYS2)、Linux、OS-Xの違いを識別して、適切な「パス」を設定できる。
OS-X では、OS のバージョンも抜き出している。

他、emacs を起動した場合の TAB を強制的に指示する為、以下の「おまじない」をファイルの先頭に追加した。

# -*- tab-width : 4 -*-

さらに、既に２０１９年だが、今まで「C++14」を指定していたコンパイルオプションを「C++17」に変更しておいた。

PFLAGS      =   -std=c++17 $(CP_OPT) $(OPTIMIZE) $(MCU_TARGET) $(DEFS)