前回、TinyGoのATSAMD21上でのRTC設定についてホンワカしたことを書いてしまったので今回は図入りで補足させていただきます。また、RTC内蔵の「デジタル歩度調整機能」の制限（なぜTinyGoの使い方とは両立しないか）についても述べさせていただきます。結局時計にしたければアナログ歩度調整してからなのよ。。。
※「AT SAMの部屋」 投稿順indexはこちら
まずは冒頭アイキャッチ画像に掲げましたるダイアグラムをご参照ください。一番上に書きましたのは、関係する構成要素のみを発振子からRTCまで書き連ねた単純化したハードウエア構造です。左から
-
- 内蔵のRCオシレータ。OSC32Kとよばれる32kHzのオシレータ
- 外付け水晶振動子(XTAL)。やはり32kHzのオシレータ
- GCLK-SRCと書かれている模式的要素。２つのオシレータの選択。
- GCLK DIV。「GCLK」クロックドライバ内の分周器
- RTC Prescaler。RTC入り口の分周器。
- RTC FREQCORR。デジタル歩度調整器。上記のプリスケーラに微妙に介入。
- RTC Conter。３２ビットのカウンタ。モードにより動作が変わる。
となっています。
TinyGoでのデフォルトの使い方
TinyGoでのデフォルトの設定が真ん中に書かれています。内蔵オシレータを選択。その周波数32.765kHz（RC発振なのでかなり誤差あり）を分周せずGCLKでドライブしてRTCに供給。RTC側でもプリスケーラはスルー。FREQCORRもスルー（FREQCORRはプリスケーラが分周していないとその動作に介入できない）でRTC Counterには32.765kHzが入力されます。
RTC Counterは３２ビットのシンプルなカウンタ（モード０）で動作してます。TinyGoのtimeモジュールなど、TinyGoの根幹部分で時間がらみの動作はこのカウンタの数値に依存して制御されています（このカウンタの１ステップ＝約３０．５マイクロ秒を当てにして各部動作しているようなので、この値を変更すると各部の動作がおかしくなる筈。）
カレンダー・クロックとして使用する場合の設定
Microchip社の中の人がカレンダー・クロック（モード２）で使う場合の「標準的な」設定を想像して描いてみたものが３番目の図です。カレンダー、クロックなので時、分、秒だけでなく年、月、日もありです。３２ビットのカウンタは複数のビットフィールドに分割されフィールド内は２進ですが、フィールド間の繰り上がりなどは複雑な（でも小学生でも知っている）ものとなります。ちゃんと閏年にも対応しておりますぞ。
この場合、カウンタに供給するクロックは１Hz、つまり秒です。なるべく精度が良いものが要求されます。時計となると月差何十秒くらいは最低要求されるでしょう。10ppm（100万分の１が1ppm)精度でも月差３０秒くらいになるはずです。
その場合外付けのクリスタルで32.768kHzを生成します。後に述べますが最低でも精度127ppm以内くらいにしないと内蔵のデジタル歩度調整にも引っ掛かりません。実用的には数十ppmくらいの精度必須と思います。そこまでの精度とするには漫然と32.768kHzのクリスタルを接続しても多分駄目で、アナログ的な歩度調整が先に必須じゃないかと思います。クリスタルについているキャパシタの容量を調整したりする技。時計に詳しい人や水晶振動子メーカにお願いすれば回路に適した容量決めてくれるでしょう（ただしメーカにお願いするときは注文の最小ロットの数量聞いてからにした方がいいです。きっと。）
その32.768kHz（のつもり）のクロックをGCLKで１０２４Hzまで分周してRTCに供給します。RTCのプリスケーラが１０ビットなので32.768kHzのままでは分周しきれないためです。これを１０ビット（１０２４）で分周すれば１Hzの信号が得られます。
ここでようやく登場するのがRTC内蔵のデジタル周波数調整機能です。RTCのプリスケーラの動作に介入してPPMオーダの補正をかける機能です。今回、設定値と補正可能なPPM値、そしてそのときの元の周波数を勝手に計算してみましたぜ（間違えているかも知れないので、もしも使うときは自分で計算してくだされ。）
つまりオシレータの周波数が32772Hzから32763Hzの間にあれば、最後はデジタルで微妙に補正可能と。
でもね、オシレータの周波数なんか、ちょっと温度変わったら「イチコロ」らしいです。安易にデジタルに頼ってはダメですな。この機能はお値段の割に精度を上げるための便法かも知れませんで（それにこのごろはInternetでNTPや、GPSあるから時計の精度はテキトーでもなんとかなるし。。。）歩度調整なんぞ知らんでもIoTアプリは出来るのかも。ホントか？