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

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

工夫と言うのは、バイナリーサイズが肥大化しているのです・・
問題になってるのは「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」を観れば直ぐに解ると思います。
※８進数は、通常あまり使わないので、オプションとしています。