次はＬＣＤと宣言してたが、その前に未実装部品についてまとめておきたい。
また、ＳＤカードを使う為にカードソケットを追加で取り付けた。

このボード、未実装の部品がある。
（１）ＳＤカードソケット「SD/MMCカードソケット：101-00565-64（AMPHENOL COMMERCIAL PRODUCTS製）」
（２）ＳＤカード電源用ゲートＩＣ「ISL61861BIBZ」
（３）ＪＯＹスティック「SW3（JOYSTICK）：SKQUDBE010（ALPS製）」
（４）イーサーネットコネクタ「RJ45_J3011G21DNL」
（５）イーサーネットＰＨＹ「LAN8720A」
※主に、上記部品で、ＳＤカードソケット、ＪＯＹスティックは、部品が判らなかったので、
ルネサスに問い合わせをした。

もちろん、自分で部品を実装したら、保障は受けられなくなるのだが、機能があるのに使わな
いのは勿体無い。
一番困難なのは、表面実装部品で、ＤＮＦパッケージだが、これは、後々、手順などを整理し
たいと思う。（基板の実装屋さんなら簡単だと思う）

多少問題なのは、上記部品で、ＳＤカードソケット、ＪＯＹスティックは、製造が終了してお
り、現在部品の入手が難しい。（入手できても割高になってしまう）
※代替部品を探したが、適当な物を探せなかった、また、日本では、やはり入手が困難だと思
われる。

特に、ＳＤカードは、このような機器では必須のＩ／Ｏなので、マイクロＳＤカードを使って
代用させる方法を考えた。
ソケットは、秋月電子製、マイクロＳＤカードスロットＤＩＰ化キットを使う。
多少細かい、配線は比較的簡単ではあるが、強引な方法なのでお勧めできないのだが、他に良
い方法を思いつかない。
また、ＲＴＫ５ＲＸ６５Ｎでは、ＳＤカードの電源をマイコンによって制御しているのだが、
電源制御につかっているＩＣ（インターシル製）は、入手できるが割高なので、とりあえず
直接接続しておく事にする。

※自分は、「セメダイン　ＳｕｐｅｒＸ」で、基板を接着した。
※強力両面テープでも良いかもしれない。

※マイクロＳＤには、ライトプロテクトが無いのでオープンにしてある。
※ほぼ、ストレートな結線なので配線は簡単だが、電源系は、熱が拡散するので、容量の大
きいハンダコテが必要と思う。

ＳＤカード関係のソフトＳＰＩでの定義

    // カード電源制御は使わない場合、「device::NULL_PORT」を指定する。
//  typedef device::PORT<device::PORT6, device::bitpos::B4> SDC_POWER;
    typedef device::NULL_PORT SDC_POWER;

    // Soft SDC 用　SPI 定義（SPI）
    typedef device::PORT<device::PORT2, device::bitpos::B2> MISO;  // DAT0
    typedef device::PORT<device::PORT2, device::bitpos::B0> MOSI;  // CMD
    typedef device::PORT<device::PORT2, device::bitpos::B1> SPCK;  // CLK

    typedef device::spi_io2<MISO, MOSI, SPCK> SPI;  // Soft SPI 定義

    typedef device::PORT<device::PORT1, device::bitpos::B7> SDC_SELECT;  // DAT3 カード選択信号
    typedef device::PORT<device::PORT2, device::bitpos::B5> SDC_DETECT;  // CD   カード検出

    typedef fatfs::mmc_io<SPI, SDC_SELECT, SDC_POWER, SDC_DETECT> MMC;   // ハードウェアー定義

    MMC     sdh_(spi_, 20000000);

-----
以前に自作のＲＸ６４Ｍボードで、ＳＤＨＩのドライバーを実装しようと、色々やったが、
どうやっても動作せず、また、ルネサスのサンプルも無いようだったので、あきらめていた。
だが、よくよく調べると、ＲＸ６４Ｍマイコンには、ＳＤＨＩインターフェース内臓版と、そう
では無いバージョンがある事がわかった。
実験で使ったデバイス「Ｒ５Ｆ６４ＭＦＣＦＤＣ」は、ＳＤＨＩは「無し」なので動くハズは
無い。
※ＳＤＨＩインターフェースのバージョンを取得するレジスターは読めて、それらしい値だった
ので、てっきりＳＤＨＩがあるものと思っていた。

