まだ、機能的に欠けている部分もあるし、あまりにヒドイ実装の部分もあり、
手直しをしたいのだがーとりあえず、書き込み、読み出し、消去など、一通り
の機能は揃っているので、この辺で、ライタープログラムは、止めて、
Ｒ８Ｃ本体のプログラムなどを充実したい感じです〜
※ヒドイ実装とは、設定ファイルのパースとか、機能が分離出来ていない
モトローラーファイルフォーマットの入出力など。

※その為、バージョンは「0.72b」としている。

Renesas R8C Series Programmer Version 0.72b
Copyright (C) 2015, Hiramatsu Kunihito (hira@rvf-rc45.net)
usage:
r8c_prog[options] [mot file] ...

Options :
-d, --device=DEVICE		Specify device name
-e, --erase			Perform a device erase to a minimum
    --erase-all, --erase-chip	Perform rom and data flash erase
    --erase-rom			Perform rom flash erase
    --erase-data		Perform data flash erase
-i, --id=xx:xx:xx:xx:xx:xx:xx	Specify protect ID
-P, --port=PORT			Specify serial port
-a, --area=ORG,END		Specify read area
-r, --read			Perform data read
-s, --speed=SPEED		Specify serial speed
-v, --verify			Perform data verify
    --device-list		Display device list
-V, --verbose			Verbose output
-w, --write			Perform data write
    --progress			display Progress output
-h, --help			Display this

MacBook Pro でシリアル接続して、Ｒ８Ｃの書き込みや、消去、を色々試したけど、
とりあえず、何の問題も無い、十分に使えると思う。
自分としては、俺俺フレームワークでＧＵＩ版も作りたいけど、それはまた、後で
考えるとして・・

ソースコード一式は、GitHubにプッシュ済み、一応 MSYS2 でコンパイルと簡単な動作は
確認済みなので、Windows でも使えると思う、MSYS2 の clang では、シリアル制御関係の
ヘッダーが無い為、コンパイル出来ない、Makefile 内で、MSYS2 環境では gcc を使うよ
うにしてある。

ifeq ($(OS),Windows_NT)

Ｒ８Ｃ関係 GitHub

さて、Ｒ８Ｃは、メモリーが６４Ｋ使える事が判ると、ＳＤカードの操作も楽に出来そうだし、
色々と夢が膨らむ〜

Ｒ８Ｃ本体に行く前に、先週、買ってきたもので、ちゃんとしたライターを作っておこうと思う。
以前の書き込みハードはあまりにショボイ・・
色々考えた末、ＵＳＢシリアル部分と、Ｒ８Ｃのライター部分を分離した構造にした。
ＵＳＢシリアルは、色々な場合に使う事が多いので、分離しておけば、便利に利用できるだろう。

まず、ＵＳＢシリアル変換、モジュールが比較的安く売られているので、それを使っても良いが、
小さいケースに収めて、綺麗に作りたかったので、部品をバラで買ってきた、デバイスは
FTDI の FT231XS、単品だと安くて２１０円だった。
SSOP20 ピンのハンダ付けが、少しだけ厳しい・・
それと、マイクロＵＳＢコネクター、調べると、ミニＵＳＢコネクターより、マイクロＵＳＢ
コネクターの方が、抜き差しの耐用が高いらしい。
また、スマホがマイクロＵＳＢコネクターを採用している事が多く、ケーブルも調達がしやすい。
RTS、CTS、DTR、DSR など制御線を出しておきたいので１０ピンのコネクターを出す。
それと、５Ｖ、３．３Ｖを切り替え出来るようにしておく。
３．３Ｖは、ＩＣにレギュレーターが内蔵されているけど、取り出せる電流が少ないので、別途
三端子レギュレーターを載せる。

ケースは、「タカチ」の「ＴＷ４－２－６」を使った。

以前から、採用している構造で、非常に具合が良いのだが、Ｌ型の１０ピンコネクターを横に出す
構造にして、反対側は、マイクロＵＳＢコネクターの先端で受けるようにする事で、基板を抑える
事が出来、シンプルに収まる。

一応ＫｉＣＡＤで回路を引いた、この関係ファイルもGitHubにプッシュしてある。

さて、これでシリアルモジュールが出来たー、次は本命のＲ８Ｃライターなんだけど、これは次回にでも～

１００円で買えるマイコンとして、売られているＲ８Ｃですが、データシート上は、

ＲＡＭ２５６バイト
フラッシュ２Ｋバイトです

ところが、実際は・・

