今まで、ＲＸマイコンで、挙動が怪しい事があって、その原因が判らなかったが、
やっと判明した・・・

症状としては、
・スタックに配置した変数が書き換わる場合
・割り込みが多重に起動するような場合に多く発生
・多重じゃなくても割り込み関連が絡む場合など

どうもスタックが壊れている感じではあるけど、プログラムを追っても、問題無
さそう・・・

ＲＸマイコンでは、スタックは、割り込み用スタック（ＩＳＰ）と、ユーザース
タック（ＵＳＰ）に分かれていて、起動時、「start.s」のアセンブラプログラム
で設定されている。
ＩＳＰをメモリーの後半に置き、その手前にＵＳＰを設定している。
当初、ＩＳＰの容量は３２バイトくらいしか無かったので、２５６バイトにした
が、症状に変化は無い・・・

    .text
    .global  _start
    .type    _start,@function
_start:

# スタックの設定（SP：__stack、USP：__stack - 128）
    mov.l       #__stack, r0
    mvtc        r0, isp
    sub         #128,r0
    mvtc        r0, usp

ソフトウェアーマニュアルを読み直していたら、何と「Ｒ０」レジスタと「ＳＰ」
は扱いが同一となっていた！

汎用レジスタ R0 には、汎用レジスタとしての機能に加えて、スタックポインタ
（SP）としての機能が割り当てられています。

あ！、「Ｒ０」は使ったら駄目なんだ・・・・・・・・・

そこで、単純に、レジスタ名を変更

    .text
    .global  _start
    .type    _start,@function
_start:

# スタックの設定（SP：__stack、USP：__stack - 128）
    mov.l       #__stack, r5
    mvtc        r5, isp
    sub         #128,r5
    mvtc        r5, usp

この修正後、今までのおかしな挙動が直った。

今まで、結構大きなプログラムを動かしていたけど、よく動いてたなぁ・・・

経験的に、レジスターセットの後ろ（Ｒ１５とか）にＳＰを置いてあるのが普通と
思っていたから、何も考えずに、Ｒ０を使ったのが間違いだった・・・
※ソフトウェアーマニュアルを良く読まなかったのが悪いのだけど・・・

-----
ＲＸマイコンでは、スーパーバイザーモードとユーザーモードのＲＵＮレベルがあり、
通常はユーザーモードで動作させる。

ユーザーモードで特権命令を実行すると、「特権違反例外」が発生する。

ユーザーモードに移行するには、「rte」命令などを実行した場合に、退避してあった
ステータスレジスターを復帰するが、その際、ユーザーモードフラグが有効になって
いれば、ユーザーモードに移行する為、以下のような、少しキワドイプログラムで移
行する。

# PMレジスタを設定し、ユーザモードに移行する、ユーザースタックに切り替わる
    mvfc    psw,r1
    or      #0x00100000, r1
    push.l  r1

# UレジスタをセットするためにRTE命令を実行する
    mvfc    pc,r1
    add	    #10,r1
    push.l  r1
    rte
    nop

※ＰＣにオフセットを加える事で、ＲＴＥ命令の下に復帰する。

ようやく、ＳＤＲＡＭのテストを開始、結線は多いが、高速な大容量外部
メモリを得られる。
デバイスだけでも５１２Ｋバイトのメモリーを持っているので、通常は十
分ではあるけど、このようなデバイスじゃないと、ＳＤＲＡＭを制御する
為のハードウェアーを内臓していない、又、１６９ピンのデバイスじゃな
いと、３２ビットの外部バスをサポートしていない。
※最大のパフォーマンスを得たいので３２ビットバスで動かしてみたい。

普通は、基板を起こすべきなのだろうけど、実験ではそうもいかない。
と、言っても最近では、海外のメーカーに発注すれば、基板を新規に作成
するコストは尋常じゃ無く安いので、いきなり基板を起こしてみるのも悪
くないかもしれない。

クロックが高いので、手配線では動作が難しいかもしれないが、バスに接
続するＳＤＲＡＭは、ＣＰＵの動作速度の半分でしかないので、（およそ
６０ＭＨｚ）このくらいなら、手配線でも何とか動作すると思う。
「反射」が起こって動作が不安定になった場合は、ダンピング抵抗を調整
してインピーダンスの整合を行えば、何とかなるのでは無いかと考えてい
る。
※変換基板では、電源ラインが相対的に弱くなるのが多少気になる。