ＲＴＫ５Ｒ６５ＮボードのＲＸマイコン「Ｒ５Ｆ５６５ＮＥＤＤＦＢ」は、ＳＤＨＩ「あり」の
デバイスなので、ＳＤＨＩインターフェースを使ってＳＤカードのアクセスを行う事が出来る。
４ビットモードを製品として使う場合は、ＳＤアソシエーションとのライセンス締結が必要なよ
うだが、自分がリリースしているテンプレートドライバー、フレームワークは無保証なので、こ
れらには関知しない。
※ＳＤＨＩには、ライセンスが必要無い１ビットモードもある。

現在、ＳＤＨＩドライバーは開発中であり、とりあえず、動作確認の為、ＳＰＩのソフトウェア
ＳＰＩドライバーを使って、動作を確認してある。
RTK5 SD カードアクセス、サンプル

現在カレントとして使っている gcc は「４．９．４」最新の gcc は「７．３．０」まで
進んでいる。
gcc は超巨大なプロジェクトなので、不具合も結構あるようで、ある特定の場合に正しく
動作しないなど、依存関係など色々な問題がある。
※時間が経つと、マイナーバージョンアップで解決されたりする。
※gcc とは分離されているツール binutils など、相性も関連している場合もある為、新
しい gcc を運用する場合、組み合わせも配慮する必要がある。
また、クロスコンパイラをビルドする gcc のバージョンも以前の環境とは異なっている
と思われる。
※過去のソースをビルドする場合、最新のＭＳＹＳ２環境では、同じものがビルド出来な
い状況になっている場合も考えられる。
「4.9.4」で特に不具合は無いのだが、C++ の場合、新しいコンパイラでは、最適化がより
良くなっている場合もあるので、なるべくなら新しいバージョンを使いたいと思ったりも
する。
※C++17 に移行したい、最新の C++ コンパイラを使いたい。

以前に、６．２．０を別のＰＣでビルドして、ＲＸプロジェクトをコンパイルしたら、
r_net_T4（ルネサスが提供する、ネット・スタック）を使ったプロジェクトが動作しない
（原因は調べて無いので不明）という現象が発生した。
※ＲＸのプログラムは通常通り起動するが、ＰＣ側からＲＸマイコンに接続が出来ない状
態（ping など不通になる）、DHCP クライアントは動作していて、DHCP アドレスを取得
している・・・

奇妙なのは、自宅のマシンでビルドした「６．２．０」では、問題なく動作するバイナリ
ーが出来る。
この違いは「何だろうか」と考えた結果、binutils、newlib のバージョンが、自宅マシン
でビルドした時と、違う（新しいバージョンを使った）点に気がついた。

そこで、要因を見極めるべく、色々な組み合わせでビルドを行い試してみた。
※非常に時間がかかり、操作を間違うと台無しになるので慎重に作業する必要がある。

※必ず MSYS2 環境で作業を行う。

binutils-2.27
gcc-4.9.4
newlib-2.2.0

割と最近の MSYS2 環境を使い、この組み合わせで、動作するバイナリーが出来た。
※２０１８年３月くらい

とりあえず、これを安定版としておいて問題無いだろうと思う。
※ 4.9.4 なら、C++14 がとりあえず使えるし、最適化もそこそこ良いと思う。

gcc をビルドする場合、その gcc がリリースされたタイムスタンプを考慮して、それ
より少しだけ古い判の binutils、newlib を使うようにすれば問題無いようだ、つまり、
binutils や newlib だけ、最新の物を組み合わせると問題が起きる場合が多いと思われる。

次に５系の最終版である 5.5.0 をビルドしてみる。
この時、binutils、newlib のバージョンは変更しない。

binutils-2.27
gcc-5.5.0
newlib-2.2.0

これも、問題無い、正常動作するバイナリーが出来た。

次に、newlib だけ newlib-2.4.0 に上げてみる。

binutils-2.27
gcc-5.5.0
newlib-2.4.0

これも、問題なし。

じゃぁ今度は、gcc-6.4.0 で、他は同じでビルド。

