フラッシュメモリの問題は無事解決？しました。
そもそもフラッシュメモリを使おうと思った動機は、バッテリー寿命の計測のためです。なので、余り記憶するデータも多くないことから、時計ICにあるバッテリーバックアップされた31バイトのメモリを使うことで、解決です。 毎秒、作動タイマー(1秒カウントのlong int)を書き込めば、最大5万年もカウント出来ます。 じゃあ、フラッシュメモリは何に使うかと言うと、練習時間の履歴データの保管に使うつもり。これなら、バッテリーの電圧がある時に1時間に1回程度記録すれば、書き込み回数上限も気にしないで行けそうです。 その後は、ずっと状態遷移ロジックのトラブルシュートを行っていました。LCD画面に内部データを表示させて、細かい遷移条件のチューニングやバグ取などです。写真は、①で音検知と練習音検知の条件確認。②で音無し1分間や練習なし１０分間のタイマー確認。③が、システムモード（4=通常モード）、バックライトモード（1=DIMモード）、Oが操作後１分のフラグ確認などといった感じです。 状態遷移ロジックは、割り込み処理で、音検知はバックグランドタスクで実施になっているので、処理タイミングなどの調整が微妙だったり、状態が直ぐ、次に移ってしまったりと、結構、大変です。 また、スタンバイモードとなるとCPUクロックが１MHzになるので、作動速度がとても遅くなりデバッグ表示自体にかなり時間を取られ、確認が遅々として進まないといった感じです。 その中で、問題が更に起きました。 デバッグのため、しばらく放置しておくと、画面が真っ白になっていることが多々発生。不思議なことに時計モードとかでは発生しません。 何だかんだで、1ヵ月位この問題と取り組んでいました。 症状としては、LCDの初期化が失敗したときの様な表示であるところから、それを手がかりにトラブルシュートです。 まず、分かったのは、画面が真っ白な状態でも、輝度コントロールができること。これは、つまりは、処理（割り込み）は動いているということです。更に、それを確認するため、特定のモードの時に、LCDを初期化する様にしたところ、画面が正常に復帰することが確認できました。ここまで分るだけでも結構掛かりました。 また、この事象は、時計モードでは起きたことが無く、練習時間タイマーモードのみ発生しています。単に頻度の問題なのかもしれませんが。 要因を考えてみましたが、多分、LCDコマンド送信途中に割り込みが入って、おかしくなるのかなと想定。コマンド送信の本体機能はSPIハードインターフェースを使っているので割り込みが入っても大丈夫だと思うんですが。 割り込み自体は、各モードでも同じ様に発生する作りですが、練習時間タイマーモードと時計モードの差ということを考えれば、マイク入力のADサンプルをするかしないかです（正確には、時計モードは、サンプルしたデータがいっぱいのまま使わない状態を保持）。 バックグランドタスクのプログラム構造として、 １．マイクＡＤサンプル完了を待つ ２．音声関連処理（音検出、練習音検知など） ３．マイクＡＤサンプルスタート ４．デバッグ表示 ５．練習時間積算処理 となっています。どこで、問題が発生しているか特定するため、上の各行の処理が終わったところで後はスキップするようにしていったところ、３．でスキップすると問題が発生せず、４．まで進むと問題が発生することを突き止めました。あとは、デバッグ表示のどこが問題なのかを調べていくと、下の写真の矢印の表示（音の大きさ）を表示するとダメというこが分かりました。つまりは、ＡＤサンプルをスタートした直後のデバッグ表示で、割り込みがかかると問題の様でした。右下の〇印のところの数字は、矢印表示直後のＡＤサンプル数（HEX値；１０進で104）を表示させたもので、２文字表示で２５６サンプルの半分近くの割り込みが掛かっていることになります。これが、１MHzクロックだと、完全に256サンプルしてしまいます。 つまり、原因は良く分かりませんが、LCDへの表示コマンドを送っているときに、ADサンプルが行われると表示異常になることは確かなようです。 なので、暫定処置として、４．デバッグ表示の前に、ADサンプリングを256点完了させてしまうことにしました。約50ms待つことになりますが、不可解な動きをするよりは良いです。 ということで、大分道草を食ってしまいました（と言っても、その間は作業机更新とかが出来ました）が、状態遷移の細部条件を確認していき、物として完成させていきます。 まだ、まだ、先は長いですが、よろしかった、お付き合い願います。時計ICのメモリ
状態遷移ロジックのデバッグ
不可解な問題
今後の計画
