Ｉ２Ｃが、何とか動作するようになったので、次はＳＰＩ通信。
ＲＬ７８／Ｇ１３は、ＳＡＵ（シリアル・アレイ・ユニット）で、ＳＰＩ準拠の通信も
扱える（ＣＳＩと呼ぶらしい）、これなら、ＳＤカードアクセスを行なっても、アクセ
ス速度が足りないとかは無さそうだし、ＤＭＡ転送も使えるはず。
※以前にＲ８ＣでＳＰＩ通信を行なった時は、ソフトウェアーのみで実装した、その時
は、ＳＤカードのアクセスでは、１１．０５ＫＨｚの波形ファイルの再生が限界だった。
一応Ｒ８ＣにもシリアルユニットをＳＰＩ通信で使うモードが用意されてはいるものの、
そうすると、シリアル通信が出来なくなってしまう。

ＲＬ７８／Ｇ１３では、シリアル・アレイは６チャネルもあり、潤沢に使える。

ただ、ＣＳＩを実装していて気がついたが、最高速度は１６ＭＨｚである上に、それは、
ＣＳＩ０だけで、他は８ＭＨｚが上限のようだ・・
これは、かなり痛い・・
現在ＵＡＲＴには、チャネル０、１を宛てているので、これを、別に宛てて、最高速度
が出せるチャネルは、ＣＳＩ用にする必要があるようだ・・

それでは、早速、ＣＳＩ用のマネージャーを作成開始。
ＵＡＲＴと違うのは、ＵＡＲＴでは、基本、送信と受信は全二重（別チャネル）で動く
ので、ＳＡＵは２チャンネル必要だけど、ＣＳＩでは、１チャネルで、出力、入力を兼
ねる点。

簡単なテストプログラムを作成して、出力をオシロスコープで確認してみたもの、パル
スが出力されない・・・

随分時間をかけて、調べた結果、ＳＡＵのデータレジスターの実アドレスだけが、イレ
ギュラーな飛び方をしている事を発見、それを修正したら、ＳＯ１０から、パルスが出
るようになった。

FFF10H, FFF11H（SDR00）, FFF12H, FFF13H（SDR01）
FFF44H, FFF45H（SDR02）, FFF46H, FFF47H（SDR03）
FFF48H, FFF49H（SDR10）, FFF4AH, FFF4BH（SDR11）
FFF14H, FFF15H（SDR12）, FFF16H, FFF17H（SDR13）

※「ＳＯ１０」は、「ＳＤＲ０２」を使う。

まず、ＳＤカードの前に、もっとも簡単なＬＣＤを繋いでみた。
大型STN液晶モジュール（128x64/SPI） [LCD12864B11-2P]
ＲＡＭが潤沢にあるので、１２８Ｘ６４のグラフィックスも余裕で扱える～
ビットマップのＬＣＤを高速に、そして柔軟に扱うには、どうしてもフレームバッファ
が不可欠で、表示サイズと同等のメモリーが必要となる。
この場合、１Ｋバイトの領域が必要。
通常、アプリケーションは、フレームバッファを全クリアして、オブジェクトをメモリ
ー上に描画する、そして、最後の描画が終わったら、全ての内容を、ＬＣＤに送る。
こうする事で、柔軟な描画が出来る。
これが、俗に言う「フレームバッファ方式」と呼ぶもので、他の考え方として、書き換
えが起こったら、その領域だけを選択的に書き換える方法があるが、液晶モジュールと
のコマンドのやりとりが複雑になり、書き換える領域が大きいほど、描画時間が多くか
かってしまう、また、書き換えるタイミングも個別に管理しなくてはならない。
フレームバッファ方式の場合、１秒に６０回ほどの書き換えが望ましいが、ＳＴＮの液
晶は、応答が速く無いので、秒間１５枚も書き換えれば、十分かもしれない。
この方式は、昔からゲーム機で広く使われている方式。

能書きはこのくらいで～

-----
先日、Ａｉｔｅｎｄｏで購入したＬＣＤは、コントローラーは、「ＳＴ７５６５Ｒ」と
あるので、ネットを探して、「ＳＴ７５６５」のドライバーを入手した。
以前にＲ８Ｃでも「ＳＴ７５６７」の液晶を扱ったので、その時に書いたドライバーは
あるが、別のソースを精査して、もう一度ドライバーを見直してみた。
※少し、動作が怪しい部分があった為もある。

