Darkside（https対応しました）

　Ａを実現させるためには、その前にＢを実現させねばならない。
　Ｂを実現させるためには、その前にＡを実現させねばならない。
　う〜ん、デッドロック。

　ここから抜け出すには、単独で何とかせねばならない。
　幸いな事に、現在のダミーダイオードは４Ａ弱までしかシミュレートできない。そして４Ａであれば、２系統ある電源のうち１系統だけで賄える。つまり、１系統を殺しておいても大丈夫で、それなら負荷分散機能を組み込まなくても構わない。
　負荷分散無し、１系統のみ動作、にて可変電圧出力電源にしておき、それで現在のダミーダイオードを調整しよう。

　そう考えたのだが、dsPIC の制御プラグラムはゴキブリレーザーの負荷分散方式を移植してしまった。手早く元の方式に戻すが、ここでトラブル発生。液晶ディスプレイ表示にＣＰＵタイムを無駄に浪費しないよう、割り込みで表示を行うようにしていた。これが機能しない。
　どこで引っ掛かっているのか調べて行くと、タイマー割り込み内ではＩ２Ｃ通信ができないらしい、と判明した。
　dsPIC のハードウェアＩ２Ｃでは、Ｉ２Ｃ割り込みを有効にする必要がある。そして、タイマー割り込み中にＩ２Ｃ割り込みは使えない。割り込みの優先順位を変えても駄目。Ｉ２Ｃ割り込み自体は可能みたいだが、ＬＣＤ表示するという本来の目的は動作しない。う〜ん、ソフトウェアＩ２Ｃなら何の問題も無く、割り込み中に動作するのだが。

　そうなると、ＬＣＤ表示後に一定時間が経過するまではＬＣＤ表示をスキップする、みたいな一段トリッキーな手法を取らざるをえない。

　ＬＣＤ表示はリアルタイム処理において非常に悩ましい問題で、旧レーザー銃でＰＩＣを２つ使用していた大きな理由でもある。２つのＰＩＣのうち、１つはＬＣＤ表示を行う。もう１つが、制御に専念する。
　ただしそれにも難点があり、ＬＣＤ表示するためには情報を取得せねばならない。その情報は、制御側ＰＩＣでも必要だ。つまり、ＡＤ変換結果その他を、２つのＰＩＣで共有せねばならない。１つのマイコンでＬＣＤ表示を行いつつ制御もやるのと、どっちが簡単かは難しい問題である。dsPIC はＣＰＵ性能が高い上に、ハードウェアＩ２Ｃが使える。だから１つにまとめたが、いずれにしろ面倒は残る。

　タイマー割り込みを１０ミリ秒ごとにして、ＬＣＤへデーターを送ったらタイマークリア。１０ミリ秒後に発生する割り込みでは、フラグを立てる。
　メインループではフラグをチェックし、立っている場合だけデーターを送る。ＬＣＤ表示を６段階に分けて、順番に実行。これによりＬＣＤ表示を、６０ミリ秒ごとに更新。
　いい感じで皮算用通りに成功したが、今度はＡＤ変換値がすべて４０９５になっている。暴走していないことは確認できたが、ＡＤ変換の異常はそのまま。この症状は初めてで、悩む。ほんとに全く、次から次へと・・・（スタートすらさせてもらえない）

　ＭＣＣを確認すると、AD1CON2 の SMPI が６回ごとではなく毎回になっていた。いつの間に設定が変わったのか、分からない。元に戻すとＡＤ変換は正常になったが、変えた記憶がない設定が勝手に変わっているのは、極めて不愉快だ。原因不明なのが、恐ろしい。
　ついでに、この機会にＡＤ変換の時間を長くしてみる。ＡＤＣはハードウェア的には１つしかなく、複数入力を切り替えている。つまり、変換時間が短過ぎればクロストークが発生することは容易に想定できる。現状は激しいクロストークが存在するが、変換を長くすれば解消するのか？

　ＴＡＤを最小の９ＴＣＹから、４倍の３６に増やしてみた。すると、明らかに効果あり。だが、完全ではない。
　そこで、許容可能な限度まで長くしてみる。
　時間分解能として、０．１ミリ秒は確保しない。入力６チャンネルを次々に切り替えているので、１チャンネルあたり１６μ秒以内で済ませたい。

　ＡＤＣは、サンプリング時間と変換時間がある。　

　サンプリング時間は、ＴＡＤの１４倍固定。変換時間は設定可能。そこで、１８に設定し、両者の合計時間を３２ＴＡＤとする。これでＴＡＤを３５ＴＣＹすなわち約０．５μ秒にすると、ＡＤＣの所要時間が１６μ秒ぐらいになる。
　結果は非常に良好で、クロストークはほぼ完全に消失した。

　試しにＴＡＤを１６ＴＣＹに減らしても、性能は殆ど同じに見える。
　目標の倍速でＡＤ変換結果が更新される、この設定で決まり。