ＲＡＭ１３６６バイト
フラッシュ３２Ｋバイト

まで使えると判り、小躍りしていました～

ＯＳ－Ｘでも、Ｒ８Ｃの開発環境を整える目的で、フラッシュ書き込みプログラムを開発していましたが、
その過程で、Ｒ８Ｃのフラッシュ領域には、まだ拡張された領域があるのでは無いかと思い、良く調べてみました。

すると・・・

０ｘ１００００～０ｘ１７ＦＦＦに、さらに３２Ｋバイトの領域があり、実際に使える事が判明しました。

つまり、フラッシュ２キロバイトとは、見せ掛けの容量で、実際には６４キロバイトの領域があります。
※市場では、容量が多く（最大１６ＫＢ）値段が高いデバイスが存在しますが、基本的に中身は全て同一
なのでしょう・・

考えるに、「ATtiny2313」など１００円マイコンと同じレンジのマイコンがラインナップに無いので、
それに相当するデバイスを揃える為に既存のデバイスを再利用したのだと思います、その時、本当の
ＲＡＭ、ＲＯＭ容量では、他のラインナップと競合してしまうので、苦肉の索として、１００円に釣り
合うと思われる小さい容量で売り出したのでしょう・・

現在のところ、最強の１００円マイコンだと思います（笑）

さて、領域がある事が判ったのですが、Ｒ８Ｃのポインターは１６ビットなので、基本的には６４ＫＢ以上の
領域にアクセスするには、工夫が必要です、Ｒ８Ｃは２０ビットのアドレス空間までアクセス出来る仕組みが
あるので、アセンブラなら、下駄を履かせてアクセスする方法がありますが、 gcc ではどうでしょうか？
調べてみると、６４ＫＢ以上のアドレスの関数をコールする為の仕組みがあり、それを使う事で、拡張領域を
使う事が割と簡単に出来るようです。

まず、リンカースクリプトに拡張領域を追加します。

MEMORY {
    RAM (w)  : ORIGIN = 0x00300, LENGTH = 0x00400
    ROM (r)  : ORIGIN = 0x08000, LENGTH = 0x07FD8
    EXT (r)  : ORIGIN = 0x10000, LENGTH = 0x08000
    VVEC (r) : ORIGIN = 0x0FED8, LENGTH = 256
    FVEC (r) : ORIGIN = 0x0FFD8, LENGTH = 40
}

次に、セクション領域を宣言しておきます。

  .exttext   :
  {
    *(.exttext .stub .exttext.* .gnu.linkonce.t.*)
    KEEP (*(.exttext.*personality*))
    /* .gnu.warning sections are handled specially by elf32.em.  */
    *(.gnu.warning)
    *(.interp .hash .dynsym .dynstr .gnu.version*)
  } > EXT =0

これで、ソースコードで拡張領域のセクション指定すれば、通常領域から押し出す事ができます。
※ADC_testで main 関数を押し出してみました。

__attribute__ ((section (".exttext")))
int main(int argc, char *argv[])

コンパイル、リンクも普通に通り、出来上がったバイナリーをデバイスに書き込んでみましたが、普通に動きます。

Motolola Sx format load map:
  0x008000 to 0x009225 (4646 bytes)
  0x00FF00 to 0x012DB6 (11959 bytes)
  Total (16605 bytes)

OS-X 用に R8C 用 gcc もビルド出来た事だし、フラュシュライターを実装する事にした。
これが出来れば、MacBook などで R8C の開発が全て完結する〜

R8C/M120AN、R8C/M110AN の場合、mode 端子を Low にしてリセットをかけると、ブートモードになり
シリアル通信で、コマンドとデータを送る事で、内部フラッシュメモリーをプログラミング出来る。

尚、ライターは簡単に自作出来るが、出来合いもあり、これがお勧めかも・・
R8C/M12A ライタ&LEDキット【MR8C-TRM】

通信プロトコルは、以下のリンクから資料を取得した。
R8C/1x、2xシリーズ 標準シリアル入出力モードプロトコル仕様書
R8C/Mxシリーズ、LAxAグループ 標準シリアル入出力モードプロトコル仕様書

最初のハードルは、OS−Xって、どうやって「シリアル通信」すんの？
だった、でも、ちょっと調べたら、どうやらPOSIX準拠のシリアル通信APIをサポートしており、要はLinuxと同じ
コードで、大丈夫のようだったー、これは、MinGWでもサポートしているようなので、簡単にマルチプラットホーム
に出来るおまけ付きだ！
※ただ、デバイスファイル名は、ＯＳ依存なのだと思う。