ソフトを実装して、動かしてみたが、ウンともスンとも動かない・・
ＳＣＩ関係のバグなのかもと思い、クロックとデータの関係など、色々確認してみたが、
問題無い、悩んだ末、組み立てる前から、基板のコネクターが気になっていたので、良
く調べてみると・・・
何と、ケーブルを差し込む上下が逆になっている・・・
ホームページの写真ではストレートに接続しているが、これでは、機能しない、１８０
度返さないと接触しない。

とりあえず、動作はしたのだが、非常に後味が悪い・・・
※メールで交換、返品を申し出たのだが、どうなるやら・・

最近アマゾンで、Ａｒｄｕｉｎｏ向けデバイスが格安で入手できる、中華製で、品質は
それなりではあるけれども、値段が恐ろしく安い。（送料も大抵無料）
評価欄で、低評価をしてる人がいて笑ってしまうのだが、こんだけ安くて、何が不満な
のだろうか？
部品を正規ルートで買って組み立てたら１０倍以上の値段になるだろうか・・
「当り」、「はずれ」は当然として、不満なら正規品を買えば良いだけの事と思うのだ
が・・
※スイッチサイエンスや、ストロベリーリナックスで、同じような「製品」は入手でき
る、その場合のコストを考えてほしいと思う。

-----
さて、シリアル入出力は、割り込みにも対応できて、機能的にはとりあえず十分なので
何か外にデバイスを接続したくなる。
ＲＬ７８／Ｇ１３には、ＳＡＵ（シリアル・アレイ・ユニット）を簡易Ｉ２Ｃとして使
う機能があるが、他に、ＩＩＣＡ（Ｉ２Ｃアレイ）が１チャネルあり、Ｉ２Ｃの仕様を
全て満足する事が出来るので、当然ながら、こちらを使う事になる。

ハードウェアーマニュアルを読んでも、イマイチ使い方がピンとこなかったが、以前に
Ｒ８Ｃで、Ｉ２Ｃをソフトウェアーだけで実現した経験があったので、それが役立った、
出来上がってみると、Ｒ８Ｃで実装した構成とほぼ同じようになった。
新規のデバイスを使うのは、困難が伴う、Ｉ２Ｃは動作が複雑なのでなおさらだ。
ハードウェアー・マニュアルの不備などに悩まされ、ルネサスさんのサンプルコードも
参考にして、ようやく動作した。
まだ、ポーリング動作なので、遅いＩ２Ｃは、割り込みにする必要があるのだけど。
※Ｒ８ＣのソフトウェアーＩ２Ｃもフル機能がある。

構成が複雑化してくると、バイナリーが肥大化してきた、これを解消する為、このプロ
ジェクトから、最適化オプション「-O2」を「-Os」とした。
これは、「-O2」から、バイナリサイズが大きくなる可能性のある最適化オプションを取
り除いたもので、サイズはかなり縮小する。
※おおよそ１／４になった。

使ったデバイスは、ＤＳ３２３１で、ＲＴＣだ、このモジュールは中華製で、危険なほど
安い！（確か２２０円とかだった）
このＲＴＣは、ＯＳＣの発振周波数が非常に正確なのが特徴で、普通にチップだけ買って
も５００円はするが、このモジュールは、バッテリーバックアップ、それにＥＥＰＲＯＭ
まで付いている。

ＤＳ３２３１サンプル・プロジェクト

const 領域の問題が解決したと思って、コンパイラに含む問題は解決されたと
思っていたのだが、何だか、動作が怪しい・・・

少し調べると、クラスの初期化リストが正しく動いていないように感じた。

xxxx.lst を見ながら、xxxx.mot ファイルのバイナリーを色々調査すると、明
らかに呼ばれていない関数がある事が判った。

00004c96 <__GLOBAL__sub_I__Z5wait_v>:

このアドレス「0x00004c96」は、どうやら、「.ctor」に積まれているようだ。

今まで、スタティックに定義したクラスのコンストラクターは、