binutils-2.27
gcc-6.4.0
newlib-2.4.0

これも正常！

binutils-2.28
gcc-6.4.0
newlib-2.4.0

大丈夫だ、問題無い！

binutils-2.30
gcc-6.4.0
newlib-2.4.0

これも問題無し！、とゆー事は、newlib のバージョンで何か起こるとゆー事か・・・

今回は、とりあえず割と新しい gcc を使える事が判ったので、ここまでにしたい。
また時間に余裕が出来たら、調査を続けたい。

この組み合わせはＮＧ・・・

binutils-2.30
gcc-6.4.0
newlib-3.0.0

仕事が重なって、凄く忙しく、なかなか趣味のマイコン関係が進まない・・・

「ＲＴＫ５ＲＸ６５Ｎ」のＬＣＤ関係を進めているのだが、ドライバーテンプレートを
自分で作りたいので、デバッグ環境を何とかしたい、このボードには、「ＰＭＯＤ」と
呼ばれる汎用インターフェースがついていて、コネクタも最初から付いている、このコ
ネクタには、ＳＣＩ９がアサインされているようなので、とりあえず、これでデバッグ
用のシリアル通信を繋げてみた。
最初は、ＵＳＢ経由のシリアル通信で行う事を考えたが、フラッシュの書き換えなどに
ＵＳＢポートを優先したいのと、切り替えが面倒なので、あえて、別のポートを使った。

俺俺テンプレートドライバーでは、非常に簡潔にインターフェースを定義できるように
工夫してある。
ポートのマッピング、消費電力制御、割り込みなど、雑多な制御は、全てコンパイル時
に行う事が出来るようにしてあり、ポートのマッピングを別の経路に変更したい場合で
も可能なような仕組みを用意してある。
テンプレートの良い所は、内部で、プログラムによって、切り替えをしていないので、
その切り替え等によって生じるオーバーヘッドや余分なメモリを消費せず、最適化され
た状態になる点で、基本的に「#define」を使っていない（プロセッサシリーズの切り替
えでは使っている）ので、プログラムも読みやすくシンプルになっている。

    typedef utils::fixed_fifo<char, 512>  RECV_BUFF;
    typedef utils::fixed_fifo<char, 1024> SEND_BUFF;
    typedef device::sci_io<device::SCI9, RECV_BUFF, SEND_BUFF> SCI;
    SCI     sci_;

ＳＣＩの起動は、割り込みレベルと、ボーレートだけでＯＫ！
※現在は、８ビット、１ストップビット固定になっているが、変える必要性を感じない。

    {  // SCI 設定
        static const uint8_t sci_level = 2;
        sci_.start(115200, sci_level);
    }

また、Ｃ言語の関数、「printf」が使えるように（Ｃ＋＋では使わないが・・）stdio
経由の出力が可能な仕組みを用意してある。
printf では、POSIX の「write」関数に対して、文字列を出力する、この際のディスク
リプタ「stdout」は、通常固定になっているので、「syscalls.c」で実装してある、
「write」関数で、SCI の文字出力に繋げておけばＯＫとなる。
※「Ｃ」の関数から呼ぶ為、「extern "C"」にしてある。

extern "C" {

    void sci_putch(char ch)
    {
        sci_.putch(ch);
    }

    void sci_puts(const char* str)
    {
        sci_.puts(str);
    }

    char sci_getch(void)
    {
        return sci_.getch();
    }

    uint16_t sci_length()
    {
        return sci_.recv_length();
    }
}

※Ｃ＋＋の「iostream」も使えるけど、このライブラリをインクルードすると、とてつも
なく多くのメモリを食うので、「common/format.hpp」を用意してあり、このテンプレート
クラスで、「boost::format.hpp」と同等な操作が出来る、このテンプレートは、他に依存
しないように利便性を追求してあり、IEEE754 浮動小数点フォーマットのバイナリーを
デコードできるよう独自の実装を行っている。
※安易に「sprintf」を呼ぶような事をしていない。

