現在カレントとして使っている 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; }

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