以前に、gcc では、内部データフラッシュメモリーへのアクセスがサポートされない
事で、開発をストールさせていたが、GR-Cotton でＲＬ７８／Ｇ１３が使われており
ＷＥＢコンパイラは gcc となっている、また、データＥＥＰＲＯＭのアクセスライブ
ラリーもあるようなので、これらを利用する事にした。
※以前に、ルネサスのＩＤＥでは、ＲＬ７８はＣ＋＋をサポートしないので、gcc 用
ライブラリの提供をお願いした際「できません」と断られた事があった。

GR-Cotton では WEB コンパイラで gcc を使っていて、gcc 用ライブラリーを同梱し
ている。
それなら、それを教えてくれてもいいと思うのだが・・・

今回、仕事でＲＬ７８のオファーを受けた事で、データ・フラッシュは必須なので、
検討を始めた。
以前に、データフラッシュライブラリのオブジェクト（ＣＳ＋ＩＤＥ）をダンプした
ら、リバースエンジニアできそうな感じだったのだが、gcc 判があれば話が早い。

早速、GR-Cotton のプロジェクトを作成して、ソースコード一式を入手した。

その中にデータＥＥＰＲＯＭ操作関係のＡＰＩがあるので、関係する部分を取得して、
自分のシステムに組み込んでみた。
※肝心な部分は、やはり、ライブラリーになっており隠蔽されている。（pfdl.a）

「pfdl.a」は、２つのオブジェクトをアーカイブしたものであるようだ。

% rl78-elf-nm pfdl.a

pfdl.o:
0000009d R _PFDL_Close
00000025 R _PFDL_Execute
00000091 R _PFDL_Handler
00000000 R _PFDL_Open
0000009d R PFDL_Close
00000025 R PFDL_Execute
0000006b r PFDL_Execute_erase
0000008a r PFDL_Execute_exit
00000061 r PFDL_Execute_firmware
0000007c r PFDL_Execute_read
0000007f r PFDL_Execute_read_next
00000091 R PFDL_Handler
00000000 R PFDL_Open

pfdl_version.o:
00000000 R _PFDL_GetVersionString
00000009 R _PFDL_VERSION_STRING
00000000 R PFDL_GetVersionString

ライブラリから、オブジェクトを分解して、肝心なオブジェクトを逆アセンブルして
みた。

rl78-elf-ar x pfdl.a
rl78-elf-objdump -D pfdl.o > pfdl.lst

00000000 :
   0:   c1                              push    ax
   1:   c3                              push    bc
   2:   a8 08                           movw    ax, [sp+8]
   4:   71 00 90 00                     set1    !f0090 .0
   8:   c7                              push    hl
   9:   16                              movw    hl, ax
   a:   bf 04 08                        movw    !f0804 , ax
   d:   8c 01                           mov a, [hl+1]
   f:   9f 01 08                        mov !f0801 , a
  12:   e5 03 08                        oneb    !f0803 
  15:   f2                              clrb    c
  16:   fc f8 ff 0e                     call    !!efff8 
  1a:   c6                              pop hl
  1b:   cf 80 08 04                     mov !f0880 , #4
  1f:   62                              mov a, c
  20:   9d f0                           mov 0xffef0, a
  22:   c2                              pop bc
  23:   c0                              pop ax
  24:   d7                              ret

上記は、PFDL_Open API の逆アセンブルソースだが、妙なアドレスをアクセスしている。
「Ｆ０８０４、Ｆ０８０１、Ｆ０８０３、Ｆ０８８０」これは、データフラッシュ関係の
制御レジスターと思われる。（ハードウェアーマニュアルには記載は無い）
また、「ＥＦＦＦ８」をコールしている、この部分に、データＥＥＰＲＯＭのファーム
があるものと思われる。（このファームの存在も、一切記述が無い）

※改めて思うが、何故、隠蔽して、情報をオープンにしないのか、全く理解に苦しむ。
※本当に知りたいのなら、リバースエンジニアリングできるし、制限を設ける理由も思
いつかない。（ユーザーは不便になり、メーカーはサポートする仕事が増えるだけ）