デバイスは３００円（１２８メガビット）なのに、変換基板（Aitendo 産）
が２５０円するけど、他に、収まりが良く、スペースが少ない変換基板が
無かった。

※基板を起こす時には２５６メガビット品を使うと思うが、組み込み用途
のＳＤＲＡＭを単体で入手（秋葉原などで）できるのは限られている。

最近は、０．５ｍｍピッチのハンダ付けが多かったので、０．８ｍｍピッ
チは、凄く楽だったーー
変換基板には、何故か余分な部分があるので、カットして、裏面にある謎
の端子パッドも、いつものようにポリイミドテープで絶縁、ベース基板と
直接コンタクトさせる。

※ピン番号のシルクが一部間違っている・・（２８、２９ではなく、２７、
２８ね・・）
※ポリイミドテープの存在を知らない時は、「紙」を貼っていた。ｗｗｗ

まず、電源ラインを配線してから、十分なパスコンを接続、それから配線
を行った、データバスは、液晶を接続するのにも使うので、別途、コネク
ターに出す。
・電源の配線

参考回路（ルネサスのＲＸ６４Ｍボードの例）

厄介なのは、ＳＤＲＡＭの場合、初期化処理を行わないと、使う事ができな
い点で、それなりのパラメーターがある、とりあえず、ベストな設定より、
必ず動作しそうな無難な設定を考えてみた。
後は、ＳＤＲＡＭのマニュアルと、ＲＸ６４Ｍのマニュアルを見ながら、行
い、とりあえず、書いたデータを読み出せた～
※もっと苦労すると思っていたので、意外な感じはあるが、メモリー空間は
３２メガバイトもあるので、詳細なテストを行わないと、分からない。

バス・インターフェースの初期化

    // SDRAM 初期化 128M/32bits bus
    device::MPC::PFAOE0 = 0xff;  // A8 to A15
    device::MPC::PFBCR0 = device::MPC::PFBCR0.ADRLE.b(1) |
                          device::MPC::PFBCR0.DHE.b(1) |
                          device::MPC::PFBCR0.DH32E.b(1);
    device::MPC::PFBCR1 = device::MPC::PFBCR1.MDSDE.b(1) |
                          device::MPC::PFBCR1.DQM1E.b(1) |
                          device::MPC::PFBCR1.SDCLKE.b(1);
    device::SYSTEM::SYSCR0 = device::SYSTEM::SYSCR0.KEY.b(0x5A) |
                             device::SYSTEM::SYSCR0.ROME.b(1) |
                             device::SYSTEM::SYSCR0.EXBE.b(1);
    while(device::SYSTEM::SYSCR0.EXBE() == 0) asm("nop");

SDRAM の初期化

    device::BUS::SDIR = device::BUS::SDIR.ARFI.b(0) |
                        device::BUS::SDIR.ARFC.b(1) |
                        device::BUS::SDIR.PRC.b(0);
    device::BUS::SDICR = device::BUS::SDICR.INIRQ.b(1);  // 初期化シーケンス開始
    while(device::BUS::SDSR() != 0) asm("nop");
    // 動作許可、３２ビットアクセス
    device::BUS::SDCCR = device::BUS::SDCCR.BSIZE.b(1);
    // Burst read and burst write, CAS latency: 3, Burst type: Sequential, Burst length: 1
    device::BUS::SDMOD = 0b00000000110000;
    // CAS latency: 3, Write recovery: 1, ROW prechage: 4, RAS latency: 3, RAS active: 4
    device::BUS::SDTR = device::BUS::SDTR.CL.b(3) |
                        device::BUS::SDTR.RP.b(3) |
                        device::BUS::SDTR.RCD.b(2) |
                        device::BUS::SDTR.RAS.b(3);
    // 128M/16 カラム９ビット、ロウ１２ビット
    device::BUS::SDADR = device::BUS::SDADR.MXC.b(1);
    // Refresh cycle
    device::BUS::SDRFCR = device::BUS::SDRFCR.RFC.b(2048) |
                          device::BUS::SDRFCR.REFW.b(7);
    device::BUS::SDRFEN = device::BUS::SDRFEN.RFEN.b(1);
    // SDRAM 動作開始
    device::BUS::SDCCR.EXENB = 1;

SDRAM サンプル

部品の整理をしていたところ、色々なＬＣＤが出てきた。

