21:26開始以前の問題Aを実現させるためには、その前にBを実現させねばならない。Bを実現させるためには、その前にAを実現させねばならない。う〜ん、デッドロック。ここから抜け出すには、単独で何とかせねばならない。幸いな事に、現在のダミーダイオードは4A弱までしかシミュレートできない。4Aであれば、2系統ある電源のうち1系統だけで賄える。1系統を殺しておいても大丈夫で、それなら負荷分散機能を組み込まなくても構わない。負荷分散無し、1系統のみ動作、にて可変電圧出力電源にしておき、それで現在のダミーダイオードを調整しよう。制御プラグラムはゴキブリレーザーの負荷分散方式を移植してしまった。手早く元の方式に戻すが、ここでトラブル発生。液晶ディスプレイ表示にCPUタイムを無駄に浪費しないよう、割り込みで表示を行うようにしていた。どこで引っ掛かっているのか調べて行くと、タイマー割り込み内ではI2C通信ができないらしい、と判明した。ハードウェアI2Cでは、I2C割り込みを有効にする必要がある。タイマー割り込み中にI2C割り込みは使えない。割り込みの優先順位を変えても駄目。I2C割り込み自体は可能みたいだが、LCD表示するという本来の目的は動作しない。う〜ん、ソフトウェアI2Cなら何の問題も無く、割り込み中に動作するのだが。なると、LCD表示後に一定時間が経過するまではLCD表示をスキップする、みたいな一段トリッキーな手法を取らざるをえない。LCD表示はリアルタイム処理において非常に悩ましい問題で、旧レーザー銃でPICを2つ使用していた大きな理由でもある。2つのPICのうち、1つはLCD表示を行う。1つが、制御に専念する。それにも難点があり、LCD表示するためには情報を取得せねばならない。その情報は、制御側PICでも必要だ。AD変換結果その他を、2つのPICで共有せねばならない。1つのマイコンでLCD表示を行いつつ制御もやるのと、どっちが簡単かは難しい問題である。CPU性能が高い上に、ハードウェアI2Cが使える。1つにまとめたが、いずれにしろ面倒は残る。タイマー割り込みを10ミリ秒ごとにして、LCDへデーターを送ったらタイマークリア。10ミリ秒後に発生する割り込みでは、フラグを立てる。メインループではフラグをチェックし、立っている場合だけデーターを送る。LCD表示を6段階に分けて、順番に実行。これによりLCD表示を、60ミリ秒ごとに更新。いい感じで皮算用通りに成功したが、今度はAD変換値がすべて4095になっている。暴走していないことは確認できたが、AD変換の異常はそのまま。この症状は初めてで、悩む。6回ごとではなく毎回になっていた。いつの間に設定が変わったのか、分からない。元に戻すとAD変換は正常になったが、変えた記憶がない設定が勝手に変わっているのは、極めて不愉快だ。原因不明なのが、恐ろしい。ついでに、この機会にAD変換の時間を長くしてみる。ADCはハードウェア的には1つしかなく、複数入力を切り替えている。変換時間が短過ぎればクロストークが発生することは容易に想定できる。現状は激しいクロストークが存在するが、変換を長くすれば解消するのか?TADを最小の9TCYから、4倍の36に増やしてみた。すると、明らかに効果あり。そこで、許容可能な限度まで長くしてみる。時間分解能として、0.1ミリ秒は確保しない。入力6チャンネルを次々に切り替えているので、1チャンネルあたり16μ秒以内で済ませたい。ADCは、サンプリング時間と変換時間がある。サンプリング時間は、TADの14倍固定。そこで、18に設定し、両者の合計時間を32TADとする。これでTADを35TCYすなわち約0.5μ秒にすると、ADCの所要時間が16μ秒ぐらいになる。結果は非常に良好で、クロストークはほぼ完全に消失した。試しにTADを16TCYに減らしても、性能は殆ど同じに見える。目標の倍速でAD変換結果が更新される、この設定で決まり。