gcc 「__attribute__((weak));」は、外部で定義されていれば、その関数を呼ぶが、定義
が無い場合、そのソースに置かれた関数を呼ぶ仕組みで、POSIX 関係の関数を外部で定義
してオーバーライトする事が出来るようになっている、「syscalls.c」にも同様な仕組み
を用意してあり、シリアルの入出力と標準入出力を繋げる仕組みに使っている。

void sci_putch(char ch) __attribute__((weak));
void sci_putch(char ch) { }
char sci_getch(void) __attribute__((weak));
char sci_getch(void) { return 0; }

今回はここまでー、次は頑張ってＬＣＤを動かす・・・

溜まった仕事が、ひと段落したので、少しだけ、ＲＸ６５Ｎ搭載のキットを触ってみた。

このボードの良いところは、前回説明したので、とりあえず、俺俺 C++ フレームワーク
を使って、簡単な動作検証と、開発環境を試してみた。

まず、ボード上には、「E2 Lite」が内蔵されている為、プログラムを転送するのに不便
は無い、ボード上のＤＩＰ－ＳＷを切り替える事で、「E2 Lite」を有効にして、ルネサ
スのフラッシュプログラマーで書き込み等が出来る。

とりあえず、上記写真のように「ＳＷ１－１」を「ＯＮ」にして、ＵＳＢを接続すると、
「Renesas Flash Programmer」から認識でき、接続する事が出来る。
・「新しいプロジェクトの作成」を選ぶ
・「プロジェクト名、作成場所」などを設定する
・「ツール」で「E2 Lite」を選ぶ
・「接続」ボタンを押すと、「ＲＴＫ５ＲＸ６５Ｎ」に接続する事が出来る。

一応、出荷時に書き込まれているデモプログラムを読み出して、保存しておく。

次に、ＬＥＤ点滅プログラムを実装してみる。

#include "common/renesas.hpp"

namespace {
    typedef device::system_io<12000000> SYSTEM_IO;
    typedef device::PORT<device::port7, device::bitpos::b0> LED;
}

int main(int argc, char** argv);

int main(int argc, char** argv)
{
    SYSTEM_IO::setup_system_clock();

    LED::DIR = 1;
    while(1) {
        utils::delay::milli_second(250);
        LED::P = 0;
        utils::delay::milli_second(250);
        LED::P = 1;
    }
}

※上記プログラムは「hirakuni45」の RX マイコン用 C++ フレームワーク上で、gcc 環境で
コンパイル出来る。
※開発環境の構築や、その他の情報は、GitHub RX に詳細な説明があるので参考にしていただきたい。
※RTK5_first_sample

ＲＸ６５Ｎは、１２０ＭＨｚ動作可能ではあるが、ＲＸ６４Ｍなどのように、１２０ＭＨｚで
はフルスピードで動作しないようで、メモリーウェイトを入れる必要があるようだ。
ただ、ウェイトを入れた状態でも、おおよそ、１０％減の速度では動作しているようなので、
実用上は問題無いと思える。
※「system_io」クラスは、工事中ではあるが、１２ＭＨｚのクリスタル、１２０ＭＨｚの速度
で使う場合は問題無い。
※ＲＸ６５Ｎ用にコンパイルすると、自動でメモリーウェイトを入れるようになっている。
※ＬＥＤは、ポート７のビット０にある。

ＲＸ関係のコードを github からチェックアウトしたら、「RTK5_firest_sample」へ移動して、

make

とすれば、実行ファイル（.mot）が出来るので、「Renesas Flash Programmer」を使って、転送
すれば、動作する。
※転送後、リセットを自動で解除するには、「接続設定」、「ツール詳細」、「モード端子設定」
で、「切断時のモード端子」で、「リセット端子をHighレベル」を選択しておく必要がある。

今回はここまで、次回はいよいよＬＣＤの設定や描画を実験してみたい。

今年の初めから、大幅に遅延していたプロジェクトに係りきりになり、凄く忙しく、
立川から、兵庫の三田（さんだ）に毎週のように通い、最近ようやく、見通しがつき、
他の作業もようやく進みだした。

その中で、ＲＬ７８を使った機器のプログラムを実装していたのだけど、その過程で
リンカースクリプトを改造していたので、覚書程度に紹介しておく。

