値が6毎に偏る問題は解決できなかったので、とりあえずカウント値を6で割って、奇数(1)か偶数(0)かを乱数ビットとして取り込んでみました。
12ビットタイマー(ITCMP)の値による連続同値の分布をみたところ 測定時間が0.915msec(14+1x0.061msec)より短いとFIPS(20000bit毎に発生する連続同値の頻度)に適合できないようです。 特に連続1～3ビット同値になる規格に不適合です。
ということで、256msecあれば256ビットの真性乱数を生成することができました！
↑ 黒線が頻度上限、赤線が頻度下限
グラフから測定時間が短いと同値が連続する傾向が読み取れますね。(6ビット以上連続して同じ値になる確率があり得ないほど高いです)
クロック差を利用した乱数生成のサンプルプログラムをアップしてみました。(CS+for CA版ですけど) japan.renesasrulz.com/.../385
次は、A/D入力を使った乱数生成です。
端子をオープンにした状態でA/D変換すると、ANI0はVDDレベル(3FFh)、ANI1はGNDレベル(000h)に張り付いてしまうので、ANI2を使ったところ変換時間に関わらず変換値は±5以内に収束してしまいました。A/D端子オープン状態の入力インピーダンス(10MΩ程度?)による熱雑音にしてはバラツキが大きいので、ESD保護用のショットキーダイオードなどから発生する1/fノイズ由来のバラツキみたいですね。
とりあえず、AD変換値の最下位1ビットを乱数列とした場合、真性乱数にはなりませんでした。 1と0の総数に偏り(5%以上)が出ていて、連続同値の成績が悪いです。
変換時間が2.3usec、38usec共にFIPSの規格(黒と赤の範囲)から食み出しています。残念！
入力インピーダンスが高いANI16以降のチャンネルを使うと更に状況悪くなって、0/1の偏りが20%以上になるようです。>_< ちなみに、内部基準電圧や温度センサーを変換対象にすると偏りか99%を超えます。
Kirin様 お世話になっております。 大変参考になるデータの公開、ありがとうございます。 自分が使うようなケースだと、 初期値設定でクロック差による乱数、メイン処理実行時にA/Dポート式と 使い分けるのがいう感じがよさそう・・・