ＶＨＤＬを速習！ ＸＣ９５１４４ＸＬ＋１６ＭＢ・ＳＩＭＭを使ってＵＳＢプロトコルアナライザを作ってしまいました！
主目的は差し迫った事情からＵＳＢプロトコルの解析をすることだったのですが、その手段として選んだのがコレ！
［第５９回］
●ＰＩＣ１８Ｆ１４Ｋ５０のＲｅａｄ−ｍｏｄｉｆｙ−ｗｒｉｔｅの怪（２）
前回からの続きです。
前回は、カメレオンロジアナで観測した、Ｚ８Ｓ１８０がＰＩＣ１８Ｆ１４Ｋ５０にＣＰＵ ＲＥＳＥＴの発生を伝えたのに応えて、ＰＩＣ１８Ｆ１４Ｋ５０がＲＢ４とＲＢ５からＬ出力したときの画像をお見せして、説明不能な異常現象です、と書きました。
どこがそれほどに異常なのでしょうか？
もう一度カメレオンロジアナの画像を見ていただきましょう。
ＰＲＯＢＥ０３がＲＢ５でＰＲＯＢＥ０４がＲＢ４です。
前回書きましたように、ＰＩＣ１８Ｆ１４Ｋ５０のその部分のプログラムは、
ＢＣＦ ＰＯＲＴＢ，４
ＢＣＦ ＰＯＲＴＢ，５
でした。
タイミングからすると、最初に ＢＣＦ ＰＯＲＴＢ，４ の実行でＲＢ４がＬになったあと、ＢＣＦ ＰＯＲＴＢ，５ の実行によってＲＢ４の出力が反転してしまったかのように見えます。
ＰＩＣのポート出力はＲｅａｄ−ｍｏｄｉｆｙ−ｗｒｉｔｅになっています。
出力ポートの全ビットを一度に変更するような使い方の場合には、この機能は意味を持ちません。
通常の出力と異なってくるのは、特定のビットのみを出力する場合です。
たとえばＢＣＦやＢＳＦは、そのビット出力のみを０または１にするのではなくて、ＰＯＲＴＢならＰＯＲＴＢの全ビットを一度読み込んだ上で指定したビットだけを変化させて、再度全ビットを出力させるという動作をしているようです。
この場合に出力ラッチの値を再読み込みするのならば、特に問題は発生しません。
しかしＰＩＣでは出力に設定したポートから入力を行なうと、出力ラッチのデータを読み込むのではなくて、その端子の状態を読み込みます。
もしもなんらかの理由で出力ラッチの値と出力端子の値が違っていた場合には、ＢＣＦあるいはＢＳＦによって読み込まれた値は、その直前に出力された値とは異なってしまう可能性が無いとは言えません。
これはしかしかなり特殊な状況の場合に限られると思います。
ふつうはそんな異常な状態は想定することはできませんが、あるとすれば出力端子に非常に大きな負荷がかかっていて出力ラッチの値がそのまま維持できないとか、大きな容量負荷のために出力ラッチの値がすぐには出力端子に反映されないといったような場合が考えられます。
そのいずれの場合でも、当然出力端子を測定すればそのような異常な値であることはわかるはずです。
では上の画像の場合にはどうでしょうか？
カメレオンロジアナの測定端子はＰＩＣの出力端子の値をそのまま忠実に捉えています。
そのことから考えると、ＰＲＯＢＥ０４（ＲＢ４）はＢＣＦ ＰＯＲＴＢ，５ が実行されるときまでにちゃんとＬに下がっていたはずです。
それなのにその時点でＲＢ４の出力をｒｅａｄ−ｍｏｄｉｆｙ−ｗｒｉｔｅによって読み込んで再出力したら（当然Ｌであるべきはずなのに）なんとＨになってしまったというのはどう考えてもおかしいではありませんか。
一体何がどうなっているのか、これはこのまま捨て置くわけにはまいりませぬ。
まずはテストプログラムを作って再現性のテストから始めることにいたしました。
といいましてもそれをＬｅｇａｃｙ８０８０でやるというのはちょっと乱暴でありましょう。
簡単なテスト回路を組んでそこでテストをするのが一番なのですけれど、さて何か適当なものはありますでしょうか？
過去記事をさぐってみましたら、ありましたよ。
ちょうどおあつらえ向きのものが。
「ＰＩＣでＵＳＢを」［第７８回］です。
おお。これですよ、これ。
超シンプルな回路に、ちょうど手頃なサンプルプログラムまであるじゃありませんか。
さっそくこれを使ってテストをしてみることにいたしました。
説明の途中ですが本日は時間がなくなってしまいました。
この続きは次回にいたします。
ＣＰＬＤ＋ＳＩＭＭを使ってＵＳＢプロトコルの解析を！［第５９回］
２０１４．６．３ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る