とりあえず、FTDIのシリアルUSBブリッジを接続したら、/dev/tty*にそれらしいデバイスが認識される。

crw-rw-rw-  1 root  wheel   18,   6  5  7 21:18 /dev/tty.usbserial-A600e0xq

これを使って、簡単な通信を行いテストすると、普通に動作する〜
「rs232c_io.hpp」に必要な機能を盛り込んだ〜

それではと、色々ガリガリプログラムを作成して、とりあえず、出来上がった〜
まだ機能追加中で、中途半端な状態ではあるけれども、一応動作しているようだ。
GitHubで公開している。

仕様的には、千秋ゼミで公開されているr8cprogを元にしている。
※このプログラムをダウンロードするには、登録が必要。

ただ、C++ でスクラッチから組んだものなので、動作は、オリジナルとは違うので注意。
俺俺フレームワークとして、「file_io、string_utils、sjis2_utf16」など同梱している。

r8c_prog -d R5F2M120 -s 57600 -e -w -v uart_test.mot

現在は、デバイス名は無視されています。
ポートは、何も指定しないと、上記のデバイスパスが使われるようにしてあります。
また、コンパイルには boost が必要です。

Windows 環境では、テストされていません。
Msys２環境でコンパイル、実行を試しました。
※select の挙動が、OS−Xと違っていて、少し悩みましたが、とりあえず、問題無く動作するようになりました。

Ｒ８Ｃの機能を一通り実装、テストしている。

今回は、コンパレータークラス。

テストプログラムでは、ICOMP3、IVREF3 を電圧比較をして、その結果、ＬＥＤの点滅速度が変わると言うもの。
※実験では、REF側に、VCCを１／２に分圧し、COMP側にボリュームを接続、確認した。

Ｒ８Ｃには２チャネルのコンパレーターがある、機能的には、単純な物だが、割り込みを使った時に、実行する
処理をどのような構成にするか、考えてみた。
以前にタイマークラスを実装した時に、タイマー割り込みから、何らかの処理を実行できるように、

void (*task_)(void);

実行ポインターを用意した、ところが、こんな事をすると、コンパイラは、「task_」で何が実行されるか不明
な為、メイン側で利用しているライブラリーのワークを全てスタックに積むようコードを生成する。
※タスク内で、メイン側と同じライブラリーを使った場合に備える為で、強引な方法だが、動作は正しい。
しかし、これでは、スタックが直ぐに限界を超え深くなるのは容易に想像出来る、その為、「実行ポインター」
でのタスク管理は不採用とした。

そこで、コンパイル時に静的な関数が実行できるような仕組みを追加した。
関数オブジェクトを使い。

class task {
    public:
    void operator() () {

    .....

    }
};

()オペレーター内に、実行したい手続きを実装して、それをテンプレートの引数とする。
関数オブジェクト内の手続きが何も無い場合、コンパイラは、その部分一切を削除する。

template <class TASK1, class TASK2>
class comp_io {

    static TASK1 task1_;
    static TASK2 task2_;

    public:
        static INTERRUPT_FUNC void itask1() {
            task1_();
            WCB1INTR.WCB1F = 0;
    }

    .....

};

これなら、コンパイラが、テンプレートクラスを展開する時に、割り込み内手続きを考慮するので、ライブラリー
で使われる変数の退避も最小限となる。

COMP_test ソースコード

-----
そして、Ｒ８ＣのＩ／Ｏ定義は、ほぼ全てを網羅した。

Ｒ８Ｃ関係のリソースもかなり色々揃って来ました。

組み込みマイコンでは、外せないＰＷＭ機能の実装です。

一般的に、組み込みマイコンのハードウェアータイマーの機能は、多機能で、複雑です。
Ｒ８Ｃ/Ｍ１２０の、タイマーＣでも、ＰＷＭは二通りのモードがあり、その他に、インプットキャプチャなど
色々な機能があります。

今回は、３チャネルの出力が可能な、ＰＷＭモードの実装を行いました。
※今後必要になったら、ＰＷＭモード２や、インプットキャプチャーなど、他の設定も組み込む予定です。

ＰＷＭの場合、デューティ可変範囲を切りのよい２のｎ乗にしたい場合と、あくまでも周波数（周期）で設定
したい場合がありますので、引数の違う２つの設定を用意してあります。

今回、必要無かったので、割り込みを使っていません。