※安売りでバーゲンしてる時に買ったもの。

ＲＸ２４Ｔには、まだ液晶を接続していなかったので、ＲＸ２４Ｔで実験してみた。

赤い基板と横長の基板は、ＳＴ７５６５で、小さいのは、ＵＣ１７０１、白い枠は、
カラーＴＦＴ液晶。
横長は、モノ１２８×３２、他はモノ１２８×６４、カラーは１２８×１６０となって
いる。

どのＬＣＤも、ＳＰＩで通信するものだけど、ピンアサインが、どれも微妙に異な
る・・・
また、基本的には、電源は３．３Ｖだけど、バックライト用電源が異なるモジュー
ルがある。（Aitendo さん何で同じにしないかなぁ・・・）

以前に買ったＬＣＤで、ＬＣＤの不良（仕様違い）で、使わなくなっていたやつを
交換してきた、メールで問い合わせたら、返金すると言っていたが、同等品があった
ので、交換にした。

このＬＣＤは大型でバックライトもあり、なかなか良い。

同じコントローラーでもＬＣＤによりコントラストの設定が異なるのが、多少厄介。

※周囲が暗いけど、小さめの赤い基板のＬＣＤ、液晶の応答速度が若干速い気がする。

※さらに小型のＬＣＤ（バックライト付）で、コントローラーがＵＣ１７０１

他にもあるが、どれも表示は問題無くできる。

    // SPI 定義（RSPI0）
    typedef device::rspi_io<device::RSPI0> SPI;
    SPI spi_;

    typedef device::PORT<device::PORT6, device::bitpos::B1> LCD_SEL;    ///< LCD 選択信号
    typedef device::PORT<device::PORT6, device::bitpos::B2> LCD_A0;     ///< LCD レジスター選択

#ifdef LCD_ST7565
    // ST7565 drive
    chip::ST7565<SPI, LCD_SEL, LCD_A0> lcd_(spi_);
#endif
#ifdef LCD_UC1701
    // UC1701 drive
    chip::UC1701<SPI, LCD_SEL, LCD_A0> lcd_(spi_);
#endif

「LCD_SEL」はＬＣＤの選択信号
「LCD_A0」は、ＬＣＤの制御レジスター切り替え

ＬＣＤの切り替えは、インスタンスを代える事で行う。
「spi_」は、ＳＰＩを制御するクラスで、コンストラクター時、参照で受け取るよう
にしてある為、SPI の制御をシェア可能になっている。

ＬＣＤのコントラストは、ＬＣＤのスタート時に（初期化）設定する。

    lcd_.start(0x00);

※大きいタイプは０ｘ１０程度、他は、０ｘ００くらいだった。（ＬＣＤにより調整
が必要なようだ）

ＲＸ２４Ｔ、ＬＣＤサンプル

Ｒ８Ｃ、ＲＬ７８、ＲＸマイコンと、実装を重ねた結果、色々と新しい試み（
判りやすさ、正確性、共有性、性能）が導入されて、昔に実装した、Ｒ８Ｃ関
係のテンプレートライブラリの完成度が相対的に低下している状況となってい
る。

ここらで、最新の実装方法を、Ｒ８Ｃにも反映するべく、アップデートを大々
的に行った。
この改修は、Ｉ２Ｃや、ＳＰＩデバイスの制御クラスを全てのプラットホーム
で共有する為の準備でもある。
また、デバイスのフラッシュ書き込み関係プログラムも改修を行った。

Ｉ２Ｃ、ＳＰＩインターフェースの完成度が低いので、その辺りも、ＲＬ７８
やＲＸと同等な実装に切り替えた。

かなり大掛かりな手術となったが、一応完成した、これで、各プラットホーム
で、外部デバイスを共有する事が出来ると思う。

-----

以前にアマゾンで、ＬＥＤドライバー、マキシム社のＭＡＸ７２１９を買った。
ＭＡＸ７２１９ ７セグＬＥＤ×８

部品単体で買っても１０００円する（これは、高すぎるが・・）ので、とても
ＣＰが高い。
一般的に、多数のＬＥＤを接続するには、ポートや、電流容量の問題で、ドラ
イバーを入れなくてはならないので、それが簡単に接続できる。
ただし、電源は５Ｖなので、３．３Ｖのデバイスに接続するには、別途電源が
必要と思う。
そこで、電源電圧が自由に選べるＲ８Ｃ／Ｍ１２０ＡＮで、５Ｖで駆動により、
接続実験を行った。