早速テスト・・・
ＰＦＤＬ＿Ｏｐｅｎ関数を呼び出すと、戻ってこない・・・
ＰＦＤＬライブラリのドキュメントを調べると、暗黙的に利用するワークＲＡＭがあるよ
うだ。（セルフＲＡＭ領域）
※不思議な事に、デバイスにより、必要な場合と不必要な場合がある。
しかし、自分が使っているＲＬ７８／Ｇ１３（Ｒ５Ｆ１００ＬＧ）では、セルフＲＡＭは
必要無い。
また、これとは別に、デバイス共通で、ＲＡＭの最終アドレス付近は、（０ｘＦＦＥ２０
～後ろ）はライブラリの利用領域として予約されている。
※スタックやデータバッファと記述がある。

自分は、スタックを共有する為、ＲＡＭの最終アドレスを設定している。

色々、悩んだ末、解決した。
どうやら、ライブラリ内では、スタックを再設定して、内部処理を行い、ライブラリを出
る時に元に戻しているようだ。
この動作の為、共有していると正常に動作しないようだ、アプリ側のスタックを完全に分
離して、オーバーラップしないようにしたら、あっけなく動作した・・・
※これだからブラックボックスは嫌いだ・・・（まぁ自分の思い込みが原因ではあるけど）

以前にＲＸマイコンで作成した、対話形式で、データフラッシュの操作を行うプログラム
を組み込んで、実際に操作してみた。

問題なく書き込める！

とりあえず、操作できるようだ、これで、ＲＬ７８も他のマイコンと遜色無く使える事が
判ったので、色々利用してみたい。
ＲＬ７８はコストが安いので、Ｒ８Ｃ／Ｍ１２０とＲＸの中間を埋める「駒」として重宝
しそうだー

RL78データフラッシュサンプル

中華製、ＶＬ５３Ｌ０Ｘのモジュールを入手したので、距離を測定する実験を行った。

元にしたソースは、Arduino の物で、ほぼ、そのまま利用させてもらった。
ただ、Arduino のソースは、ヘッダーとソースに分かれており、Ｃ＋＋の有意義な部分
を使っていないものが多く、その辺りは、Ｃ＋＋流に書き換えた。

たとえば・・
・「define」マクロ関数を使っている。
※Ｃ＋＋では、define マクロを使って関数を定義するメリットは全く無いので、一般的
に使う必要性が無い。
※実行速度も改善されないし、「型」の検査や、定義を台無しにしてしまう。
・生の「enum」を使っている、Ｃ＋＋では、「enum class」を使う事で、冗長な書き方
や不整合を回避できる。
※部分的には、逆に「冗長」になる場合があるが、「型｣安全になるので許容する。
・（定義）ヘッダーと、（実装）ソースを分ける必要性が無い。
※Arduino では、ソースとヘッダーに分かれている。
※ヘッダーに全て書けば、管理や、修正などが簡単で、間違いが少ない。
・ＶＬ５３Ｌ０ＸはＩ２Ｃインターフェースで通信を行うが、元のソースは、Ｉ２Ｃの
標準的なＡＰＩ（Ｃの関数）を呼び出して使っている。
※Ｉ２Ｃのインターフェースクラスは、テンプレートで渡す仕組みにしている。
・「参照」渡しが使われていない。
※わざわざ、ポインターにする必要が無い。

Ｉ２Ｃは電源を入れると、４ピンなので、写真のようなコネクターを使っている。
片側は４ピン、片側は２ピンｘ２となっており、電源、信号接続の違いを吸収できる。

メイン部分では、Ｉ２Ｃを初期化して、ＬＸ５３Ｌ０Ｘを初期化する。
※Ｒ８Ｃ／Ｍ１２０ＡＮでは、ソフトウェアー処理でＩ２Ｃを実現している。
距離の測定は、「単発」で行い、０．５秒おきに、コンソールに出力する。