このタイマーＣのＰＷＭ出力は、設定値とカウンターの一致を利用しているので、設定値を書き換えるタイミングに注意
する必要がありますが、現状の実装では考慮されていません。

    // ＰＷＭモード設定
    {
        PML1.P12SEL = pml1_t::P12TYPE::TRCIOB;
        PML1.P13SEL = pml1_t::P13TYPE::TRCIOC;
        PML1.P10SEL = pml1_t::P10TYPE::TRCIOD;
        bool pfl = 0;  // 0->1
        timer_c_.start_pwm(10000, pfl);
        uint16_t n = timer_c_.get_pwm_limit();
        timer_c_.set_pwm_b(n >> 2);  // 25%
        timer_c_.set_pwm_c(n - (n >> 2));  // 75%
    }

↑の例では、ＰＷＭ周波数を１０ＫＨｚとしています。
Ｂ出力には２５％、Ｃ出力には７５％のデューティで出力します。

    if(adc_.get_state()) {
        uint32_t v = adc_.get_value(1);
        v *= timer_c_.get_pwm_limit();
        timer_c_.set_pwm_d(v >> 10);
	adc_.start();
    }

又、Ｃ出力にはＬＥＤが接続してあるので、ＡＮ１入力にボリュームを繋げて、０～１００％まで
デューティを変化させられますのでＬＥＤの明るさが変化します。

-----
Ｉ／Ｏポートの定義を見直し、ポートのマッピングに「固有の型」を導入しています。
その為、設定が判りやすく、誤設定も減ると思います。

        PML1.P12SEL = pml1_t::P12TYPE::TRCIOB;
        PML1.P13SEL = pml1_t::P13TYPE::TRCIOC;
        PML1.P10SEL = pml1_t::P10TYPE::TRCIOD;

※この型には「enum class」を使っている為、C++11対応コンパイラでコンパイルする必要があります。
現在 gcc-4.7.4 なので、「-std=c++0x」オプションを使っています。

PWM_test

GitHubにソースをプッシュしました。

さて、今回はデータフラッシュメモリーを扱います。

Ｒ８Ｃには、プログラムフラッシュとは別に、データの記録用の小規模なフラッシュメモリーが別にあります。

３０００番地から始まり、容量２０４８バイトです。
※１０２４バイト毎にバンク０、バンク１と分かれています。
フラッシュメモリーは、「１」のビットを「０」にする事は出来ますが、「０」のビットを「１」にする場合は、バンク毎に
イレースコマンドを発行して、全て「１」の状態に戻します。

この辺りのマネージメントが、多少難しいのですが、電源を切っても、記録を残す事が出来るので、非常に有益なメモリーと言えます。

テストプログラムでは、バイト単位での読み出し、書き込み、イレースなどが対話形式で行えるようにしてあります。
※シリアルポートにターミナルを接続します。

Start R8C FLASH monitor
# ?
erase bank[01]
r xxxx
write xxxx yy
# r 3
FF
# write 3 56
# r 3
56

操作説明：
? ---> 簡単な説明
r xxx ---> xxx のデータをリード
write xxx yy ---> xxx へ yy を書き込み
erase bank0 ---> バンク０を消去（0x3000 to 0x33ff）
erase bank1 ---> バンク１を消去（0x3400 to 0x37ff)

※xxx アドレスは、0 から 7ff までの領域です
※値は全て１６進数で行います

本来は、プログラム領域の操作関数も含めたいところですが、それは、また次の機会（必要になったら）とします。

-----
Ｒ８Ｃへのプログラム書き込みには、ルネサスのＦＤＴを使っていましたが、コマンドラインから気軽にプログラム出来れば便利です。
又、ＦＤＴは Windows 環境にしか対応しておらず、Linuxや、OS-X での開発には不向きでしたが、先日、ＡＶＲ関係でお世話になっている
ＹＣＩＴのsenshuさん
の掲示板で、コマンドラインで使える、R8C 用プログラムコマンドが公開されました。
元々は、ゆきさん開発の r8cprog を元にしていて、M120AN 32K Flash に対応した
ものですが、使いやすいように、その他の小規模な改造も行っており、安定性も増しています。
私は、コマンドラインから使えるのが便利ですが、GUI 版も用意されており、シンプルで良く精査されたシンプルな設計により、予備知識が無く
ても直ぐに使えるようになっています。
Linux にも対応している事から、OS-X にも対応可能と思います、こちらは、時間が出来たら挑戦してみるつもりです。

ＡＤＣを動作検証するサンプルで、ＵＡＲＴとタイマーの割り込みを使うようになった。
他、色々複雑化しているのだが・・

非常に気になる事案が発生するようになった、数時間程度稼動させていると、ハングアップするのだ・・