輝度をプログラム出来るとか、電流制限抵抗が少ない、デージーチェインできる
、ダイナミックスキャンが行われているなど、かなりユニークなデバイスで、取
り扱いが簡潔で良い。（少量でも安ければ良いのだけど・・・）

MAX7219サンプル

ＭＡＸ７２１９制御クラス

最近、ＢＭＰ２８０が、安く購入出来る事を知り、早速購入、実験してみた。
アマゾンで２３０円だった。
※湿度も計測できる、ＢＭＥ２８０は、まだ高価なようだ・・（＠５４０）

ＢＭＰ２８０は、ＢＭＰ１８０の後継で、色々な部分が改善されているようだ、ただ、
温度や気圧を得る為のシーケンスは、ＢＭＰ１８０とは異なる為、新規に実装する必要
がある。
今後は、ＢＭＰ１８０はＢＭＰ２８０に置き換わるものと思われる。
※現状では、ＢＭＰ２８０の方が安く入手できる。

ＢＭＰ１８０とＢＭＰ２８０の主な違い：

Parameter:               BMP180                 BMP280
Footprint:               3.6 × 3.8 mm           2.0 × 2.5 mm
Minimum VDD:             1.80 V                 1.71 V
Minimum VDDIO:           1.62 V                 1.20 V
Current consumption:     12 μA                  2.7 μA
(@3Pa RMS noise)
RMS Noise:               3 Pa                   1.3 Pa
Pressure resolution:     1 Pa                   0.16Pa
Temperature resolution:  0.1°C                  0.01°C
Interfaces:              I²C                    I²C & SPI (3 and 4 wire, mode ‘00’ and ‘11’)
Measurement modes:       Only P or T, forced    P&T, forced or periodic
Measurement rate:        up to 120 Hz           up to 157 Hz
Filter options:          None                   Five bandwidths

早速、ＢＭＰ２８０用にテンプレートクラスを実装して、動作実験を行った。
ここで、ＢＭＰ１８０とインターフェースを合わせる為、ＢＭＰ１８０の実装も見直した。
ＢＭＰ１８０では、温度は０．１度単位で出力されるが、ＢＭＰ２８０では、０．０１度
までの分解能がある。
なるべく、小規模なマイコンなどで使う事を考えて、浮動小数点を使わないようにしたの
で、以前のインターフェースでは、１０倍した整数で、温度を取得するようにしていたが
これを１００倍とした。
圧力（ヘクトパスカル）は、元々１００倍された値だったのでそのまま使った。
ＢＭＰ２８０では、さらに小数点以下８ビットも有効のようだったが、センサの分解能か
ら考えて、必要ないと思ったので、捨てている。
圧力から、高度を求めるＡＰＩは、std::pow を使うので、Ｒ８Ｃ版では、容量の関係で、
コンパイルは出来るものの、容量オーバーで、リンクに失敗する。
ＲＬ７８でも問題無く機能するものの、バイナリーは６４キロを超える。
※ＲＸでは１３キロ程度に収まる。

-----

補正などのソースコードはネットにあるソースを参考にしたけど、どうも、初期設定の
デバイスの動作モード設定に誤りがあるようで、データシートを読んで（観て）設定データ
としたが、それが正しいのか微妙ではある、データを１秒間隔で出力させると、それらしい
データを出力している。
※立川の高度は１００ｍくらいのハズなので、かなり違うが、天気によりそれなりに変
化すると思うので、スルーしている。
※一応、圧力の補正ルーチンは確認しているが、特に間違いは無いと思える。

Bosh のデータシートには「filter」に関する説明が不十分なように思う・・・
※とりあえず、「Filter:16」の設定として、０ｂ１００としている。

BMP280 初期化コードの一部

    // Ex: Ultra high resolution
    // setting control
    // osrs_t(X2): 010, osrs_p(X16): 101, mode(Normal): 11
    uint8_t mode = 0b010'000'00 | 0b000'101'00 | 0b000'000'11;
    write8_(REG::CONTROL, mode);

    // setting config
    // t_sb(0.5ms): 000, filter(16): 100, xxx(0): 0, spi3w_en(0): 0
    uint8_t conf = 0b000'000'0'0 | 0b000'100'0'0 | 0b000'000'0'0 | 0b000'000'0'0;
    write8_(REG::CONFIG, conf);