・Ｉ２Ｃ、ＶＬ５３Ｌ０Ｘの定義

    // I2C ポートの定義クラス
    // P4_B5 (12): SDA
    typedef device::PORT<device::PORT4, device::bitpos::B5> sda_port;
    // P1_B7 (13): SCL
    typedef device::PORT<device::PORT1, device::bitpos::B7> scl_port;

    typedef device::iica_io<sda_port, scl_port> iica;
    iica	i2c_;
    typedef chip::VL53L0X<iica> VLX;
    VLX		vlx_(i2c_);

・初期化

// I2C クラスの初期化
{
    i2c_.start(iica::speed::fast);
}

// VL53L0X を開始
if(!vlx_.start()) {
    utils::format("VL53L0X start fail\n");
} else {
    // 20ms
    vlx_.set_measurement_timing_budget(200000);
}

・メインループ

    ++itv;
    if(itv >= 50) {
        auto len = vlx_.read_range_single_millimeters();
        utils::format("Length: %d\n") % len;
        itv = 0;
    }

出力される距離には、５０ｍｍオフセットが加算されているようだが、正確だ！

VL53L0X.hpp

ＶＬ５３Ｌ０Ｘ　Ｒ８Ｃ／Ｍ１２０ＡＮ　サンプル

最近は、組み込み関係が多かったが、久しぶりにＰＣアプリ関係のフレームワ
ークを更新した。

実際は、組み込み関係も含んでいる。

最初は、簡単なアルゴリズムで、ピアノぽぃ音が出ないかを研究する為に始め
た、アプリケーションがトリガーだった。
組み込みマイコンで、簡単なシンセサイザーぽぃ事をして、ピアノ風演奏を行
うのが目的だ。
そこで、ＯｐｅｎＡＬ関係のマネージメントに手をいれ、リアルタイムに波形
を合成して鳴らす事から始めた。

とりあえず、簡単な音が出せるようになったのだが、和音とかを鳴らしてみた
くなり、ＭＩＤＩ入力を行うクラスの実装を始めた、とりあえずＷｉｎｄｏｗｓ
のみ。
※後から調べたら、「portmidi」なるライブラリがあり、これを使えば、最初
からマルチプラットホームにできるようだ、時間が空いたら対応しようと思う。

久しく、ＧＵＩ　Ｗｉｄｇｅｔｓのプログラムをしていないので、自分で実装
したものなのに、どうやって使うか、自分で作ったサンプルを参考にするとゆ
ー、何とも、痛い状況になっている。

ＭＩＤＩデバイスのリストを widget_list に反映して、選択するようにしたい
が、widget_list はダイナミックにリストを作れない構造になっていた。
まず、それを改修する為に色々修正を行った。
Ｗｉｄｇｅｔｓ関係は、中途半端な部分が多く、度々改修工事が入る。

これには、色々な用件を満たしていないといけない事に気がつき、かなり色々
修正した、結局、それで終わって、肝心な部分の研究が出来ないでいる・・

-----
１２平均音階率：
現代の音楽では、基本となっているもので、ほとんどの音楽は、この「決まり」
に沿って作曲されており、売られている楽器の多くが、この「決まり」に沿って
作られている。
実際のコンサートでは、ピアノの調律を、計算された周波数とは微妙に変えた、
調音を行う事があるようで（和音の響きが変わる）、流派、考え方が色々ある
ように聞くが、一般的な計算方法は以外と簡単だ。

４Ａ（ラ）の音は４４０Ｈｚ、１オクターブ上がると８８０Ｈｚ（５Ａ）、下
がると２２０Ｈｚ（３Ａ）となる。
１オクターブ分が１２個に平均的に分割されている。
つまり、１２乗すると２となる定数ｋを求めて、それを基準の周波数に掛け
ていくと、音階が出来上がる。

k = pow(2.0, 1.0 / 12.0);
// k: 1.059463094

※何故「ド」が「Ｃ」なのか（「Ａ」では無く）
※何故「ラ」を基準にするのか（Ａだから？）
不思議な決まりが色々ある。