スタックかと思い調べたが問題無い・・

全く原因が掴めないので、しばらく放置していたが、たまたま確認の為、Ｒ８Ｃのマニュアルを観ていたら
気になる事項が・・

5.7.3　割り込み制御レジスタの変更
(1) 割り込み制御レジスタは、そのレジスタに対応する割り込み要求が発生しない箇所で変更してく
ださい。割り込み要求が発生する可能性がある場合は、割り込みを禁止した後、割り込み制御レジ
スタを変更してください。
(2)　割り込みを禁止して割り込み制御レジスタを変更する場合、使用する命令に注意してください。
IRビット以外のビットの変更
命令の実行中に、そのレジスタに対応する割り込み要求が発生した場合、IR ビットが“1”(割り込み
要求あり)にならず、割り込みが無視されることがあります。このことが問題になる場合は、次の命令
を使用してレジスタを変更してください。
対象となる命令…A N D 、O R、BCLR、BSET
IRビットの変更
IR ビットを“0”(割り込み要求なし)にする場合、使用する命令によってはIR ビットが“0”にならな
いことがあります。IR ビットはM O V 命令を使用して“0”にしてください。

は！？、うーーーん、そうか・・・
これは、要するに、リードモディファイライト命令など、リードからライトへの遅延が短い場合に、
フラグのリセットに失敗するのだろう、しかし、わかり難いのは、常に失敗する訳では無く、何か
の条件が重なると失敗するようだ。
もしかしたらコレかもしれない、そこで、割り込みフラグのリセットを全般的に書き換えた。

※タイマーの割り込みフラグのクリア部分

以前は、
    TRBIR.TRBIF = 0;

だったのを・・

    volatile uint8_t r = TRBIR();
    TRBIR = TRBIR.TRBIF.b(false) | (r & TRBIR.TRBIE.b());

とした。
※同じように、UARTの制御クラスにも修正を加えた。

ここで、TRBIR レジスターを１度読み出しているのだが、「volatile」を指定しないと、最適化されて、
AND 命令とかでＩ／Ｏを直接書き換えるようなコードが出てしまう。

この検証には時間がかかる・・・
２４時間走らせたが、今度は順調なので、多分解消されたと思う。
割り込みフラグを「消す」場合には注意が必要だ・・

ただ、コンパイルされたアセンブリコードには多少無駄な部分がある、しかしこれはコントロールが難しい
ので、我慢するか、アセンブラで書き直すしかない。
折角、可読性を重視して C++ を活用しているので、まぁ我慢しておく事にする。

元のソース
    uint8_t r = TRBIR();
    TRBIR = TRBIR.TRBIF.b(false) | (r & TRBIR.TRBIE.b());

    8266:	97 80 e7 00 	and.b:s #-128,0xe7

「volatile」修飾子を使った場合
    volatile uint8_t r = TRBIR();
    TRBIR = TRBIR.TRBIF.b(false) | (r & TRBIR.TRBIE.b());

    826b:	75 c4 e7 00 	mov.w:g #231,a0
    826f:	72 60       	mov.b:g [a0],r0l
    8271:	02 ff       	mov.b:s r0l,-1[fb]
    8273:	0a ff       	mov.b:s -1[fb],r0l
    8275:	94 80       	and.b:s #-128,r0l
    8277:	72 06       	mov.b:g r0l,[a0]

Ｒ８ＣのＡ／Ｄ変換も出来ました。

ただ、別の部分で、工夫が必要な事が判りました。

工夫と言うのは、バイナリーサイズが肥大化しているのです・・
問題になってるのは「format」クラスです。
このクラスは、「printf」に代わるものとして実装した物ですが、１６キロバイトにもなります。
フラッシュメモリーは３２キロまで使えるとは言え、流石に半分も消費するのでは問題です。
ＲＸマイコンで実装した物をほとんどそのまま使っているのですがー、ＲＸマイコンではそこそこのサイズでしたが、Ｒ８Ｃでは巨大になるのです・・

動作は、設計の通りですが、小さくする工夫をする必要があります。

しばしば、小さな組み込みでは、libc の printf が巨大になるので、縮小版を作る人が多いですが、自分もその口です。
そもそも、printf は、引数がスタックベースなので、フォーマットと、引数が食い違う場合に簡単にクラッシュするか、
意図しない微妙な動きになる場合があります。
コンパイラーが整合性をチェックしますが、完全ではありません。
C＋＋では、そんな危険を冒さなくても、安全な方法が色々あります。
「format.hpp」は、オペレーターの機能を使って、boost::format のような実装を行った物です、boost::format 版は、std::cout が必要な為、バイナリーが肥大化して使えませんので、縮小版です。

  int i = 123;
  printf("%d\n", i);