extern void rl78_run_preinit_array(void);
extern void rl78_run_init_array(void);
extern void rl78_run_fini_array(void);

の３つを走らせれば良いのだと思っていたが、どうやら、「ctor」に積まれた
アドレスもコールしておく必要があるようだ・・

そこで、リンカースクリプトに「ctor」、「dtor」リストのシンボルを追加して、
「start.s」に関数を呼ぶエントリーを追加、「init.c」から呼ぶようにしてみ
た。
※どの順番で呼ぶのか不明なので、ctor を最初に呼ぶようにした。
※ctor、dtor のエントリーアドレスを得る方法が判らないので、シンボル追加。
この「無理やり」な解決方法が合っているか不明ではあるけど・・・

とりあえず、初期化が正しく行われ、正常に動作しているようだ。

まだまだ、スタートアップの方法に問題を含んでいるのかもしれない・・・

ここは、時間が出来たら、もう少し厳密な調査をしたい。

ＲＬ７８も、ＵＡＲＴが動作し始めた事で、佳境に入った感が出て来た。

とりあえず、現在使ってみた感想を述べてみる～
・バイナリーは、Ｒ８Ｃより少なくなる感じではあるけど、基本内部は８ビット構成な
ので、１６ビットや３２ビットを扱うと、肥大化は免れない。
・ミラー領域のおかげで、６４Ｋ領域を超えた場合も、ある程度普通に扱う事が出来る。
・３２ＭＨｚで動作するので、速度面でもかなり有利に感じる。
・ＲＬ７８／Ｇ１３は、コアは「Ｓ－２」なので、掛け算や割り算命令は無いものの、
外部に「乗除積和算器」があり、コンパイラオプション「-mmul=g13」で、コンパイラ
はこのリソースを使う為、それなりの速度で動作する。
※但し、割り込みルーチン内で使う場合には注意を要すると思われる。
・トータルメモリーのサイズから考えると、コストパフォーマンスに優れている。
・消費電力が非常に小さい。

いつもは、ＬＥＤ点滅の後くらいに、インターバルタイマーを実装するけど、ＲＬ７８
のインターバルタイマーは、１ユニットで、１２ビットレンジ、低速で、シンプルすぎ
るので、イマイチ意欲が沸かなかったが、必要な機能ではあるので、粛々と実装した、
動いた。

ただ、残念なのは、カウンターの値を読み出す事が出来ないので、正確なタイマーを実
装したい場合などに使えない。

単に設定したインターバルを待つだけのものでしか無い。

-----

ついでなので、ソフトディレイも実装した。
ＲＬ７８／Ｇ１３では、３２ＭＨｚ動作なので、より細かい単位も可能だけど、とりあえ
ず良く使うだろう、１ｕＳ（１マイクロ秒）単位の関数にした、これは、Ｒ８Ｃと同じ仕
様。
最初、アセンブラは、覚えなくても良いとか言ってたけど、結局、なんだかんだで、覚え
る必要が出てきて、ソフトウェアーマニュアルを読む事になった・・・

void micro_second(uint16_t us)
{    
    while(us > 0) {
        --us;
    }
}

上のようなコードは、最適化（-O2）して、以下のように展開される

(2) decw    0xffef0
(1) movw    ax, 0xffef0
(1) cmpw    ax, #0
(1) skz
(3) br      !!4922 <.L629>

最適化されても、ワークメモリーが使われているが、マシンサイクルから考えると、なる
ほど、ペナルティーは意外と少ない。
ＲＬ７８のような、アーキュムレーターが基本のＣＰＵでは、レジスターだけに割り振る
コードを出すのは難しいのかもしれない・・
※（）内がマシンサイクル

この結果を考慮して、全体で３２クロックになるように「nop」命令を置く。

・次のコードで実験してみた。

    while(1) {
        utils::delay::micro_second(10);
        P4.B3 = !P4.B3();
    }

１０ｕＳ毎にポートを変化させてみた。

大体合ってる～

インターバルタイマーソースコード

暇をみて、Ｉ／Ｏ関係の定義を粛々と実装しているけど、まずはシリアル通信だろう～
※Ｉ／Ｏポートの定義は実装した。

