おしゃべり時計withUSB開発日誌(10)、チャイム時間チェックのロジック、RTCCキャリブレーションロジックの再検討。

 ４．チャイムが時々ならなくなる。チャイム時間チェックロジックの再検討。

これは、次のチャイム時間を取得するロジックvRTCC_getNextChimeTimeもしくはvRTCC_TimeCheckが動かず、pbFFF_get_nextTimeで次の時間を取得できていないのだろう。　

各保持している時間、bNextHHMM、bNextHHMM、bCurrentHHMM は文字列型だが、割り込み処理中では、xsprintf関数が上手く動かない為、1分ごとの割り込みでは、チャイム時間やアラーム時間のチェックが出来ずこの割り込み処理の修正が必要である。　なので1分毎の割り込み処理中に数字⇒文字列変換の必要がないように、これらの変数を文字列からinteger型に替える。　

※問題の関数＝＞xsprintf(bCurrentHHMM, "%02d%02d", currentTime.tm_hour, currentTime.tm_min);

各保持している時間、bNextHHMM、bNextHHMM、bCurrentHHMMをまず数字型に変更する。合わせて、RTCCobjをstruct型で定義してそこに変数を全て入れる。

そもそも、これらbNextHHMM、bNextHHMM、bCurrentHHMMの変数が文字列型を使っていた理由は、その文字列でchime.txtの一覧をサーチする為だったので、このサーチ関数pbFFF_get_nextTimeを使う時だけ時間を数値⇒文字列変換して対応する事にする。　

サーチ関数pbFFF_get_nextTimeの返り値も文字列な為、文字列⇒数値に変換する必要がある。　これには当初 xatoi関数を使っていたのだが、思うように変換できない場合があり1時間ほど悩んだ挙句、atoi関数を使う事にし解決した。　(※xatoiには変換エラー時のリターンがあったため当初こちらを利用していた。)

５．RTCCキャリブレーションロジックの再検討

RTCCの進み遅れ具合を設定する、キャリブレーション値は時刻を合わせるごとに512⇒128⇒64⇒32⇒16⇒8⇒4⇒2⇒1⇒１、、と半分づつ、最後は1づつ変化するようにしている。　しかしなが最初の時刻設定を間違えてしまった場合、その間違え分を取り返すまでに相当数の回数を時刻合わせいなければならなくなる。　そこでキャリブレーション値の変化を1/2ではなく２/３づつとなるように修正する。

また、時計用に使用しているクリスタルVT200の誤差が±20ppmとなっている。

PIC32MXのRTCCのキャリブレーションの範囲が±260ppmであり、これを10ビット(±512)で設定可能であるため、20ppm = 20/260*512 = 39.38 となる。　3で割り切れる42をスタートとして、42⇒28⇒19⇒13⇒9⇒6⇒4⇒3⇒2⇒1、、と変化するように修正する。

20200913(+3.0h)