が、

  uint32_t i = 123;
  format("%d\n") % i;

のように書けます。
※Ｒ８Ｃでは「int」が１６ビットなので、in32_t、uint32_t を使います。
※「％」オペレーターをオーバーロードしています。

調べると、現在の実装では、文字の出力や、定型サイズなどをテンプレートの引数として受け取るのですが、これが肥大化の要因のようです。
そこで、テンプレートをやめ、通常のクラスとして定義しなおし、エラーレポートもオフにしてみました、その結果、半分以下になりました。
これなら、許容範囲と思いますと言いたいのですが、もう少し何とかしないと駄目な感じです・・
R8C の gcc はメンテされていないのと、基本１６ビットのＣＰＵなので、コンパイラのコード生成に問題があるのかもしれません・・
※R８Cでは、フラッシュは６４キロ以内なので、６４キロを超えてジャンプする機構は必要無いのですが、コンパイル
されたマシンコードには、そのキックコードが含まれています、コンパイラのスイッチで排除出来ると思いますが、少し調べた限りでは判りませんでした・・

さて、本題はＡ／Ｄ変換です、Ｒ８Ｃに内臓されているＡ／Ｄコンバーターは１０ビットの分解能で、２チャネル、アナログ入力は６チャネルあります。
変換速度は高速で、最大で２．３ｕＳです。
アナログ用電源はピン数の制限から、デジタル電源と共通ですが、ルネサス系のＣＰＵは電源ノイズも少なく、Ａ／Ｄ変換の精度もＡＶＲ系より優れている感覚があります。
※ＡＶＲ系ではサンプルホールドが無い為、変換結果に誤差が乗り易く、正確な変換を行うのが難しいと思えます。

format クラスには、Ａ／Ｄ変換などの表示に適した、固定小数点表示「％ｙ」を実装してあります。
Ａ／Ｄ変換結果は大抵、電圧や電流などですが、表示する場合、小数点付きで１０進表記で表示した方が判りやすい
ですが、通常だと実数と少数部を分けて、別々に計算をする必要があり、多少面倒です。

固定少数点表記機能を使うと、例えば、１０２３を５Ｖとすると、実数１桁、小数２桁、小数点以下８ビットの精度としてー

  uint16_t v = adc_.get_value();
  format("%1.2:8y") % static_cast(((v + 1) * 10) >> 3);

とすれば、v が１０２３の場合に「５．００」と表示できます。

Ａ／Ｄ変換のサンプルコード

浮動小数点の計算は、リソースを食うし、ＦＰＵが無いとスピードも出ませんので、固定小数点の計算を簡単に行えると便利だと思います。
※何故１０倍して８で割っているのか、良く考えれば判ります。

現在の「format.hpp」は「float、double」の実装がまだで、中途です、IEEE754 の表示を浮動少数点を使わずに整数計算だけで実装したいのですが、苦労しています、道まだ半ばです・・・

型指定子にどんなものが使えるか、「format.hpp」を観れば直ぐに解ると思います。
※８進数は、通常あまり使わないので、オプションとしています。

R8C もようやくタイマー関係の定義が出来ました。

R8C には３つのタイマーモジュールが内臓されています。
それぞれ、ＲＣ、ＲＪ、ＲＢ です。

ＡＶＲに比べると、複雑で、機能を使うには、マニュアルの意図を理解するのに時間がかかりますが、
高機能で、ＡＶＲと両方使って思うのは、ルネサス系のタイマーの方が、細かい部分が良くできている点です。
インプットキャプチャー機能などは、ダブルバッファになっていて、正確な値を取得できますし、ＰＷＭ機能は、
多くの場面を想定していて、十分な使い方が出来ます。

この中で、比較的単純な構造なのはＲＢです。
単純と言っても、色々な仕組みがあるのですが、とりあえず、１６ビットのタイマーとして使い、周期的に割り込みをかけるのに使う事にします。

タイマークラスでは、登録した関数を割り込み内から呼び出す仕組みを設けてありますが、通常「禁止」としています。
これを「有効」にすると、ライブラリー関数の静的変数を全てスタックへ退避するコードが追加される為、注意が必要です。
※そうしないと、メイン側で、あるライブラリー関数を実行していた場合、それを、割り込み側でも呼ぶと、問題が起こります。