261.6 Hz　ド　　　Ｃ
277.2 Hz　ド＃　　Ｃ＃　261.6 * k
293.7 Hz　レ　　　Ｄ    277.2 * k
311.1 Hz　レ＃　　Ｄ＃  293.7 * k
329.6 Hz　ミ　　　Ｅ    311.1 * k
349.2 Hz　ファ　　Ｆ    329.6 * k
370.0 Hz　ファ＃　Ｆ＃  349.2 * k
392.0 Hz　ソ　　　Ｇ    370.0 * k
415.3 Hz　ソ＃　　Ｇ＃  392.0 * k
440.0 Hz　ラ　　　Ａ    415.3 * k
466.2 Hz　ラ＃　　Ａ＃  440.0 * k
493.9 Hz　シ　　　Ｂ    466.2 * k

ドレミの音階は、非常に不思議で、周波数的には均等な分布では無い。
※「ミ」と「ファ」の間、「シ」と「ド」の間は「黒鍵」（半音）は無く、
飛び飛びになっている。

小学高や中学校では、音楽を聴くのは好きだったが授業は不得意だった。
この辺りの理屈は、会社に入り、ゲーム用の演奏プログラムを作るようになって
から勉強したが、「周波数」の話を最初にして欲しかったｗｗｗ

黒鍵が歯抜けになっている事で、ある楽譜を、少し高い音や低い音で演奏する場
合（トランスポーズ）、「黒鍵」と「白鍵」の使い方が全く異なるのに、ピアニ
ストは瞬間的にそれに対応する様を観て、「凄い」なぁーと関心した事がある・・

ちょっと横道にそれて、ソースコードをクリーンアップしている。

開発初期では、あまり深く考えないで、安全確実なシンプルなコードで運転
していたが、もうそろそろ、気になっていた、柔軟性に欠ける部分を更新す
る時期なのかもしれない。

まず、ポート関係、ＲＸマイコンでは、非常に沢山のラインナップがあり、
パッケージによっても使えるポートが変化するので柔軟な創りが要求される。

ただ、全てのＲＸマイコンに対応させる品質にするのは大変だし、自分で使
うデバイスのみ定義を行い、新しいデバイスを使う必要性が生じ場合を考慮
して、「対応できるように」を目標に実装しておく。

とりあえず、カレントのデバイスは、ＲＸ６４Ｍ、ＲＸ２４Ｔなので、それ
らを中心に考える。
※最近は使わなくなった、ＲＸ６２１も（秋月＠９５０）なので、ＣＰはそ
れなりに高いから追加しておくべきかもしれない。

デバイスで異なる典型的なレジスタとして「ＯＤＲ」（オープンドレイン制
御）がある。
ＲＸ６４Ｍ、ＲＸ２４Ｔで以下のようになっている

            P0 P1 P2 P3 P4 P5 P6 P7 P8 P9 PA PB PC PD PE PF PG PJ
RX24T ODR0  o  o  o  o  x  x  x  o  o  o  o  o  x  o  o  -  -  -
      ODR1  x  x  o  x  x  x  x  o  x  o  o  o  x  o  o  -  -  -
RX64M ODR0  o  o  o  o  o  o  o  o  o  o  o  o  o  o  o  o  o  o
      ODR1  o  o  o  o  o  o  o  o  o  o  o  o  o  o  o  o  o  o

※o: 有効、x: 無効、-: ポート無し

この事実を踏まえ、ポートのテンプレートを以下のように定義して、

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  ポート定義基底クラス（PDR, PODR, PIDR, PMR, PCR, DSCR）
    @param[in]	base	ベースアドレス
    @param[in]	option	オプション
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <uint32_t base, class option>
struct port_t : public option {

...

};

ODR の定義は、option クラスとして継承させる事にすると・・

typedef port_t<0x0008C002, odr_oo_t<0x0008C084> > PORT2;
typedef port_t<0x0008C003, odr_oo_t<0x0008C086> > PORT3;
typedef port_t<0x0008C004, odr_oo_t<0x0008C088> > PORT4;
...