Temperature: 19.51 C
Pressure: 1005.85 hPa
Altitude:   61.79 m
Temperature: 19.51 C
Pressure: 1005.86 hPa
Altitude:   61.71 m
Temperature: 19.51 C
Pressure: 1005.87 hPa
Altitude:   61.63 m
Temperature: 19.51 C
Pressure: 1005.87 hPa
Altitude:   61.63 m

BMP180/BMP280 サンプル

ＲＸ２４Ｔは、モーター制御がターゲットだからか、Ａ／Ｄ変換関係が、もの
凄く充実した（細かい）造りになっている。
変換時間は１マイクロ秒で、１２ビットの精度があり、５チャンネルが２ユニ
ット、１２チャネルが１ユニット、計２２チャンネルと豪華で、付随する機能
も豊富で複雑だ。

流石、インバーター制御用なので、サンプルホールド回路が複数あったり、
ゲインを制御する機構があったり、モーター制御に必要な機構を網羅している
ようではある。
変換結果を受け取るレジスターも、個別になっているので、変換したいチャネ
ルを選んで、変換を開始するだけで、マネージメントも簡単で、処理負荷も少
なくてすむ。

とりあえず、単に変換するだけの機能を実装してテストしてみた。
他の変換モードは、必要になったら、適宜追加していくようにしたい。
ただ、テンプレートの定義は、複雑だったので、それなりに苦労した。
なるべく、３つのモジュールを同じように扱う事が出来るように工夫した。

チャネルの扱いをどのように扱うか、色々悩んだが、結局、各モジュールの定
義内に、「enum class」を使って、チャネル定義を行った。

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  S12AD1 定義
    @param[in]	base	ベース・アドレス
    @param[in]	t		ペリフェラル型
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <uint32_t base, peripheral t>
struct s12ad1_t : public s12ad_t {

    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    /*!
        @brief  アナログ入力型
    */
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    enum class analog : uint8_t {
        AIN100,
        AIN101,
        AIN102,
        AIN103,
        AIN116 = 0x10,
    };
.
.
.
};
typedef s12ad1_t<0x00089200, peripheral::S12AD1> S12AD1;

ユニット０、１は、チャネル５本で、５番目は、１６番から開始する為、定数を１６
としている、この値を使ってレジスターアクセスのオフセットとしている。
※ただ、こうすると、ループを回して、設定するような事が出来なくなるのが、痛い
が、アナログチャネルは、通常全て同一に使う事は少ないので、「良し」とする。

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  S12AD2 定義
    @param[in]	base	ベース・アドレス
    @param[in]	t		ペリフェラル型
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <uint32_t base, peripheral t>
struct s12ad2_t : public s12ad_t {

    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    /*!
        @brief  アナログ入力型
    */
    //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
    enum class analog : uint8_t {
        AIN200,
        AIN201,
        AIN202,
        AIN203,
        AIN204,
        AIN205,
        AIN206,
        AIN207,
        AIN208,
        AIN209,
        AIN210,
        AIN211,
    };
.
.
.
};
typedef s12ad2_t<0x00089400, peripheral::S12AD2> S12AD2;

変換時間は１マイクロ秒と短い時間ではあるけど、８０ＭＨｚのＣＰＵの場合
では、変換開始から変換終了を待つのでは、十分な実装とは言えないので、割
り込み処理は実装してあり、変換終了時に、何かタスクを実行できるような仕
様としてあるが、どこまで実用的かは多少疑問が残る。
結局、リアルタイムカーネルのようなマルチタスクシステムにしないと真価を
発揮出来ないかもしれない。

ＲＸ２４ＴのＡ／Ｄユニットの構成は、他のＲＸマイコンと比較して、汎用的
では無いため、変換操作を行う具体的なクラス「adc_io」は個別に定義した。
ＲＸ６４Ｍや、ＲＸ６３Ｔでは、別に定義する必要がある。

A/D 変換サンプル

ＲＸ２４ＴにもＳＤカードを接続してみた。

ほとんどは、ＲＬ７８のリソースを使ったものの、FatFS を ff12b と最新の
実装を使った。
また、なるべく、固有のハードウェアー設定を追い出して、ハードの依存を
少なくする仕組みを整えた。