周期的な割り込みを使うと、プログラム全体の時間管理が単純に行えるので便利です。
これは、同期式とも言います、ゲームなどに向いた方法で、画像の表示、書き換えを同期させ、常に一定の速度で全体を動作させます。
又、シングルタスクでありながら、マルチタスク的な並列動作を行うのに便利な方式です。
※厳密な意味での「並列」ではありませんが。

組み込みでも、「同期式」は、色々な面で、都合が良い場合が多くあります。

簡易的なマルチタスク的な動作が出来ます。

一つの例として、スイッチのチャタリング除去などが上げられます。
周期的な割り込みを行い、その周期で I/O ポートの値を読み込む事で、デジタルフィルター的な効果が付加され、結果的にチャタリングを除去
します。
この周期はスイッチの機械的特性によりますが、６０Ｈｚ～１００Ｈｚくらいが適当です。
※スクリーンのリフレッシュレートが６０Ｈｚなので、その値が使われます。

当然ながら、１秒に６０回以上のOn/Offを検出出来なくなりますが、通常は問題ありません。

また、個々の処理を時分割で動作するように実装して、それを周期的に呼び出す事で、並列動作が実現出来ます。

通常は、カーネルがタイムスライスを行い各スレッドを管理しますが、小さなシステムでは、マルチスレッドは複雑になりすぎる場合があり、
「同期式」でも十分な場合があります。

ゲームを作っている人には、常識的な実装ですが、初めて触れる人には新鮮で、判り難いかもしれませんが、馴れておくと良いと思います。
今まで、複雑で、難解な実装が、シンプルに出来る場合があり、モジュール的に他の処理と分離する事ができます。

ここで、今までに実装したＲ８Ｃ関係クラスなどをまとめておきます。

M120AN/
  m120an.ld     ---> リンカースクリプト
  system.hpp    ---> システム制御
  clock.hpp     ---> クロック発生回路
  port.hpp      ---> I/O ポート
  intr.hpp      ---> 割り込み
  uart.hpp      ---> シリアルインターフェース
  timer_rb.hpp  ---> タイマＲＢ
  timer_rc.hpp  ---> タイマＲＣ
  timer_rj.hpp  ---> タイマＲＪ

Ｉ／Ｏ制御関係では、以下のファイルがあります。

common/
  start.s        ---> Ｒ８Ｃ起動アセンブラソース
  vect.[hc]      ---> 割り込み、割り込みベクター関連
  init.c         ---> 初期化関連
  io_utils.hpp   ---> レジスター定義ユーティリティーテンプレート
  uart_io.hpp    ---> シリアルインターフェース制御クラス
  trb_io.[hc]pp  ---> タイマＲＢ制御クラス

各デバイス毎にテストしたプロジェクトがあります。

R8C/
L_chika     ---> 基本の基本ＬＥＤ点滅（最小限の実装）
UART_test   ---> シリアルインターフェースのテスト（ポーリング、割り込み）
TIMER_test  ---> タイマーＲＢのテスト（ポーリング、割り込み）

これからも、随時追加していく予定です。

凄い長い間、間が空いたけど、再びＲ８Ｃです。
※ＷＲ２５０Ｘを買ったせいで、休みは、出かける事も多く、体調を崩した事もあり、進んでませんでした・・

ＵＡＲＴですが、Ｍ１２０、Ｍ１１０には１チャネルのＵＡＲＴが備わっています。
Ｒ８ＣではＳＣＩと言わないのが、何となく系統の違いを感じますが、内部の機構や構成は、ＲＸマイコンなどと殆ど同じです。
※良く調べたら、送信割り込みの機構はかなり違っていて、ＲＸマイコンやＳＨ用ＳＣＩのプログラムはそのままの構成では流用できませんでした。
※もしかしたら、これが「ＵＡＲＴ」と呼ぶ事なのかもしれません・・

クロックジェネレーターの構成により、あまり高いボーレートを使う場合は苦しいかもしれません。
※内部発振器は通常２０ＭＨｚで発振しますが、調整機構があり、１８．４３２ＭＨｚで発振させる事が出来るようで、ボーレートクロックに適しています。
※１９．９６８ＭＨｚならもっと良かったのに・・

追加したファイルは、以下です。