※ＲＸ６４Ｍ

...
typedef port_t<0x0008C002, odr_oo_t<0x0008C084> > PORT2;
typedef port_t<0x0008C003, odr_ox_t<0x0008C086> > PORT3;
typedef port_t<0x0008C004, odr_xx_t<0x0008C088> > PORT4;
...

※ＲＸ２４Ｔ
のように最終的な定義とした。

ここで、ODR 定義の option クラスは、

odr_oo_t    --->    ODR0、ODR1 の定義がある
odr_ox_t    --->    ODR0 のみ定義がある
odr_xx_t    --->    ODR0、ODR1 両方の定義が無い

とする。
※「odr_xx_t」は、中身の何も無いテンプレートとなっている。

あと、ポートのビット割り当ては、パッケージのピン数などでも変化があるの
で、今回は見送った（そこまでする必要があるか？）、しかしながら対応する
事は可能。

RX600/port.hpp

次にクロック関係の定義：

本来、特別な理由が無い限り、マイコンを定格より低いクロックで動作させる
事は稀（消費電力など）と思うが、一応定義はスマートに出来るようにしてお
きたい。
※初期のＲＸマイコンでは、ＵＳＢを使う場合、１２ＭＨｚのｎ倍にしか設定
できないので、ＲＸ６２１などでは、１００ＭＨｚまで動作が可能でも、９６
ＭＨｚでしか動かせない制限がある。
※最近のＲＸではＰＬＬの設定範囲や、構成を見直し、なるべく最大のパフォ
ーマンスが出せるような工夫がされている。

（１）外部接続のクリスタルを選べる事
（２）ＰＬＬ動作周波数の選択
（３）内部ペリフェラルのクロック選択

ＲＸマイコンでは、内部のペリファラルをグループ分けしてあり、それに対応
するクロックを個別に供給している。
※専用の分周期を持っている。

以前から、Makefile 内で、コンパイルオプションを利用して、変数定義として、
各モジュールのクロック周波数を定義していた。

-DF_ICLK=80000000 -DF_PCLKA=80000000 -DF_PCLKB=40000000
-DF_PCLKD=40000000 -DF_FCLK=20000000

※しかし、実際の分周非の設定は、適切な値を直接設定していた。

これは、（３）に相当する部分で、シリアルのボーレートや、タイマー周期、
時間待ちループなどの基数として利用してきた。
外部クリスタルの周波数を変更した場合、それに合わせて、適切な値を設定す
る必要があるので、イマイチ柔軟性に欠けるものの、通常は、クリスタルを頻
繁に交換する事も少ないので、特に仕様を変更せずにそのままにした。
※分周比の設定は、一応計算されるが、割り切れないような設定では問題とな
ってしまう。

（２）は、内部ＰＬＬの構成がより柔軟となったもので、ＲＸ６４Ｍなどは、
最大速度は１２０ＭＨｚだが、より広範囲の基底周波数を選択できるように、
内部ＰＬＬは倍の２４０ＭＨｚまで設定可能となっている。
そこで、クロック設定の際に、内部ＰＬＬをどの速度にするかを設定できるよ
うにした。
※ＰＬＬの倍率には、制限があるので、入れた数字がそのまま内部基数になる
訳ではないのだが・・

// 10MHz X-Tal, 80MHz
typedef device::system_io<10000000> SYSTEM_IO;
SYSTEM_IO::setup_system_clock(80000000);

※ＲＸ２４Ｔでは、内部ＰＬＬの最大速度は８０ＭＨｚなので、上記のように
使用する。

RX24T/system_io.hpp

最近ＲＸ６４Ｍ関係の仕事で、忙しかったが、ようやく何とかなった感じで、
やっと、ＲＸ２４Ｔ関係を再開する事ができた。