早速、ＳＡＵ（シリアル・アレイ・ユニット）の定義を作った。
ＲＸマイコンやＲ８Ｃのハードウェアーマニュアルでは、レジスター名の命名は、規則的
で、一貫性があり、作りやすいのだけど、ＲＬ７８は、一貫性が無く、ハードウェアー
マニュアルと乖離しないように、考えながら実装しないと駄目な感じで疲れる。
※Ｒ８Ｃは、多少古いので、部分的に微妙な部分もあるけど・・

例えば、Ｉ／Ｏポート：
「Ｐ１」はＰ１グループ（Ｐ１０～Ｐ１７）を指す。
「Ｐ１０」は、「Ｐ１」ポートの「０」ビットなんだけど・・・
Ｐ１０グループ（Ｐ１００～Ｐ１０７）のポートも同時に存在する為、「当たる」・・・
従って、ビット指定の令名はプログラム上から行えない。
なので、「Ｐ１．Ｂ０」とするようにした、これは、ＲＸやＲ８Ｃもそうしているので、
問題ないけど・・、何でそうなるの？、作った人って何考えてるか・・・

Ｉ／Ｏポートでそんな感じだから、他も、かなり酷い、でもまぁ仕方無い、なるべく、
ハードウェアーマニュアルの記述を取り込むように、考えながら実装してみた。

それで、早速ＵＡＲＴ０を使った、送信、受信のクラスを書いてみた。

ＲＸともＲ８Ｃとも違う構成のレジスター郡で、ＲＬ７８はＮＥＣ系なんだと思うが、
理解と動作するまでに、それなりに時間がかかった・・・

文字列を出力する簡単なプログラムが、思ったように動作しない事が主な原因だった。
※この問題は、「ＲＬ７８のミラー領域」で詳細を解説してある。

とりあえず、ポーリングによる実装のみしてあり、これから、割り込みを使った物や
ＤＭＡを使った実装を行いたい。

追記：
割り込みを使った実装を行った、以前に書いた、Ｒ８Ｃ用のコードをほぼそのまま
使ったが、問題無く動作する。
この辺り、Ｃ＋＋は、再利用性が高い、これは、実装段階で、再利用を考えながら
ハードの依存を極力減らして書いている事が大きいのだけど・・・

ＤＭＡは、転送量があまり多く無いシリアル通信の為に使うと、もったいない気が
する、ＳＤカードの読み書き、ＬＣＤへの転送など、転送量が多いデバイス用に確
保する方が良いと思った、また、ＤＭＡでは、結局、同期を取ったり、その他の部
分のマネージメントが色々ありそうなので、とりあえず保留とする事にした。

-----
ＲＬ７８内蔵の「シリアル・アレイ・ユニット」は、このデバイスでは、２ユニット
、６チャネルの通信回路が使えて、ＵＡＲＴ回線なら３回線を同時に使える。

「G13/sau.hpp、common/uart_io.hpp」テンプレートでは、これを扱えるように工夫
してある。
RL78/G13 では、シリアル通信は、偶数チャネルで送信動作、奇数チャネルで受信動
作を行う為、送信チャネル、受信チャネルを別々に指定する。
※制限もあるので、複数チャネルを使う場合には注意が必要。

ＵＡＲＴ０を宣言する場合は以下のようにする。
※現在は使われていないが、送信バッファと受信バッファの大きさを指定する。

    device::uart_io<device::SAU00, device::SAU01, 128, 128> uart0_io_;

他のチャネルは動作テストはしていないけど、同じように扱う事が出来ると思う。

    device::uart_io<device::SAU02, device::SAU03, 128, 128> uart1_io_;
    device::uart_io<device::SAU10, device::SAU11, 128, 128> uart2_io_;

UART の簡単なテスト

-----
フラッシュへのプログラムと、ＵＡＲＴとの通信では、共に、ＲｘＤ，ＴｘＤなどを
使う、これらの切り替えを出来るように、２回路のスイッチを設けて、書き込み回路
もテスト基板に追加した。
※書き込み器は、デバイスの「/RESET」信号を制御するので、「RTS」信号を必要とす
る。

ＵＡＲＴの実装を行っている過程で、文字列を出力する簡単なプログラムが、思ったよう
に動作しないで、随分悩んだ・・・

