１．Sleep時の消費電流、またはバックアップコンデンサの有効時間。
以前Sleep時の消費電流が1mA程度であったが、これの原因の一つがCDSで明るさを検知してPIC32MXのコンパレータへの入力回路にあった。
問題の回路は+5VをCDSと100KΩの抵抗で分圧してコンパレータの入力としていた。 周囲が明るいとき、CDSの抵抗値は数10KΩ以下となり、コンパレータの入力がCPUの電源電圧+3.3V以上となり、漏れ電流が流れてしまっていたようである。
CMP1, CMP2両方とも100KΩづつ追加した理由は、CMP1,2のリファレンス電圧が一つしか指定できす閾値を揃える為である。 またCMP1に100KΩを3っつ直列に並べたのは、抵抗の在庫を増やしたくなかったのと、同じロット内の抵抗ならばそれぞれの誤差の偏りが同様なので、１／３の分割がより誤差が少なくなる為としておく。
その他あちこち弄ってSLEEP時の消費電流を下げようと悪戦苦闘したのだが、結局520μAまでしか下がらなかった。
20200922(+20hぐらい？)
４．チャイムが時々ならなくなる。チャイム時間チェックロジックの再検討。
これは、次のチャイム時間を取得するロジック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)
おおむね対応するべき課題は以下の通り。
１．Sleep時の消費電流。
２．Sleepから復帰した時のボタンの効き。
３．曜日の実装。
４．チャイムが時々ならなくなる。
５．RTCCキャリブレーションロジックの再検討
６．スイッチメニューで、日付・時間設定で発声しない。
１．Sleep時の消費電流。
今の所Sleep時に1mAを消費しているが、100μA程度には抑えたい。
２．Sleepから復帰した時のボタンの効き。
ボタンを押してSleepから復帰しても、USBメモリのエニュメレーションが終わらないと、メニュー動作に入らない。 Sleep起動時の押されたボタンでメニュー動作に入るようにしたい。
３．曜日の実装。
今まで”何曜日”と発声していなかったが、これを実装する。
４．チャイムが時々ならなくなる。
これは、次のチャイム時間を取得するロジックvRTCC_getNextChimeTimeもしくはvRTCC_TimeCheckが的確に動いて、pbFFF_get_nextTimeで次の時間を取得できていないのだろう。
各保持している時間、bNextHHMM、bNextHHMM、bCurrentHHMM は文字列型だが、割り込み処理中では、xsprintf関数が上手く動かない為、これらの変数を文字列からinteger型に替える必要がある。
※問題の関数＝＞xsprintf(bCurrentHHMM, "%02d%02d", currentTime.tm_hour, currentTime.tm_min);
５．RTCCキャリブレーションロジックの再検討
RTCCの進み遅れ具合を設定する、キャリブレーション値は時刻を合わせるごとに512⇒128⇒64⇒32⇒16⇒8⇒4⇒2⇒1⇒１、、と半分づつ、最後は1づつ変化するようにしている。 しかしなが最初の時刻設定を間違えてしまった場合、その間違え分を取り返すまでに相当数の回数を時刻合わせいなければならなくなる。 そこでキャリブレーション値の変化を1/2ではなく２/３づつとなるように修正する。
６．スイッチメニューで日付・時間設定している時に、設定日付・時間を発声しない。
これは、設定日付・時間の値が変更された事が、発声部の検知対象外となっている為と思われるので、該当部分のコーディングを追加する。
20200912(+1.0h)
時計回りの機能を、色々とデバッグ中。
省電力の為、通常はPICはSleepしてUSBの電源も落としておいて、スイッチが押されたら、もしくは1分経過したら、SLEEPから復帰しUSBメモリの電源を入れて、時間を喋る事になる。
しかしながら、USBメモリは電源を入れたら直ぐに使えるわけではなく、アドレスを割り振るなどのエニュメレーションをして、Configuredのステータスにならないとメモリの内容を読み出せない。 これに1~2秒、USBメモリによっては数秒かかるのだ。
なので、USBのエニュメレーションが終わってから、USBメモリから音声データを読み出して音声を再生する必要がある。 そうしないとエラーとなる。悪くすれば処理が帰ってこず、プログラムが暴走するなんて事もある。 つまりUSBメモリのステータスを見て処理を進めていかなければならず、地味にめんどくさかったりする。
しかしながらここは肝の処理なので、注意してデバッグしていく必要がある。
20200829(+4.0)
おしゃべり時計のメインの機能にチャイムがある。 これはchime.txtに列記した時間になると”何時何分です。”と時間を喋る機能である。 これ自体は、以前のプログラムを踏まえて問題なく実装する事が出来た。
おしゃべり時計のもう一つのメインの機能が音楽ファイルを順番に再生していく機能がある。これも順番に再生するだけならば問題なく実装する事が出来た。
音楽を順番に再生しているときに、チャイムの時間が来たらどうするかというと、一旦音楽を中断して時間を発話させたい。だって、時計なのであって、音楽の再生はおまけの機能なのだから。 これを実現する為の処理の流れは下記のようになる。
１．音楽を再生中
２．チャイム発生時間の到来を検知。
３．再生中の音楽をストップ
４．chime.txtのファイルをサーチして該当した時間の音声データファイル名を取得する。
５．時間の音声データファイルを再生する。※複数ある場合、複数回再生する。
５．次のチャイムの時間を、chime.txtをサーチして取得する。
６．上記３．でストップした音楽をはじめから再生する。
といった具合になる。 今回作成している”おしゃべり時計withUSB”は、ファイルオブジェクトは一つしか実装していない。バッファを8Kbyteも使う為、メモリを圧迫してしまうからだ。
なので一つのファイルオブジェクトを使い回すことになる。上記１~６を実現するのに５つ以上のファイルをとっかえひっかえ読み出す必要がある。 これの切り替えがなかなか上手く出来ずに何日か悩みつつデバッグしていたが、本日ようやく何とかスムーズに切り替える事が出来るようになった。
まだまだ、スイッチメニューの切り替えが上手くいかなかったりするので、今しばらくはこのあたりのデバッグに時間がかかりそうである。
20200901(+8.0h)
FusionPCB から基板がとどきました。20240121. 1月11日に発注したので10日で出来上がって届きました。 早速組み立てましたがが、イヤホンジャックのフットプリントが裏返っており、痛恨のミス。。。 しかしながら、他にも問題が無いか一通り組み立ててチェックしました...