ＲＸ２４Ｔ用の汎用基板を作ろうと、回路図を引いていて、そういえば、
ＭＴＵ関係の実装が全く進んでいない事に気がつき、テンプレートを実装し
始めた。（なんか回路図引くのが、億劫）

ＭＴＵ３は、非常に高機能なので、全てを網羅するような、汎用性の高い
テンプレートを作るのはかなり大変なので、必要な機能を少しづつ実装して
ゆき、その都度改修するしかないと思われる。

とりあえず、インプットキャプチャー機能を試してみた。

今回実装した「mtu_io.hpp」は、テンプレートパラメーターとして、
「mtu.hpp」テンプレートを内包する。

typedef device::MTU0 MTU0;
typedef device::mtu_io<MTU0> MTU0_IO;
MTU0_IO mtu0_io_;

ＭＴＵは、９チャネルあるが、全てが同じ機能ではなく、微妙に違う部分が
あり、それらを吸収する構造を考えるのはパズルのようだがそれなりに楽し
い。
※ＭＴＵ５は、３相モーター用に特化しており、除外した。（指定すると
エラーになる）

「mtu.hpp」は、ルネサスのハードウェアーマニュアルに準拠したクラスな
ので、レジスターの名称は、マニュアルに準拠させている。
だが、割り込み、入出力ポートのマッピングなど、連携して動作する機構が
必要なので、それらの制御が簡潔に書けるように、ヘルパー関数を用意した。
※これは、ＳＣＩやＩ２Ｃ、ＳＰＩなどの知見を元に考えた構造で、さらに
ＭＴＵ用に色々と拡張した。

    uint8_t intr_level = 3;		
    if(!mtu0_io_.start_capture(MTU0::channel::A, MTU0_IO::capture_type::positive, intr_level)) {
        utils::format("MTU0 input capture start fail...\n");
    }

こんな感じで書けるようにした。

※チャネルとポートのマッピングは、現在の実装では、標準的ポート固定に
なっているので、変更できる仕組みを考えないといけないが、シンプルな方
法を思いつかないので、そのうちじっくり考える事にする・・

const auto& cap = mtu0_io_.get_capture();
float a = static_cast<float>(mtu0_io_.get_base_clock()) / static_cast<float>(cap.all_count_);
utils::format("Capture: %7.2f [Hz]\n") % a;

こんな感じで、キャプチャーした周期を表示できる。

ＲＸ２４Ｔでは、ＭＴＵモジュールの最大周波数は８０ＭＨｚなので、精度
が高いと思ったのだが、かなりずれている・・、ただ、リファレンスの周波数
の精度が悪いだけかもしれないので調査が必要・・・
※Ｒ８Ｃ／Ｍ１２０ＡＮで出力した信号（Ｒ８Ｃのクロックは内臓ＲＣオシレーター）
※正確なオシレーターを持っていない・・

次は、単純な波形出力を実装してみようと思う。
出力も、ほぼ、キャプチャーと同等なので、実装してみた。

typedef device::MTU1 MTU1;
typedef device::mtu_io<MTU1> MTU1_IO;
MTU1_IO mtu1_io_;

※実験では、MTU1 を使った。

// MTU1 設定
{
    uint32_t frq = 1000;
    if(!mtu1_io_.start_output(MTU1::channel::A, MTU1_IO::output_type::toggle, frq)) {
        utils::format("MTU1 output start fail...\n");
    }
}

MTU1 の出力「PA5/MTIOC1A (36)」を「PB3/MTIOC0A (32)」に繋いで１０００Ｈｚ
出力。
そしてキャプチャーしてみた。

概ね正確なようだ、昨日の「ズレ」は、Ｒ８Ｃ／Ｍ１２０ＡＮの周期が不正確
なのが原因だったようだ・・
それでも、真っ当な信号発生器は買うか、作る必要があるようだ・・・

ソースコードは GitHub にプッシュした
インプット・キャプチャー、サンプル
※ＲＸ６４ＭのＭＴＵもほぼ同等な機能なので、そのまま使えそうだが、割り
込み関係のハンドリングがかなり異なるので、それを吸収する仕組みを考えな
いとならない。