R8C/M120AN/uart.hpp
R8C/common/uart_io.hpp
R8C/UART_test/*

現在のところ、ポーリングによる動作しか実装していませんが、そのうち割り込み動作も追加するつもりです。
Ｒ８Ｃは、ＲＡＭのリソースに余裕が無い為、割り込みベクターをＲＯＭ側に置いておく必要があり、その為のしくみを考え中です。

Ｍ１２０以外のＲ８Ｃでも流用が出来るように、ＵＡＲＴ０だけに特化していません。
※今のところ、Ｍ１２０以外のＲ８Ｃを使う予定はありませんが・・

以前にＲＸマイコン用に作った、sci_io.hpp をR8C/UART 用に焼きなおしただけで、基本的な構成は似ています。

・テンプレート関数内 static 宣言
テンプレートクラスで static クラスを宣言すると、実態が必要なので、uart_io.hpp の最後の方で実体を宣言してあります。
※以前、この宣言方法が判らなくて、少し苦労しました・・

template<class UART, uint16_t recv_size, uint16_t send_size>
	utils::fifo<recv_size> uart_io<UART, recv_size, send_size>::recv_;
template<class UART, uint16_t recv_size, uint16_t send_size>
	utils::fifo<send_size> uart_io<UART, recv_size, send_size>::send_;

何故、static にする必要があるかと言えば、割り込みが関係しています。
割り込みが発生した場合、テンプレートクラスのリソースにアクセスする為には、テンプレートクラスの実体のアドレスが必要ですが、
通常の方法では、簡単に得られません（クロックを消費します）、そこで、static 変数にしておく事で、コンパイル時にアドレスが決定される為、
割り込み関数から、容易にアクセスできるのです。
static にしてありますが、テンプレート引数に依存しているので、UART チャネルが違う場合は、別のリソースとして割り当てられます。

・最適化の功名
main 関数内で、UART にボーレートを設定している関数がありますが、内部でボーレートジェネレーターに設定する値などを計算しています、
しかしこれは定数を指定している為、コンパイル時に最適化によって計算部分が最適化され、ダイレクトに定数がレジスターに設定されるような
アセンブリコードが出力されます。
※機能としてボーレートを変更できるような仕様だと、省く事が出来ない為、計算するコードが含まれる事になります。

・基本的な使い方
ＵＡＲＴ０を使うには、モジュールを有効にして、Ｉ／Ｏのマッピングを設定する必要があります。

    MSTCR.MSTUART = 0;  // モジュールスタンバイ制御
    PMH1E.P14SEL2 = 0;
    PMH1.P14SEL = 1;
    PMH1E.P15SEL2 = 0;
    PMH1.P15SEL = 1;

※Ｍ１２０の場合、Ｉ／Ｏポートの方向レジスターの設定は不要のようです。

Ｍ１２０のシリアルフラッシュライターでは、ＴＸＤのポートは、本来のＴＸＤ０とは違うポートを使っている為、フラッシュライターのハード
を使って、シリアル入力のテストを行うには、Ｐ１：Ｂ６とＰ１：Ｂ５をブリッジする必要があります、今回は適当な抵抗でブリッジしています。

※使い方は、main.cpp を参考にして下さい。

いつものように GitHub にプッシュしてあります。

追記：
割り込みにも対応するべく、色々やっていました。
色々なバグなども見つけて、安定度なども向上しつつあります。

リンカースクリプトに記述してあるスタックのアドレスを間違ってました・・

それを修正して、割り込みベクターの設定ハード用のテンプレートを実装したら、受信割り込みは簡単に動いたのだけど、
送信割り込みがーー、Ｒ８Ｃでは、送信割り込みハードの実装が微妙で、スマートな方法が使えないのです。

普通、送信割り込みはバッファが「空」になったら発生するので、ソフトとの連携も楽なのですが、Ｒ８Ｃではそうなっておらず、
少し苦労しましたが、何とか方法を考えて実装しました、以外と簡単な対処ですが、ロジックに誤りがあれば、普段は良くても、何か違う状況
の場合などに微妙に正しく動作しない可能性があります。
※バッファに送信データが残るとか、送られないデータが出るとか・・
割り込みを含んだロジックは、隠れて見えない部分が多いものなので、しばらく注意して観ておく必要があります。

送信割り込みで運用したロジックは以下のような物です。
・リングバッファが空で、ＵＡＲＴのレジスタも空なら、送る物が何も無い状態なので、直接送信レジスターにデータを書く。
・リングバッファが空では無いか、ＵＡＲＴのレジスタが埋まっていれば、送信中なので、リングバッファにデータをいれる。
・送信割り込みでは、リングバッファが空なら、送る物が無いので、何もしないで終了とする。
・送信割り込みでは、リングバッファに何かデータがあれば、それをＵＡＲＴのレジスターに書いて終了する。