Darkside（https対応しました）

　故障判定を行なった結果、
・ＯＫならカウンターを０にする。
・ＮＧならカウンターを＋１し、所定の回数に達していれば故障扱い。

　というように条件分岐を追加。
　１０回連続までは故障扱いしないようにしたところ、普通に５Ａに収束して使用できるようになった。だが、条件分岐がバグっていて絶対に故障扱いにならないという可能性もある。そこで、今度は１回連続にしてみた。一瞬で故障扱いになった。
　次の問題は、故障扱いまで連続何回と定義するのが適切かということ。
　回数を増やせば誤判定は減るが、故障検出に要する時間が長くなる。

　昨日の段階では、１分ぐらい照射してからＮＧの連続回数の最大値をフラッシュメモリーに書き込む・・・みたいな調査を考えていた。しかし、調査用プログラムコードが案外複雑になる。高級言語を使うなら何でもない処理だが、ＰＩＣアセンブラでは調査用コード自体に幾つのバグが紛れ込むかも分からない複雑な記述を要する。
　実際、ＰＩＣを使っていて最大の弱点はアセンブラのマクロが貧弱過ぎることだと思う。以前書いたが、中でもただ一点「マクロでローカルラベルが使える」ように改善されるだけで桁違いに生産性が上がると思う。

　そんな訳で、今度は連続２回で試す。３回、４回と連続ＮＧ許容回数を増やしながら、故障判定されるまでの時間を測る。時間の伸び具合から、事実上無限に判定されなくなるであろう回数を推測し、それを最終的に設定する。
　だが想定外にも、２回に増やしただけで何十秒経過しても故障判定されない。
　プログラムコードを確認すると、ＮＧでカウンターを＋１した後の飛び先でカウンターがクリアされていた。最後に飛ばす場所がＯＫ時と同じだった。これではカウンターは永久に２にならない。

　良くある馬鹿ミスだが、修正してもやはり２回連続のＮＧが発生しない。
　試しに敷居値を書き換えて、ほぼ常にＮＧと判定されるようにしてみた。２回はもちろん１０回許容にまで設定しても、一瞬で故障扱いになった。つまり、カウンター周りの追加コードはもうバグっていない。
　どうやら巨大ノイズは発生原因に周期性でもあるのか、頻度こそ高いものの２回連続で発生する確率は非常に低いようだ。
　そこで、許容回数を５回に決定した。