ＲＬ７８は、非常に沢山の種類があるのだけど、１つのグループでも、リソースが異
なるデバイスが沢山ある。
プログラム・フラッシュ・メモリーの容量が、異なるのは良くあるのだが、データ・
フラッシュの容量も色々ある。
以前は、Makefile から、容量を与えていたが、デバイス固有のリンカースクリプトに
記述した方がシンプルでスッキリするなぁーと思っていた。
ただ、リンカースクリプトは、イマイチ、記述方法が判らない部分もあり、敬遠してい
たのだが、色々実験して、ようやく方法を理解した。

多分、他に、より良い方法があるのかもしれないが、とりあえず、以下の方法で解決し
た。
まず、「メモリー」で、データフラッシュの領域を記述する。

MEMORY {
    VEC (r)   : ORIGIN = 0x00000, LENGTH = 0x00002
    IVEC (r)  : ORIGIN = 0x00004, LENGTH = 0x0007C
    OPT (r)   : ORIGIN = 0x000C0, LENGTH = 0x00004
    SEC_ID (r): ORIGIN = 0x000C4, LENGTH = 0x0000A
    ROM (r)   : ORIGIN = 0x000D8, LENGTH = 0x0FF28
    RAM (w)   : ORIGIN = 0xFDF00, LENGTH = 0x01F20
    DATAF (W) : ORIGIN = 0xF1000, LENGTH = 0x02000
    STACK (w) : ORIGIN = 0xFFE20, LENGTH = 0x00002
}

※「DATAF」が、データフラッシュの、アドレスと領域の設定。

続いて、rdata セクション内に、データフラッシュのサイズを置いて、アクセスできるよ
うに、シンボルを宣言しておく。

    PROVIDE (__dataflashsize = .);
    SHORT(LENGTH(DATAF));

これだけだ・・
新しいのは、「LENGTH()」で、「DATAF」の「LENGTH」を参照している。
領域は、「uint16_t」サイズで置いてある。
※「uint32_t」サイズで欲しい場合は、「LONG()」を使う。

「C、C++」からは、

extern const uint16_t _dataflashsize;

で参照できる。
ただ、リンクしないと参照出来ないので、コンパイル時には参照はできない変数となって
いるので、プログラム起動後に参照するような構成にしなければならない。

マイコンでＡ／Ｄコンバーターを使った、ストレージオシロぽぃ物を作る過程で、
機能検査を行う必要があり、手頃な信号発生器を探していた。

最近は良いデバイスがあるもので、ワンチップで、最大１２．５ＭＨｚまで出力
可能なＤＤＳモジュールが安く売られていたので、早速注文した。

※基準発信器付きで小さいモジュールとなっている。
※中華、船便なので、それなりの時間がかかるが格安。

早速、ＡＤ９８３３のライブラリをネットから取得して、自前のシステムに合うよ
うに、テンプレートクラスとして整形し直した。

このデバイスは、ＳＰＩ通信で内部設定を行うので、マイコンで制御する必要があ
る。
そこで、とりあえずＲ８Ｃ／Ｍ１２０ＡＮを使ってテストしてみた。
※このＩＣ、３．３Ｖでも５ＶでもＯＫのようだが、とりあえず３．３Ｖで動作確
認。（モジュールに付いてるＯＳＣはＡｒｄｕｉｎｏ系が主なので５Ｖと思えるが、
ちょっと調べた限りでは、どの電圧で動作するのか記述が見つからない・・）

サンプルは１ＫＨｚのサイン波を出力している。（起動するとデフォで１ＫＨｚの
をサイン波を出力する）

実用的に使うには、出力にアンプを追加したり、レンジ切り替え、周波数切り替え、
高性能なエイリアシング除去フィルターなど工夫が必要だと思うが、とりあえず、
機能を実験するだけのシンプルな構造になっている。

ソースコードは AD9833 Sample に上げてある。
※AD9833.hpp テンプレートは chip ディレクトリーにある。
※このデバイステンプレートは、他のマイコンでも修正無しで使えるはずだ。

-----
シリアルポートと５７６００（８ビット、１ストップ）で接続する事で、対話形式
で、周波数、波形の変更ができるようにした。

freq 2000     ---> 2000Hz
form tri      ---> 三角波
help          ---> ヘルプ