2014年1月27日月曜日

Communication Box 24 (GPIB IPの作成 13)

GP-IB I/Fの基本的動作確認もとれ、Communication Boxのハードウェアとしては問題無いと判断できるので以下の様に設置した。

我がpoor man's labはFLUKEのマルチメータも所有している。この測定器の外部I/FはRS232CなのでCommunication BoxのCOMポートと接続した。これで電源、オシロスコープ、マルチメータをCommunication Box経由で制御できる環境が整った。

GP-IB IPだが、若干の仕様変更してトーカ・オンリーモードとリスン・オンリモードも使えるようにした。 具体的にはCONFIGレジスタのTLK_EN、LSN_ENビットをそれぞれR/W可能とし、そこで設定するようにした。


GP-IBバスに接続する機器がトーカ役とリスナ役の2台のみの場合は、最初からその役割専用モードにして使用する場合もある。そのような使い方にも対応できるようにした。

2014年1月26日日曜日

Communication Box 23 (GPIB IPの作成 12)

問合せコマンド(query command)が連続して実行できない理由が判った。
GPIBバスのIFC、REN、ATN、EOI、SRQの信号は基本的にLINEレジスタから制御する。


この内、EOIはやや特殊である。
ライトはIPがコントローラとして動作していて且つコマンドモードの場合に有効となる。つまり、その場合にライトした値がバスに出力される。これに対してリードは常にバスの信号の状態を返す。問合せコマンドに対する応答データを受信後バスをコマンドモードに戻す際に、ソフトウェアを以下のように記述していた。

  pGPIB->LINE |= LINE_ATN

これで、ATNのみをTRUEにしているつもりだった。GPIBバスのコマンドモードとデータモードはATNのレベル(HかLか)によって決まる。また、上記のとおりEOIはリードとライトで参照する対象が異なるのでこの記述だと、データモード側のEOI値(現在のバスの状態)が、コマンドモード側のEOIに設定されてしまう。 問合せの応答データの最終バイトにはデリミタとしてEOIがアサートされるが、このEOIがネゲートされるタイミング次第では上記のモード切替のリードでアサートされたEOIがリードされることになり、それがコマンドモードで設定されることになる。これが原因で、以降のコマンド送出が滞ってしまっていた。コマンドモードでEOIに1をライトするのはパラレルポールを行う場合のみであり、それ以外ではEOIは0をライトしなければならない。したがって、上記は以下のように記述すべきであった。

       pGPIB->LINE = (pGPIB->LINE & ~LINE_EOI) | LINE_ATN

つまり、リード値のEOIの部分をマスクしてATNの部分を1にする。このようにソフトウェアを修正することで連続実行も可能となった。この部分はレジスタの仕様を変更したほうがいいかな。。。コマンドモード時以外は0になるようにした。

オシロ2台をGPIBバスに接続して、それぞれに問合せコマンドを発行してみた。


プログラム


結果


それぞれで3回づつ連続した場合




FIFOの閾値とか、割込み、シリアル/パラレルポール等々、まだ確認すべきものはあるが、一応これで基本的な送受信の確認は取れたと思う。


2014年1月25日土曜日

Communication Box 22 (GPIB IPの作成 11)

先日入手したGPIBアダプタを相手にして動作確認を始めたところ、コマンドモードでのハンドシェイクは行うのだが、データモードになるとNDACがHレベルに上がりっぱなしになりハンドシェイクしない。 このGPIBアダプタはレギュレータ電源用GPIBアダプタだが電源本体は持って無いので、アダプタ単体のみを通信相手として使ってみている。それが原因かとも思ったのだが、どうもおかしい。こちらのIPからGPIBアダプタに対してLA_MSGでリスナ指定をしているのだが、それが正しく行われないためにGPIBアダプタがリスナにならず、NDACをLにドライブしていないようだ。やはり、原因はこちらのIP側にある筈である。。。。あれこれ思案した結果、データバスの論理が逆なのでは無いか?との考えに至った。  GPIBバスの信号は負論理なのだが、データバスに関してはデータなのだから正論理も負論理も無いだろう、だからそのまま、つまり正論理だろうと思い込んでいたのだ。ところが、実際はデータバスも負論理にする必要があるようだ。 実際、改めて参考資料を読み直したところ、プロトコルハンドブックにDIOも負論理との記述があった。つまり、GPIBの規格について一つ誤解していた。そこで、データバスを負論理に修正した結果データモードでもハンドシェイクするようになった。

以下はハンドシェイクの波形で、上がDAV、下がNRFDである。


こちらは、上がDAV、下がNDAC


測定は以下の状態で行った。 GPIBアダプタ側のコネクタ側から1.5mのケーブルで信号を引いてきてその先の(治具)基板の信号をオシロで観測している。上記で信号反射のような波形が見えているのはその所為ではないかと思う。


ハンドシェイクが正常に行われるようになったので、GPIBアダプタにPWIBという問い合わせコマンドを送って機種名を取得できるかやってみたが、結果は取得できなかった。 電源装置が繋がっていないのだから返信すべき機種情報が判るはずもないので、この反応は当然といえば当然であろう。

ということで、今度は通信相手をAgilentのE3631Aに変えて動作確認するしてみることにした。
以下のプログラムで6Vチャンネルの出力電圧を制御してみた。


電源側の動作の様子
video

出力


電圧設定部をforループにして繰り返してみた。


プログラム通りの出力が得られている。

今度は、HPの54616C(デジタルオシロ)と通信を試してみた。
以下のようにしてオシロの画面に文字列を表示させる。