以前に、ＲＬ７８で実験したものをＲ８Ｃで焼きなおしたものです。

通常、マイコンの入力ポートは、非常にインピーダンスが高い入力元である事
を利用しています。

ガラスエポキシのユニバーサル基板上に、１０ｍｍ角の銅版を載せ、表面をポ
リイミドテープなどで絶縁します。
この銅版を入力ポートに接続しておきます。
この銅版は、１Ｍオームの抵抗でプルアップしておきます。

・この銅版は、等価的には微小なコンデンサと考える事ができます。
・まずポートを出力として、ＧＮＤに落とし、コンデンサの電荷をリセットします。
・次に、ポートを入力にすると、１Ｍオームの抵抗を通じて、コンデンサがチ
ャージされ、微小な時間差で「Ｈ」になります。
・この実験では、この時間は、数マイクロ秒～数十マイクロ秒だと考えられます。
※銅版の大きさ、ベースとなるユニバーサル基板の誘電率などの条件で変化する。
※ある程度再現性はあると思うが、環境によって調整が必要。
・上記で計測した時間の違いで、「タッチ」されているか、「開放」なのかを
判断する。
※サンプルでは、通常は常に出力、Ｌにしておき、コンデンサをショート状態
にしてあり、計測の時だけ、入力にしている。

プログラムを単純にする為、ＣＰＵループ数で計測している。

uint16_t count_input_()
{
    uint16_t n = 0;
    INPUT::DIR = 0;  // 検出する場合だけ、「入力」にする。
    do {
        ++n;
    } while(INPUT::P() == 0) ;
    INPUT::DIR = 1;  // 出力
    INPUT::P = 0;    // 仮想コンデンサをショートしてリセット
    return n;
}

実験では、「開放時１４」、「タッチ時１８以上」となった。

Github

※計測値を単純に表示する場合、「DISP_REF」を有効にする。

先日、Ｒ８Ｃ関係のブログにコメントが入り、「誰かの役に立ってるんだなぁ」
と実感、ＲＸで得た知見を元に、Ｒ８Ｃにも少しばかり反映を行った。

ＡＶＲの「ＡＴＴＩＮＹ２３１３－２０ＰＵ」は、以前は、ちょっとした物を創
る場合の救世主だったが、最近は、単価が上がり、気軽に使えなくなった。
※それでも、ＵＳＢの直接接続など、需要は少なく無い。
それに代わって、現れた救世主が、「ルネサスのＲ８Ｃ／Ｍ１２０ＡＮ」で、値
段も１００円で、隠し機能のおかげで重宝している。

Ｒ８Ｃ関係のＣ＋＋テンプレートも、それなりに充実してきて、何か実験やテス
トを行うのに困らなくなってきている。

-----
ＲＸのテンプレートクラスライブラリーを実装する課程で、gcc 独自の「拡張」
機能を学んだ。

__attribute__((weak));

これは、シンボル名に対する拡張で、二重定義の場合に「後から宣言されたシン
ボル」を有効にするもので、割り込みベクターの定義に有用だと判った。

つまり、

void UART0_TX_intr(void) __attribute__((weak));
void UART0_TX_intr(void) { }

上記のように「仮」の関数を定義しておき、割り込みベクターを宣言しておく事
ができる。