ＲＸ２４Ｔには、専用のＳＰＩチャネル（ＲＳＰＩ０）が１つだけあるので、
ＳＤカードに割り当てた。
ＳＤカードを扱うと、このチャネルはほぼ占有されてしまうと思うので、他
とのシェアをあまり考えなくてもも良いと思うが、一応、それも可能に出来る
ようにはしてある。

新規に作成したＵＳＢシリアルコンバーターから、電源を取っているのだけど、
ＳＤカードをマウントすると、ＵＳＢシリアルデバイスが不安定になる現象が
起こった、これは、ＳＤカードマウント時に大きな電流が流れ、電圧効果が大
きいのだろう、そこで、解消の為、ＵＳＢシリアルモジュール側に４７ｕＦの
コンデンサを追加した、（２２ｕＦくらいで十分だと思うが、手持ちが無かっ
た）これで、安定的に動作するようになった。
念のため、ＲＸ２４Ｔ側にも１０ｕＦのコンデンサを足した。

簡単なベンチマークを行った。
※サンプルのＳＤカードは、Transcend の８ＧＢ
※ＲＸ２４Ｔでは、ＳＰＩの最大クロックは２０ＭＨｚとなっている。

RX24T:
SD Speed test start...
SD Write test...
Write frame: 460
Write: 136770 Bytes/Sec
Write: 133 KBytes/Sec
SD Read test...
Read frame: 133
Read: 473041 Bytes/Sec
Read: 461 KBytes/Sec

RL78/G13:
SD Write test...
Write frame: 541
Write: 116293 Bytes/Sec
Write: 113 KBytes/Sec
SD Speed test start...
SD Read test...
Read frame: 180
Read: 349525 Bytes/Sec
Read: 341 KBytes/Sec

※書き込み速度は、あまり変化は無いが、読み込み速度はかなり改善している。
※ＲＬ７８では、ＳＰＩのクロックは１６ＭＨｚだったので、その分と、ＣＰＵ
の処理能力の違いと思える。

-----

ポートを１ビット単位で定義できるようなクラスを実装した、これはＲＬ７８
でも同じようなクラスを実装したけど、より汎用的な仕様にした。

定義の仕方は、ＲＬ７８とほぼ同じだが、ポートの指定は、テンプレートクラス名とした。

    typedef device::PORT<device::PORT6, device::bitpos::B5> sdc_select;    ///< カード選択信号
    typedef device::PORT<device::PORT6, device::bitpos::B4> sdc_power;    ///< カード電源制御
    typedef device::PORT<device::PORT6, device::bitpos::B3> sdc_detect;    ///< カード検出

ＲＸマイコンでは、ポートの出力と、入力は、異なったレジスターを利用する
為、テンプレートクラスは、この対応が非常にやりやすい。
以下は、ポートクラスの一部：

struct port_t {
    static bit_rw_t<rw8_t<PORTx::base_address_ + 0x20>, bpos> PO;  // ポート出力用
    static bit_ro_t<ro8_t<PORTx::base_address_ + 0x40>, bpos> PI;  // ポート入力用

        void operator = (bool val) { PO = val; }
        bool operator () () { return PI(); }
    };
    static port_t P;

operator をオーバーロードする事で、「Ｐ」に対して、「＝」で、値を設定、
「（）」で読み出す事が出来る。

RX24T SD カードアクセスサンプル

ＲＸ２４Ｔに続き、ＲＸ６４Ｍでも、フラッシュへの書き込みが出来るようになった。

ＲＸ６４Ｍは、ＲＸ２４Ｔとは、全く違うプロトコルで、機能も増えている為、かなり
の部分が作り直しとなった。

ＲＸ６３Ｔ、ＲＸ２４Ｔでは、接続が確立され、コマンドを受け付けるようになった時
には、フラッシュは自動で消去されている為、「--erase」動作は必要無いのだが、
ＲＸ６４Ｍでは、消去は、個別に対応する必要がある。

また、デバイスを自動で認識する訳では無い為、書き込み時、デバイス種別を選択する
必要がある。