以下のプログラムで*IDN?コマンドを送って機種名を取得してみた。


取得できた。


一応通信は出来ていそうであるが、一つ不可解な現象が見つかった。
問い合わせコマンドを連続すると2回目のコマンド通信時にハンドシェイクが上手くいかなくなるようで、いつまで待ってもコマンドFIFOが空にならない。




うーむ…

でも、まぁ、昨年の8月頃に始めてから漸く実機で通信ができる段階まで来れた。いつものIP作成と違い今回は筐体の加工や回路作成もあったのでそれなりに時間がかかってしまったが、あともう少しで完成しそうだ。

先日入手したTektronixのデジタルオシロだが非常に使いやすい。
いやーー、良い買い物をした! って言う感じだ。

2014年1月19日日曜日

GPIBケーブルとデジタルオシロ

GP-IB IPの動作確認用に本物のGP-IBケーブルが欲しいなと思っていた。 ヤフオクで1mのGP-IBケーブルを含んだジャンクケーブル3本セットというのを見つけて入札したら他に入札する人も無く、開始価格で落札できた。 価格は¥1(1円)だった。

通常は落札価格の他に送料がかかるのだが、この時は同じ出品者が出品している他のジャンクも落札できたので、そちらとの同梱をお願いしたところ快諾頂いた。 なので、そういう意味ではケーブルの送料は無料となった。   同時に落札したのはGP-IBアダプタというやつで、レギュレータ電源をGP-IBから制御するためのアダプタのようだ。こちらは¥1,000円で落札できた。



上記とはタイミングが異なるが、ジャンクのデジタルオシロもヤフオクで買ってしまった。
デジタルオシロは中古測定器屋から入手したHPの奴があるのだが、、、まぁ、何というか、出品されている品の画像と価格を見てたらもう一台欲しくなっちゃったのよ。うん。

入手後、立ち上げて動作確認したところ、電源投入時の自己診断はPASSするのだがジョグダイアルに若干難があってダイアルを右に回しているのにカーソルは左に移動したり反応しなかったりしていた。 筐体のカバーを開けて、ジョグダイアル(接点式のロータリエンコーダと思う)の軸の隙間から接点クリーナーを注入したら正常に機能するようになった。それ以外に機能的な問題は無さそうである。また、精度的にも問題無い感じである。少なくとも趣味で使う範囲では。



かなり高機能のデジタルオシロみたいだ。
GP-IBポートもついているので、GP-IB IPから制御できるようになるといいなと思う。

2014年1月18日土曜日

Communication Box 21

SPI I/Fの動作確認として、SDカードをSPIモードで制御し、SDカードのディレクトリ情報をCOMポートに出力するプログラムを書いて動かして見ようとしていた訳だが、一応できた。

32MBのSDカードのルートディレクトリに以下のように4つのファイルを置いた。

プログラムの実行結果


プログラム ... SPI I/F(及びIP)部の動作確認ができればいいので、FAT16のルートディレクトリ情報のみに対応するものとした。





このプログラムは自作CPUのzumi32で実行される。
以前にも書いたが、zumi32用GCCの移植が出来たお陰で、プログラム開発がすごい楽である。

上記のようにプログラムを書いて make し、

FPGAにダウンロードする。

printfによるメッセージはCOM1(UART)に出力表示される。


普通のマイコン用プログラム開発と大して変わらない。移植して良かった。

SPI I/F部は一応これで終わり。

次は、いよいよGP-IBだ。




2014年1月14日火曜日

Communication Box 20

SPIモードによるSDカードアクセスを試している。
SDカードは以下の3枚で試していて、SDHCに関してはまだアクセスできていないが、他の2枚のSDカードはアクセス出きるようになった。


IPやハードウェアの問題は無さそうであり、ソフトウェア面での試行錯誤が続いている。

現状のプログラムは以下の通り
CMD0から始まって、MULTIPLE READでセクタを数ブロックリード出来るかを試している。




実行結果






2014年1月5日日曜日

Communication Box 19

なかなか GPIB の動作確認に到達しないが、、、今度はSPI I/Fの動作確認をすることにした。
これが終われば、GPIBに移れる。

SPI の動作確認として今回は SDカード(MMCモード)にアクセスしてみようと思う。 具体的には、SDカードのディレクトリ情報をリードしてCOMポートに出力するプログラムを書いてみようと考えている。 今やC言語でzumi32のプログラムが作成できるので、その意味では難易度はあまり高くないだろうと考えている。

今日は変換基板を作成した。





Communication Box 18

I2Cの動作確認

I2C液晶を動作確認に使用した。この液晶はいつか使ってみようと去年か一昨年にストロベリーリナックスから購入しておいたものだ。
video

I2C busのクロック(SCLの周波数)は392KHzにしている。
液晶のI/FがI2Cというと速度的に遅いイメージを持ってしまうが、実際に動かしてみるとそんなことは無く、意外だ。


プログラム

初期設定


文字列表示部


サブルーチン



2014年1月1日水曜日

Communication Box 17

まだPIO部で遊んでいる。

M202SD16FAというVFD(蛍光表示管)型キャラクタ表示モジュール(制御仕様は一般的なLCDキャラクタモジュールと同じ)を接続して文字列を表示させてみた。

video


GTX1050Ti と Tesla m2050 No.2 (BNN-PYNQのtrainingをやってみた)

BNN-PYNQのtraining(学習)をやってみた。  手順は https://github.com/Xilinx/BNN-PYNQ/tree/master/bnn/src/training に記載されており、特に判りづらい点はなかった。 ・ mnist.py 実行...