なんちゃってロジアナ 10

Communication Boxのデバッグ時にI2C液晶を接続して動作確認した。その時のセットでI2Cバスをロジアナで観測してみた。

トリガ条件はI2C通信の開始（SCLがHの時にSDAが立ち下がる）にした。

以下のような波形が採れた。

300msec毎にI2C通信の塊がある。
このデモは300msec周期のタイマー割り込みで動作させており、観測値と合っている。


通信の部分を拡大してみた。  特に異常なところは無いと思う。



次に、GPIBの信号観測をして見た。
Communication BoxのGPIB I/Fの動作確認でシリアルポールを確認した時に、デジタルオシロからのステータスバイトのハンドシェイクが連続発生してしまうという現象があった。今回はそれを見てみた。
以下の画面右側のメニューに対応するボタンを押下すると、デジタルオシロからSRQ（サービスリクエスト）が発行される。

測定風景

以下のような波形が採れた。
表示項目のDIO[7:1]はGTKWaveの機能を使ってDIO7～1をバス表示したものであり、DIO[7:1] (inverted)はさらにその論理値を反転させたものである。  また、GPIBのメッセージは7bitで定義されているのでここでも7bitでのバス表示にしている。
               
 (プロトコル・ハンドブック 朝日新聞社より引用）

 GPIBバスは負論理なのでそのままではデータバスの値が分かり辛い。そこで反転して正論理表示させている。

 シリアルポール時の処理は、SPE(0x18)コマンドに続いてTAx（0x4n）でトーカーを指定しステータスバイトを送信させる。この処理を必要なだけ（デバイスの数だけ）行い、最後にマスタがSPD(0x19)、UNT(0x5F)を送信して終了する。

以下はシリアルポールが開始される箇所で、SPEからTA送信までの波形だ。

以下がステータスバイトのハンドシェイク部とSPD、UNTによるシリアルポール終了の部分だ。

ステータスバイトのハンドシェイク完了を待たずに、SRQがATNがHになった直後にネゲートされているのが少し意外だが、このタイミングはデバイス側が制御するものなのでGPIB IPとしてはどうしようも無い。また、ステータスバイトのハンドシェイクのタイミングに異常は無いと思う。　にも関わらず、１発で終わらずに連続するということは、そういう仕様なんだろう。