./rx_prog -d RX64M -P COM11 --verbose --progress --erase --write --verify uart_sample.mot
# Platform: 'Cygwin'
# Configuration file path: 'rx_prog.conf'
# Device: 'RX64M'
# Serial port path: 'COM11'
# Serial port speed: 115200
# Input file path: 'uart_sample.mot'
# Motolola Sx format load map: (exec: 0x00000000)
#   0xFFE00000 to 0xFFE00FCB (4044 bytes)
#   0xFFFFFFD0 to 0xFFFFFFFF (48 bytes)
#   Total (4092 bytes)
# Serial port alias: COM11 ---> /dev/ttyS10
# Serial port path: '/dev/ttyS10'
# Connection OK.
#01/01: Device Type OSA: 16000000
#01/01: Device Type OSI: 16000000
#01/01: Device Type CPA: 120000000
#01/01: Device Type CPI: 120000000
#01/01: Endian is little.
#01/01: System clock: 120000000
#01/01: Device clock: 60000000
#01/01: Change baud rate: 115200
#01/01: ID: Disable
Erase:  ###############################################
Write:  ###############################################
Verify: ###############################################

RX Flash Programmer

以前に、gcc-6.2.0 で、RL78 の gcc をビルドした時、C++ の構築時に
失敗した（１６ビットＣＰＵだとポインターが１６ビットなのが原因の
よう）ので、試さなかったが、ＲＸマイコンは純粋な３２ビットなので、
ビルドできるよなと思い、やってみた。

普通に成功した・・・
※６系は、ビルドも速い気がする。

5.4.0 では、「-flto」でビルドすると、ソースによっては、リンク時に
gcc がクラッシュする事があった、6.2.0 だと、今のところ、クラッシュ
しない～
バイナリーも小さくなる～
これは、もしかしたら、「良い」のかもしれない・・・

６系は、主に、C++1z に向けた、コンパイラと思っていたのだが、色々と
改修が進んでいるのかもしれない。

gcc-6.2.0 でコンパイルしたＲＸマイコンのプログラムも普通に動作する
ようだ。

ＲＸ２４Ｔのフラッシュ書き込みプログラムが動くようになった。

以前に実装したＲＸ６３Ｔ版と微妙に違うので、それを修正して、対応しただけ
なのだけど、ＲＸ６３Ｔより簡略化されているので、簡単だった。
※まだ、実装されていないプロトコルがある。（プロテクションＩＤの設定など）

ＲＸ６３Ｔでは、内臓発振器の周波数が低い為、速度をキックする場合には、外部
接続クリスタルの周波数を設定して、内部のクロックデバィダをプログラムする必
要があったが、ＲＸ２４Ｔでは、内部発振器の周波数はそこそこ高いので、その必
要は無くなった。

# Platform: 'Cygwin'
# Configuration file path: 'rx_prog.conf'
# Device: 'RX24T'
# Serial port path: 'COM12'
# Serial port speed: 115200
# Input file path: 'DS3231_sample.mot'
# Motolola Sx format load map: (exec: 0x00000000)
#   0xFFFC0000 to 0xFFFC1B4B (6988 bytes)
#   0xFFFFFFD0 to 0xFFFFFFFF (48 bytes)
#   Total (7036 bytes)
# Serial port alias: COM12 ---> /dev/ttyS11
# Serial port path: '/dev/ttyS11'
# Connection OK.
#01/01: Device: RX200 Series (LittleEndian)
#01/01: Device ID: 0x33306638
#01/01: Data area: 1D
#01/01: User Area: FFFC0000, FFFFFFFF
#01/01: Data Area: 00100000, 00101FFF
#01/02: Block: FFFC0000, 00000800, 00000080
#02/02: Block: 00100000, 00000400, 00000008
#01/01: Change baud rate:
#01/01: ID Protect: Disable
Write:  ################################################
Verify: ################################################

ＲＸ２４Ｔ対応、フラッシュライター

-----
rx_prog では、rx63t_protocol.hpp、rx24t_protocol.hpp と２つの制御プログラム
を使っている、C++ では、通常このような場合には、インターフェースクラスを使
って切り替えるのが一般的ではあるが、「new」を使いたくないとか、ポインター
でアクセスするのが好きじゃ無いとか色々あり、boost::variant を使ってみた。
これを使って、各メソッドに対応する visitor クラスを実装すれば、同じような
共有化が出来る。

最初は、個々の visitor クラスの実装が面倒とも思ったが、インターフェースクラス
を書くのと大差無い事が判った。
これからは、boost::variant を積極的に使っていきたい～
ただ、エラー発生時に、非常にわかり難いエラーメッセージが出力される・・・
この辺りは慣れが必要と思う・・・