const void* variable_vectors_[] __attribute__ ((section (".vvec"))) = {
...
    UART0_TX_intr,   NULL,    // (17) UART0 送信
...

アプリケーション側で、割り込みが必要なクラスを使いたい場合、同じ名前で、
再定義すると、そちらが優先される。

#include "common/uart_io.hpp"
#include "common/fifo.hpp"

namespace {
    typedef utils::fifo<uint8_t, 16> buffer;
    typedef device::uart_io<device::UART0, buffer, buffer> uart;
    uart uart_;
}

extern "C" {

    void UART0_TX_intr(void) {
        uart_.isend();
    }

...

};

この改修で、今まで、アプリケーション側に定義していた、割り込みベクター
テーブルを追い出す事ができ、冗長なコードが改善できる。

追記：
しかし・・・、問題が全く無い訳では無い。
アプリ側のコードで、割り込みエントリーのシンボル名を「タイポ」した場合、
「vect.c」で定義されたシンボル名が優先されるので、割り込みエントリーが
空のままとなる、そして、コンパイル、リンクはエラー無く終了するので、こ
の手のミスが明るみになる可能性はかなり低い・・・
これは、課題とする。

最近は、ＲＸマイコンが多くて、Ｒ８Ｃはご無沙汰だった。

Ｒ８Ｃは、ちょっとしたデバイスの試験なら、気軽にできる。

以前に、オーブントースターを温度制御したくて、買っておいた、
ｋ熱電対センサーと、モジュールを使って、温度を表示してみた。
MAX6675/Kタイプ 熱電対

ＭＡＸ６６７５は、アンプとＡ／Ｄコンバーターが一体になった
ＩＣで、出力はＳＰＩ、電源も３Ｖ～５Ｖまで使え、０．２５℃
の分解能、０℃～１０２４℃まで計測でき、便利なＩＣだ。

プログラムは、ＩＣからデータを読み出して、表示するだけの物
だが、チップ・テンプレート・クラスに新たに、「MAX6675.hpp」
を追加した。

MAX6675 は、初期化の必要も無く、単にデータを読み出すだけの
ものだ。

サンプルでは、以下のように定義した。
※MAX6675 の SPI は、出力（MOSI）は使わないので「NULL_PORT」と
している。

// P1_0(20):
typedef device::PORT<device::PORT1, device::bitpos::B0> SPI_SCK;
// P1_1(19):
typedef device::PORT<device::PORT1, device::bitpos::B1> MAX_CS;
// P1_2(18):
typedef device::PORT<device::PORT1, device::bitpos::B2> SPI_SDI;

typedef device::spi_io<SPI_SCK, device::NULL_PORT, SPI_SDI> SPI;
SPI     spi_;

typedef chip::MAX6675<SPI, MAX_CS> MAX6675;
MAX6675	max6675_(spi_);

初期化は、以下のようにすれば良い。

    // SPI 開始
    spi_.start();

    // MAX6675 開始
    max6675_.start();

温度表示：

    auto v = max6675_.get_temp();
    utils::format("%6.3f\n") % v;

※当然ながら、ＲＸマイコンでも同じように使える。

GitHub にサンプルプロジェクトを追加した。
MAX6675サンプル

ネットスタック作りは、未だ実装中、もうしばらくかかる・・・
意外と奥が深い、色々考えると、タイミングや応答の順番、イレギュラーな場合
など、色々考慮する必要があり、実験しながらなので、中々決まらない。
それでも、少しづつは進んでいる。

その過程で、イーサーネットの割り込みタスク（ＥＤＭＡＣ）内から、文字出力
を行う事が多くなってきたが、文字出力は、排他制御されていないので、メイン
ループの出力と衝突すると、厄介な事になる（文字出力がハングアップする）そ
こで、どうにかできないか考えてみた。

void sci_putch(char ch)
{
    static volatile bool lock = false;
    static utils::fifo<uint8_t, 1024> tmp;
    if(lock) {
        if((tmp.size() - tmp.length()) >= 2) {
            tmp.put(ch);
        }
        return;
    }
    lock = true;
    while(tmp.length() > 0) {
        sci_.putch(tmp.get());
    }
    sci_.putch(ch);
    lock = false;
}

とりあえず、ロック機構を使ってリソースを包んで、ロック状態の場合は、一旦
バッファ（ＦＩＦＯテンプレートクラス）に貯める。
ロックが外れたら、バッファに残っていた文字を取り出し、表示する。
※この取り出すタイミングは、多少問題で、文字出力が無いと、バッファに残っ
た文字が永遠に出力されない。
バッファに残った文字は、メイン部分で、タイマーの同期ループなどで出力する
ようにすればＯＫと思う。