調べると、ミラー領域に関する認識が甘かったようで、データフラッシュ領域と当たって
いた事が判った。

８／１６ビットマイコンでは、ポインターは１６ビットサイズで、基本６４キロバイトの
領域しかダイナミックにアクセス出来ない。

ＲＬ７８では、物理的なメモリー空間は１Ｍバイト（６４Ｋが１６ページ）ある。
プログラム領域は、０番地から始まり、１２８Ｋバイト品（R5F100LGAFB）の場合、
０ｘ１ＦＦＦＦまで使える。

ＲＡＭ領域は、１２８キロバイト品の場合、１２キロバイトあり、０ｘＦＣＦ００から
始まる。

データフラッシュは１２８キロバイト品の場合、８キロバイトあり、０ｘＦ１０００
から０ｘＦ２ＦＦＦまである。
※６４キロバイト品では、半分の４キロバイト

ＲＬ７８のｇｃｃでは、Ｒ／Ｗアクセスする領域は、常に０ｘＦ００００～
０ｘＦＦＦＦＦをベースとしていて、ＲＡＭ領域をベースにアクセスするようになって
いる。
ここで問題になるのが、プログラム領域に置かれた読み出し専用データのアクセスとなる。
ＲＬ７８では、「ミラー領域」を使ってこれを解決していて、ＲＡＭ領域、
データフラッシュ領域以外は、ＲＯＭ領域のアクセスと同等となる
仕組みがある。

ここで、以前に修正したリンカースクリプトが問題となった・・・

 .rodata (MAX(__romdatastart + __romdatacopysize, 0x2000)) : {

この「０ｘ２０００」のオフセットが何なのか、判ってなかった為、これを無効
（０ｘ００００）としていた・・・
※０ｘ２０００の領域が「空く」のは勿体無い・・

当然、「０ｘ００００」にすると、文字列データは、先頭から配置される為、テストして
いたプログラムでは、０ｘ２０００以下の領域に配置される、ミラー領域では、このエリ
アは、データフラッシュ領域の為、０ｘＦ１０００～０ｘＦ１ＦＦＦがアクセスされてい
た。
それには、途中で気がついて、オフセットを０ｘ２０００に戻したが、それでも、直らな
い、良く調べると、１２８ＫＢ品は、データフラッシュが倍の８Ｋバイトあり、
０ｘＦ１０００～０ｘＦ２ＦＦＦまでとなっていた。
そこで、オフセットを「０ｘ３０００」とする事で、解決した。

 .rodata (MAX(__romdatastart + __romdatacopysize, 0x3000)) : {

※リンカースクリプトは修正済みでプッシュしてある。

つまり文字列などの固定データは、０ｘ３０００以降、０ｘＣＦ００までに置く必要があ
る。
まぁ、このくらいの領域があれば、当面困る事は無いと思われる。

先頭の空いた領域には、「.lowtext」セクションが割り当ててあるので、ここには、割り込
みルーチンなどを優先的に配置するのが良さそうだと思う。
※割り込みルーチンは、ベクターが１６ビット固定なので、必ず６４Ｋ以内に配置する必要
がある。

また、６４Ｋ以降のエリアへは、「__far」を使う事で、ポインターを３２ビット扱いとして
アクセスする事も出来るが、C++ ではこのキーワードを上手く扱えないようで、悩んでる。
※とりあえず、Ｃの関数だけで操作するしか無い。

Ｃの関数宣言では、ポインターが３２ビット扱いになり、逆アセンブルリストを観た感じでは
ＥＳレジスター付き２０ビットでアクセスするコードになっている。

「コード」の呼び出しは、２０ビット対応の「call」命令が使われているので、全域に対して
アクセスでき、６４Ｋの壁を意識する必要は無いようだ。

 12c:   fc be 32 00        call    !!32be <_main>

※コードが６４Ｋを超えて伸びていっても問題は無いと思われる。

-----
ＲＬ７８は、Ｚ８０のようだと思ったら、実際Ｚ８０（７８Ｋ０）がベースのようだｗｗｗ

※昔、ゲームボーイのプログラムで、Ｚ８０のアセンブラを随分扱ったので、馴染みがある。
でも、３２ＭＨｚで動くＺ８０となると、かなり話が違う。