明日は午後から休暇なので、今日中にいろいろやっとかないとな。
なんて考えながら、ふと気づいたことがあって、オシロスコープで測定しようとしたら、
そう単純にはいかなかったという話。
これはマイコンの外部にラッチICがあるのだが、
このラッチにストアするタイミングが外部から入力されるパルスの立ち上がりの少し前になるように設計している。
この少し前というのが想定の時間内に収まっているか見たかったのである。
で、外部から入力されるパルスの立ち上がりでトリガをかけて、
ストア信号の波形をずっと上書きさせたのだが、どうも想定の時間を超えるケースがあるようだ。
ほとんどは想定の時間内に入っているが、たまに超えると。
なので、このときの他信号の波形を取得したかったのだが、
外部からのパルス信号の立ち上がりが、ストア信号の立ち上がりの一定時間前にないケース、
これに着目してトリガをかけようとするとどうにもいかなかった。
複合条件でのトリガというのは可能なのだが、
トリガAが発生した後、指定時間経過後にトリガBが発生した場合に限られ、
これだとどうにも今回のケースを捕まえるのは難しいようだ。
というわけでオシロスコープの説明書を真面目に読んだのだが、
信号のパターンの継続時間によりトリガをかけることができることに気づいた。
さっきのストア信号と外部からのパルス信号はいずれも短時間Hiになる信号である。
もし想定通りに行っていれば、双方がLoになる時間というのは一定範囲内に収まる。
具体的には外部からのパルスの周期が1000us、Hi同士の間隔が50us以上となる想定ならば、
双方がLoになる時間は 50us～950us の範囲になるはずである。
この範囲外の場合はトリガをかけるという設定をすればよさそうだ。
で、当初の設計だと全然ダメだったので改めてタイミングを計算し直して、
それでやったのだが、想定外の形で範囲外に出ていた。
それはラッチ処理がまるごと1回飛んでいることがあったのである。
一体なにが起きているのか、デバッグ信号を追加して判明したのは、
想定外の形で多重割り込みが起きていたということである。
このパターンは多重割り込み起きないんじゃなかったっけ?
想定と異なるから想定外なんですけどね。というわけで明日の午前中に追跡する予定である。
この問題を回避するだけなら割り込みマスクを追加して多重割り込みが起こらないようにすればよく、
暫定的にそういう対策をしたら確かに起きなくなった。
トリガ条件を少しずつ動かしたのだが、新たな見積もりの範囲に入っているので、そこはよさそう。
やはり実測することは大切ですね。